The big takeaway here is interoperability. React is great, Angular was great for its time, etc, but if your company builds out all its UI components in a specific framework you're locked into that framework, so a lot of churn happens if you ever decide to try the newest hotness. It appears that all the major browser vendors are now in agreement on a Web Components spec so it's only a matter of time now before we have a good, standardized way of extending the web spec.
Well, yes, because web components are native to the browser, not some third-party library. In other words, I'd feel no more locked into Web Components than I feel locked into the current DOM API.
Sorry to break it to you, React is not great. Angular neither. They fill a void that they should have never had to patch up, and are flawed because of it.
The fact that the 'newest hotness' breaks your GUI each time is an alarming sign that something is very broken. Additionally you seem to be talking as if this won't continue to happen.
Your final point - I'll believe it when I see it. Along with webAssembly, in 10 years.
There is no solution here. Who decides what I can and cannot declare with the select? If it's not me, then how will this other body of control make sure to include all possibilities in their API, which satisfy my requirements that even I don't know yet? And of course, how will these features work together? and then also be efficient?
.. aaaand we're back to where we are today. Pointless article.
You can extend it or create your own. Nobody forces you to use select. It's simply there if you need it. Your comment makes me think you don't actually understand how web components work.
Web components bring nothing new to the table. They simply copy the ideas from the desktop world, warts and all. I would have hoped after decades of GUI research the web would try something new, but why innovate when you can just copy right?
> There is no solution here. Who decides what I can and cannot declare with the select? If it's not me, then how will this other body of control make sure to include all possibilities in their API, which satisfy my requirements that even I don't know yet? And of course, how will these features work together? and then also be efficient?
By that reasoning any library is not a solution. Somehow people keep writing useful ones.
The article is saying the form is useful but needs to be extensible. Doesn't seem pointless to me.
Using Javascript has pros and cons, but the idea that it's fundamentally flawed is amusing. It certainly has had its warts, but the community has figured out how to use it efficiently and reliably. You're views on JS would have been much more relevant 10 - 15 years ago.
It's amusing to see that the web is haphazardly rediscovering decades of CS research. They finally figured out how to write subroutines into HTML.
Also, don't web components require JS, due to the document.registerElement call? If that's true, they've even failed to write web components into plain HTML. They're just gluing another JavaScript framework onto the web, the same way people expected would happen with prototypeJS.
You can style any custom element just fine without using document.registerElement, and use it like a native element if it's extending one. You only need to register it to do Javascript-specific things just as attaching functions to lifecycle callbacks, so it really isn't any different from being "required" to do `document.getElementById('#id').addEventListener(...)` in order to use plain DOM events.
It's not really that amusing, as if these "web" people aren't intimately familiar with CS research or basic principles of programming. The web wasn't designed ahead of time for all the uses it has today, it's evolved into its current role, and often by developers forcing it to do their bidding. It's also not defined by any single entity and the standards process takes a long time.
Of course something that started as an application framework would have had "subroutines" and custom components. That's no reason to deride the efforts to address that now.
As for requiring JS, you are correct. A declarative custom element standard will be needed before we can have extensible HTML without script. But given that a declarative standard will be a subset, in term of power, of the imperative API, it's best to see what the most common used parts of the imperative API are before baking defining the declarative version. If you look up initial versions of MDV and web components, you'll see declarative elements in there.
You speak as if web tech was made by the smartest people, and is cutting edge or something? The web is just politics. It is a total failure of technology - in fact, failure built upon failure - and yet it keeps it's head above the water because there is no alternative that can serve content to so many people.
> It's amusing to see that the web is haphazardly rediscovering decades of CS research. They finally figured out how to write subroutines into HTML.
Standards are hard and take a long time. C++ hasn't been haphazardly rediscovering decades of lambda expression use, for instance. Web components have been in development in some form for more than a decade.
JS, CSS and HTML were never designed to be a fully fledged programming application development solution, and no one is suggesting that it is supposed to be either. They weren't even designed in paralell.
Now that this has become a requirement, the slow moving spec machine is trying to resolve the issue.
Is this a problem for you? Because it seems to be.
