Web Components could replace frontend frameworks?

The question is how can we build better frontend apps and not should we use frameworks or not. In the end there are only tools for different purposes.

Context and history are important to fully grasp WebComponents.

WebComponents arose when there was jQuery and decoupling of CSS, HTML and JS.

If you look back 10 years, there was no real separation of concern and Web purists like today always disliked the idea of mixing CSS in JS.

Then came NodeJS and frontend build tools started to provide better tools (GruntJS etc.) for compile time checks. Encapsulating CSS in JS for example solved the problem of overuse of id selectors, greedy class selectors and namespace collisions - domains that WebComponents tries to solve with Shadow DOM etc.

Todays frontend frameworks in combination with the underlying build tools provide a lot of the abstraction that WebComponents want to give developers. So I would rather say that WC are another tool which can be used by modern frameworks.

It is like saying air pollution can be solved by driving slower on highways when there are only combustion engines. Why should teslas be punished for the wrong reasons? Same goes for WebComponents. Good idea, great abstraction but context is important.

I wasn’t aware of this because this stuff is being developed and released so dang quickly! (I do worry that APIs developed in relative haste might be replaced or iterated on in relative haste, especially if they aren’t adopted widely first...)

Being built into the browser doesn't make it lightweight.

I mean, if you look in terms of functions that WebComponents adds, it's a relatively small API surface. However those APIs encompass an awful lot of different functions that imo bloat basic concepts by introducing complexity into HTML elements and the DOM.

>Ember, React and others plan to eventually support them. So, I am unconvinced that it disagrees with them at all. In fact I think it enables them to have wider access to developers.

I'm very much not holding my breath for that. I do think interoperabilility with WebComponents is a definite future, but thats it.

React fundamentally disagrees about what a component is. At the most basic level, React components are not DOM components, their entire DOM representation is what they render. This is not something that can be reconciled.

However should React let you export a component as a "WebComponent," via custom elements, sure, that's fine. Interoperabilility is not really notable though. It's also possible to interop React with Angular, Angular 2 with Angular 1, etc etc. Many of those are done today. In big apps. In production.

Edit: Reacts take here. https://reactjs.org/docs/web-components.html

>React and Web Components are built to solve different problems

Could not agree more, and that is precisely why no, WebComponents are not replacing my JS frameworks.

This is a weird misnomer to me. Stuff that's provided by the browser is not magically faster or better. Further, native browser functionality can slow down applications just by existing, like for example Mutation Events (which were removed in favor of Mutation Observers.)

In that sense I really dislike what functionality is being loaded onto HTML elements, effectively the lowest level primitive of web apps.

>They're also pretty unopinionated. They only let you define an HTML element and hook it's lifecycle.

In itself, there's not a whole lot wrong with this... But as fate would have it, the idea that HTML elements themselves should be components is an opinion hotly debated. In Angular 2, you have both directives, AND components that are selected from attributes. In React, the component tree is a fully separate entity from the DOM tree, and components don't even appear in the DOM.

To me these are not small details that can be reconciled. Part of what makes React ergonomically nice is that it can generate a nice, clean DOM free of component cruft and scoped CSS or whatever.

>And much better performance and bundle sizes.

Modern JS app performance is just not that simple. We've got server side rendering with hydration, scheduling rendering asynchronously for better responsiveness, bundle splitting, etc. Simply saying "WebComponents are better because they're faster" means little to me. Is my app bottlenecking on React? Often it's really not.

And if React's ~100kb is really killing you, there's plenty of libraries that implement just the basics in much less. Preact is quite good.