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.

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

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.

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.

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.

If you can manage to get >50% of your core logic in a 'vanilla' language(js, python, good ol' C) with minimal external dependencies, these yearly framework shifts become much less of a big deal.

I just wish I had internalized this lesson way, way, way earlier in my career...

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.

Developers disagree on even the most trivial things, like the best way to parse a query string. What makes anyone think those disagreements will magically disappear once web components become a standard?

Sure, give us native APIs that allow developers to build web components. But even then, people are not going to be abandoning their preferred frameworks. Frameworks can change their internals to target the new native APIs, but on the surface, they probably won't change much.

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

Instead they announce switching from Angular to Web Components before they ship a stable version of their current framework. It's great for doing really basic applications - but if it's getting into serious business their framework is just too buggy and the incredible demand to rewrite the whole app in pure JS becomes overwhelming.

I disagree that Ionic has found the end of the framework churn. What stays is a mixed feeling of a click bait. At least to me.

Web components are a nice standard, but don't force reactive DOM updates. Web components can contain their own script block and can do whatever updates they want, breaking reactive patterns in apps. In order to keep a reactive app behaving properly, developers will have to vet web components to ensure they work properly with their reactive app. In all likelihood everyone will continue re-implementing components in the reactive framework their app relies on.

Components are just one thing frameworks do -- among many other things. So the existence of a 'standardized component format' wont do anything to reduce framework churn.

Nor are Web Components going anywhere.

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

Maybe in a couple of years we get our Delphi and VB component designers and toolboxes for the Web.

"To end Framework Churn once and for all, .... Thankfully, there’s an answer: Web Components. "

I was expecting something like "Plain Javascript!" or something fundamental.

This is a content free reply, but I can't help but think this is the beginning of another churn.

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

How on Earth do you figure that? I'm well aware that e.g. the <video/> element is basically implemented as a Web Component in most (all?) browsers, but the reason people are excited is that it's now possible for non-browser developers to use Web Components and have those components work just like native elements.

We were discussing Web Components at the time the Angular was getting popular and before React was even released.

> for non-browser developers to ... have those components work just like native elements

Honest question, how do Web Components help native developers in any way? Because from UI devs perspective, Web Components are useful only in a single edge case - when you must make sure than it's impossible for Cascading Style Sheets to cascade to your component.

For a developer, Web components are solving problems that almost no one has or that were solved better by React and Vue.

> Honest question, how do Web Components help native developers in any way?

Being standardized, i.e. any old framework that can work with the DOM can with them, i.e. it reduces the number of truly necessary components to an "N" problem instead of an "NxM" component. Simple as that.

(Let's say we're looking for a "scrolling/sortable table" component. N is the number of different components along the 'features' axis. M would be the number of frameworks (Vue, React, etc.). It's a massive waste of resources that M > 1.)

EDIT: Yes, frameworks will still be around and that's fine.

Not really, it was used as a library to make JS work consistently across browsers and add missing features like querySelector and ajax fetch. But it had no opinion on how you should structure your app.

Angular, Backbone and Ember is from the same post-jQuery era when talks about Web components started.

> Being standardized, i.e. any old framework that can work with the DOM can with them

But does a developer really care that it's possible to use the same component in different frameworks, when you need it to work with just one (yours)?

I think the biggest fallacy is that people expect a technology to appear where you could just drop the component and it would work perfectly. From my experience, that will never happen - external component libraries are 90% what you need and 10% of hacking around missing features. The easier it is to safely and predictable hack the last 10% the better the framework/component library is.

Web Components provide nothing that help in UI development:

Helps manage multiple components state? Nope.

Provide a declarative API for components? Nope, imperative - the one we are trying to get away from.

Prevent CSS from affecting components? Cool, or I could just not write global styles, use BEM or CSS modules.

Easy to share components? NPM still works just fine for that.

> It's a massive waste of resources that M > 1

Agreed, that's something I thought a lot about. So I have created a cross-framework visual component editor - one component exports to many frameworks: https://github.com/UgnisSoftware/ugnis

Really? Maybe I was just out of the loop. I hope we can agree that Web Components were little more than a gleam in somebody's eye at that point, right?

(I'd love if you could point to any relevant mailing list/google groups discussions or whatever around this time, because apparently I missed 'em.)

> But does a developer really care that it's possible to use the same component in different frameworks, when you need it to work with just one (yours)?

Yes! I often have to work with multiple frameworks. Also: It'd be fanstastic if I had a choice matrix of "N" vs. "MxN" when I had to choose an implementation of, say, a scrollable-live-loading-table. That would be amazing, especially since we'd already decided on the "M" axis and written 20k LoC! I could choose the very best feature set for me! Ok, I might have to write a thin "shim" to have it interact with React or Vue.js or whatever, but the point is that this would be a trivial shim. I wouldn't have to rewrite the whole frontend when $BOSS decides that they want SuperLongUberTable.

The mere fact that the contents of such a table are just DOM nodes would also mean that I would be able to publish (as OSS) our own implementation of said beast... to much acclaim and prestige.

I also appreciate the fact that changing "NxM" to "N" means that (eventually) we'll get higher-quality components. For example, the components shipped in your browser are actually quite good. How many "good" video players did you see before HTML5 <video/>? My point is: The fact that anyone can write them means that there'll be a sort of evolutionary competition which tends towards an (admittedly, local) maximum -- but it's not as if the framework world has done much better, so... (Of course this is still at least a little hypothetical. We'll see, but I'm cautiously optimistic.)

EDIT: I might not have articulated it, but I think it goes without saying that I obviously want all components to evolve towards the "stateless-and-emits-events-to-container-components" model of e.g. React... and I think that will happen because it's simply easier to integrate into any framework.

I heard about Web Components spec in late 2012. There are some blogs from around that time: https://hacks.mozilla.org/2013/05/speed-up-app-development-w... In five years not much has changed.

> Yes! I often have to work with multiple frameworks.

There is an easier solution to this than Web Components - using a single framework. Unless you are a consultant same as me, than we can only blame ourselves for having to deal with this.

> My point is: The fact that anyone can write them means that there'll be a sort of evolutionary competition

That's not what happened with React component libs (material-ui, react-toolbox, etc.) - none of them has "won", all of them are pretty similar in quality. I would say that quality of a component is less important than how easy it is to adapt them to your business needs is.

My point is that having more ways to create a component is irrelevant - Framework churn existed not because we couldn't share components, but because writing components and managing state was awful. Web Components are still terrible at both of these things.

The good thing is that there hasn't been any new JS innovations in three years since React, Cycle, Elm, ClojureScript boom. And I would claim that there is not going to be because we are limited by the textual representation of our programming language. So the Framework churn ended not because everything is perfect, but because we couldn't make UI development better.

Yes, we all know how easy that is. I mean, really, come on -- that's not realistic in any reality.

EDIT: We all know the "n+1" standards XKCD joke, but the reality is that standards (HTML, CSS, HHTP, DNS, TCP, UDP, IP, etc.) brought us the fucking Internet, flawed as those standards may be. As I said, I'm cautiously optimistic that standardizing "custom DOM" will eventually get us to a standard slightly above raw HTML.

Huh? Most projects use a single framework in a project, sometimes two if they are migrating. If I had multiple frameworks in my project, sharing components between them would be the least of my problems.

> standardizing "custom DOM" will eventually get us to a standard slightly above raw HTML

I understand this sentiment, but DOM is irrelevant to front-end work right now. DOM is just a render target for frameworks, making DOM smarter changes nothing.

React components are brittle. The brittleness comes from the global nature of HTML, CSS, and JS. The DOM tree inside a React component isn't encapsulated from the rest of the page. This lack of encapsulation means your document stylesheet might accidentally apply to parts inside the widget; your JavaScript might accidentally modify parts inside the widget; your IDs might overlap with IDs inside the component; and so on. This means React components cannot be safely reused.

Web Components solve this problem. What's more, you can use JSX with Web Components (to implement Web Components as well as to use Web Components). See here: https://github.com/wisercoder/uibuilder

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.

CSS name clashes are an issue if you have to incorporate independently developed React components.

W.r.t. CSS name clashes, yeah they can come up especially in the contexts of independently developed React components. But in my experience over-encapsulation comes up far more often in the same context. I'm almost never in a situation where I want to slot a component in as-is. Instead, I want some find grained control over its styling or behavior, and if that's hidden behind an encapsulation barrier, that makes re-use even harder.

I do think the React component paradigm has some issues, but IMO they're the same sort of issues that come up in a lot of OO designs where abstraction and encapsulation happen in the wrong places. I still feel like Web Components solves some re-use problems I rarely if ever see in practice while doubling down on ones that I do.

    interface Component { void render(); }

Some ideas:

Standardization of certain APIs (see the craziness in the Javascript world regarding promises, though that night not even matter with 'async')

I believe this to be naively optimistic, but I'm all for Web components or any other development that help simplify things a bit. It's just that there will never be any silver bullet. I can make a list of the types of "The era of <Problem X> is now over and from here on it will be smooth sailing forever" that I've witnessed followed by the introduction of <Problem Y> that couldn't be anticipated. In a world of exponential complexity and creativity, I don't think this cycle is avoidable. It seems that the best we can hope for is that the rate that initiatives of abstraction, consolidation and standardization will manage to keep up with the forces (market and other) of defragmentation and growing complexity.

If anything, web components make framework hopping marginally easier resulting in a more likely (marginally) exodus of a framework when something new and shiny comes by.

Front-end framework churn is ultimately a result of the ever-growing Javascript community and its relatively fast-paced development. Because we now treat the front-end as seriously (and formally) as we treat the back-end and server/service stack, we will see the constant invention/innovation/adoption cycle that we see in these aspects of technology.

Framework churn is here to stay until browsers change the way the front-end works altogether.

But, until that actually happens, I'll carry on using Vue.

Anyone have any input for a confused developer?

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.

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

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.

https://xkcd.com/927/

And more often than not, they are right.

In this particular case Web Components only solves part of what frameworks do, and solves it badly. As badly as CSS solved the layout problem the last 2 decades.

I wouldn't mind a nice Web Components solution, but the current design reminds me of the over-engineering of things like Swing and JSF.

Now the latest Web framework trend is to do start headless browsers to do server side rendering.

Is it? I'd say it's usually rather because:

(a) Some of the competing standards wither and we get rid of them.

(b) Some standard emerges as the winning one and is adopted by everybody.

But very rarely by the addition of a new standard.

And for competing standards to wither, there somebody must have created the other standards too.

I wrote "emerges as winner". Not "emerges period".

Which does not require creating a NEW standard on top of existing ones (N+1), since an already existing standard (of N) can emerge as the winner.

I think it's a potent danger to be aware of, but I agree that I don't think it's a binding prophecy that somehow must happen.

I'm watching the conference where there are saying that "that is not yet another frameworks" but come on, that IS TOTALLY A NEW JS FRAMEWORK.

Let tell to a recruiter that you work 3 year on angular 1, 2 year on angular 2, but no really you feel you are ready for web component but you already failed your job interview, because you are a distancied old programmer working on old'good angular 4.1.3

Guys at ionic, you should work to correct your current version totally buggy (I know what I say, I will soon release my first app that I worked 5 month full time on)

Next time for sure I will stick with angular cli and a naked cordova

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