Post

Can't emphasise how much I feel these are exactly the sort of use cases and users the web was made for: "hobbyists, hackers, educators, makers and developers"! Not everything has to be about corporate bottom lines sometimes the web can just be for fun tinkering (but also lots of real world use too)!

It also goes to show that perhaps chromium was right to forge the path on these APIs, well established technologies brought to the web in a safe way. It may have taken years but there's now a solid second implementation and a path to a standards venue.

2 reposts9 likes

I think so too. Sometimes the right thing is to seek consensus upfront and sometimes the right thing is to just slash ahead with something imperfect and let it meet reality. It's not always obvious which one is right.

Well I’d argue it’s ALWAYS the right thing is to SEEK consensus. And know you would too! 😁 But when you can’t get it, is when it gets interesting. Of course there are risks to slashing ahead and it’s definitely not always the right thing to do. But there’s also downsides to not pushing ahead.

I think in the case of these peripheral APIs where there's nothing super novel being done except for exposing the capability to the web, and the argumentation is almost entirely at the "should we do this?" Question rather than about API details, that's a reasonable place to push ahead.

In fact I think the picker permissions model was a very nice development out of these and it would be interesting if they could and should be retrofitted somehow to other APIs. E.g. Web midi doesn't use that.