The end of Framework Churn

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.

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.

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.

Thats what web components aim to do, take Polymer - you get only minimal library on top of the spec, and with more browsers supporting the standard you just shed the polyfills for missing bits.

I was once using angular, and I wanted to use a common thing I had done in the past (autocomplete for a form I think it was). I already had a simple and effective way of doing it in jquery, but getting angular and jquery to work together is kind of a pain.

at the time, it wasn't implemented in angular very well, and there were some specific things I wanted to do that was incompatible to the way angular did it.

when I posted to the community how to get it working, their response was 'using jquery is not the angular way'. my way is getting things done with code I have used time and time again.

it took a bit of wrestling, but I was able to get it done with jquery and angular.

The goal of what folks call "universal web components" isn't (or shouldn't be) to create a single universal UI library -- that would indeed be a pipe dream.

Instead, the goal is (or ought to be) to create a native, app-directed API for creating and manipulating UI components. HTML and the DOM are a universal content format and API, and we need its equivalent for web apps (as opposed to content).

The web is a strange dualism between content and apps[1], and unfortunately, the app side has been forced to implement its constructs on top of an API that at its most fundamental level is built for presenting content.

[1] I like the diagram on page 33 of Jesse James Garret's seminal The Elements of User Experience: http://www.jjg.net/elements/pdf/elements_ch02.pdf

You can use vdom, lit-html or hyperhtml to force that (so yes everyone will use their favourite tool I guess, and that is a good thing). But individial components can be shared and reused.

To me custom components feel like one of the "innovations" that bring us more to a state where one part of the equation will be "solved" and there won't need to be any more experiments. It will just work. With all frameworks. And that is great.

Its not new, JavaScript has been around almost as much as Java which has a mature ecosystem since 10+ years.

JS world has had this "We're almost there" attitude since the announcement of HTML 5 ten years ago.

I had the same reaction because it's ridiculous to claim that Web Components can stop the Framework Churn when they predate most of the frameworks and didn't stop the churn from happening.

There are fundamental shifts happening in UI development, but Web Components are definitely not it.

I was really pumped about Web Components at first, largely because this sort of argument made a lot of sense to me. A few years on, I'm a lot less convinced that these are the problems that need to be solved.

Element IDs, for example, are useful if you're doing a kind of old-fashioned select-and-mutate approach to DOM management. But if you're using React idiomatically, you're never running query selectors or ever reading from the DOM at all (modulo trivial things like getClientHeight in lifecycle methods). It's hard to imagine when you'd have an ID conflict with React because it's hard to imagine when you'd need an ID.

Similarly, over the past few years I've had maybe two or three cases where CSS leaks due to under-encapsulation were a problem, and I was able to pick up on them and solve them with very little effort. Over the same period I've devoted much, much more effort to solving problems with over-encapsulation in cases where I needed to style a supposedly reusable component but some clever attempt at encapsulation (e.g. inline styling) prevented me from doing so and forced me to do a lot of work or re-implement the component wholesale.

I've known a few projects that were excited about things like Shadow DOM and went through a lot of work to incorporate them only to end up stripping them out (see Atom: http://blog.atom.io/2016/11/14/removing-shadow-dom-boundary-...) for related reasons.

So at this point I see a lot of the touted benefits to things like Web Components as a potentially painful set of solutions to a set of problems I've never really had. I don't really get it, but maybe they scratch some itch I don't have.

From what I have seen and heard, upgrading to v4 will be a bit more work than from 3.5 to 3.6 - but not nearly as big as the v1->v2 transition.

Here is a currently working link to a branch where this is developed (pre-alpha, so can change of course): https://github.com/ionic-team/ionic/tree/core/packages/ionic... & https://github.com/ionic-team/ionic/blob/core/packages/ionic... As I see it mostly the syntax and attributes of components were cleaned up.

Ionic Framework is still fully based on Angular, it will just be using Custom Components (bundled in a package called @ionic/core) inside instead of the "Angular built Components" (no idea how to name these...) in v2+3. These custom components are built using the Stencil compiler by the Ionic team, but as a Ionic Framework user you won't (have to) come into contact with that at all.

These new components can be used in other frameworks like React etc as well - or even AngularJS (Ionic v1!) or plain Javascript.

An alpha of v4 is planned pretty soon I hear.

This is an extremely short sighted article. It points out potential weaknesses of frameworks and then concludes unilaterally that they should never be used. This doesn't help anyone. Without the Rails framework my job would be significantly harder since I'd have to piece together several libraries for ORM, HTTP requests, DB Connections, etc. This would be significantly more cumbersome than just using a framework, since any one of those libraries could go defunct just like a framework could. My only other option if I can't use a framework is to write my own implementation of _every single core feature_ of rails. No thank you.

Use frameworks when they are appropriate, stand on the shoulders of others who have made significant contributions to the community.

I think you mean "You should never use Django unless you're building a social network". A lot of your arguments seem to only apply to the old guard of frameworks Django, Angular 1, etc...Where there would always be "The X way of doing it..."

All of the popular modern JavaScript frameworks are easy to learn, increase flexibility and creativity, are themselves mostly high powered versions of the core language (no useless knowledge after learning), generally small, and in no way are Facebook, Google, or Microsoft about to abandon React, TypeScript, Angular et al...

And that's just front end frameworks. Express and Koa do nothing to mystify idiomatic JavaScript or server development, and are just implementations of popular, easy to understand programming patterns.

I'm downvoting this because this is a knockout argument: People use this comic way too often to shush those of us who want to have a debate about whether a standard would be useful in a particular situation. I don't think this was Randall's intention when he did this comic.

I'm upvoting this, primarily because it accurately reflects what usually happens when a new standard is proposed. Apparently the rest of the HN community is either unaware of this, or dislike being reminded of it.

You can downgrade me as you want... That would be better to tell why it is a good news for developers? That is a new pain in my life, that it. Like if life wasn't already difficult like this.

Ionic Framework users won't come into contact with Stencil at all, just with the custom components built using it. The old `ion-textarea` (for example) will be replace with a new one that was compiled with Stencil.

So no, this is not a new JS framework that will be relevant to framework users.