Comment by eric_b | Hacker News Reader

Comment by eric_b | Hacker News Reader

I do not believe Web Components will stop framework churn.

The big problem I have with web components is that they aren't very useful. Everyone seems to think the component is the key to victory with modern web applications. It's true that it's sometimes valuable to have turn-key UI components, but they almost never stand completely on their own. They need to know about the rest of the application and what's happening - and this is where web components fall short.

Imagine a shopping cart indicator on an E-commerce site. (A so-called "mini cart"). These are ubiquitous. When a user adds something to the cart from other places on the page, the indicator (usually in the upper right corner of the page) increases the count displayed, and maybe adds a small picture/description to a dropdown list showing what's in the cart.

Components help with a vanishingly small portion of that interaction. Sure, they allow you to drop a single tag on the page and have the UI look the same. But how does the cart component know to update? Global event bus? Click event handlers? Polling? Callbacks? That mechanism is undefined with Web Components.

Communication between components is the key to winning the web application war, and this is why I think React has done so well. Their data flow/communication pattern with Redux is really understandable and easy to reason about. They've got first class support for passing application state around, and ensuring an action in one place on the page cascades to all places that care about it. To me that is infinitely more important for productivity than stamping out the same custom element over and over.

I think the point is more that by using web components, whatever framework you're using becomes more interchangeable. Web components only solve a piece of what, say, React does – the component piece. For state management, you can still reach for Redux (which tries to be framework agnostic), or even still embed them in React if that makes sense for your app.

So maybe web components won't stop framework churn, but they'll make it a lot easier to transition between frameworks.

I dunno, I'd rather use "vanilla" React/Redux/JSX than try and get those tools to fit with custom elements, shadow DOM and the html import/template stuff.

The web components specs look poorly thought out to me. They seem superficially like good ideas, but when you actually bother to build something with them you hit the rough edges and missing pieces. I do not appreciate that Chrome rammed them unilaterally down our throats, or that their Polymer evangelists continue to flog these technologies as though they are somehow an answer to the vast majority of problems web developers face.

React is an ideal version of web components in a world where ui = f(state)

JSX standard is independent of React and can be used with Web Components. Also, HTML import is unnecessary to use Web Components. The key technologies in Web Components are ShadowDOM and Custom Elements.

So we push the churn to router, stores and other frameworks?

Yeah, this. I'm not actually sure the war is fully winnable - maybe it'll slow down at some point.

UI frameworks have churned in every language I've ever worked with. Java had AWT/SWT/Swing/JavaFX/etc. I can't remember all the C++ options. There have been more JS frameworks and the turn over rate is higher, but that makes sense given how UI-focused the web applications have to be and how fast the underlying platform has changed.

User interfaces have to react to (and inform) a lot of internal application state, which means they often need to be coupled to the application architecture. Furthermore, interfaces are often refactored and customized in ways that are hard to predict from the outset.

So for one thing, I've never really found components to deliver on the promise of re-usability and compatibility - I always end up having to dig into the internals and make some changes to get exactly the behavior I want in a way that fits in to my system's overall architectural requirements.

But also, this tends to spell trouble for opinionated frameworks in general - the assumptions you make aren't going to work for all applications, and the ecosystem of applications (e.g. the migration to SPAs) or platform technologies (e.g. ES language and web API changes) might change out from under you.

So my advice for most web devs is: stop thinking "when will this end?" and start thinking "how can I make myself less vulnerable to the worst parts of this?"

Using less opinionated frameworks is a good step. Big, do-everything, opinionated frameworks tend to have to be replaced wholesale if there's something missing or wrong with any part of them, or they're just not compatible with the approach you need to take for a given project. I can count a handful of things that were supposed to finally solve all the problems of web development that aren't officially supported at all anymore. React actually makes some progress on this front - it's a lot less opinionated than its early competitors, e.g. Angular, Ember, etc. More modular systems that are based on a few interacting libraries that can be swapped out are ironically more stable even though they're more vulnerable to low-level churn of changing bits and pieces because frequent small changes tend to be less traumatic than periodic big ones.

I agree with everything you say right up until you glorify React.

React too will churn to dust in another few years, when the Next Hotness comes out. I've been building GUIs of various flavors going back to MFC on Win16. Every few years the technology shifts, and if you don't want to get left behind, you shift with it. The New Thing is always compelling but it's also never a pareto improvement on the Old Thing. Hell, there are still some aspects of React that make me miss MFC (like, how about a decent tree control??).

I've spent most of the last year working with React. It's ok. But it's not different this time; it's just one more step along the way. In another two years I expect to be using something else.

You can use web components with redux. The implementer of that said "mini cart" can make all the decisions for you, but you will end up with reusable "mini framework" in the end.

Components raise events, you listen for those events and update what you need. Probably you could setup data binding in some components like Listboxes.

Reply on news.ycombinator.com