I do not believe Web Components will stop framework churn.<p>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.<p>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.<p>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.<p>Communication <i>between</i> 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.
In my experience, the biggest cause of framework churn is bad architecture and development patterns - no clear separation of business logic and 'framework', which forces these all-or-nothing rewrites with the sexy framework of the day in the hopes of a massive productivity boost.<p>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.<p>I just wish I had internalized this lesson way, way, way earlier in my career...
As I've said before, universal web components are a pipe dream.<p>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?<p>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.
It's mid of September so this can't be an April fool.
Having read this headline I was hoping that they are doing something more 'vanilla': just good old Javascript for the core logic, HTML5 with data attributes describing the markup of an app and CSS3 to for styling.<p>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.<p>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.
One of the reasons that React, Vue, and other reactive frameworks have become so prevalent is because of Virtual DOM reducing the number of Physical DOM updates.<p>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.
><i>To end Framework Churn once and for all, we need a way to create components that speak a language every developer and framework can understand. A component language that can be standardized but is also compatible with existing framework component languages.</i><p>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.<p>Nor are Web Components going anywhere.
The reason for the churn is not lack of a standard for components. It's that the ecosystem is both new and large, so many experiments are going on, some of which become popular until the next best thing comes along. This won't be solved by components. It will be solved slowly over time as innovation levels off.
As much as hacker news frowns on humour replies. I really frankly laughed out loud when I read<p>"To end Framework Churn once and for all, .... Thankfully, there’s an answer: Web Components. "<p>I was expecting something like "Plain Javascript!" or something fundamental.<p>This is a content free reply, but I can't help but think this is the beginning of another churn.
I've been using the same JS framework for 3+ years. I don't agree with all of these complaints on JS churn being too much. Web components aren't the answer either.
Web Components solve a number of problems with other component libraries such as React.<p>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.<p>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: <a href="https://github.com/wisercoder/uibuilder" rel="nofollow">https://github.com/wisercoder/uibuilder</a>
Web components are syntactic sugar and a registry (yes, Java coming to a browser near you!) around the following:<p><pre><code> interface Component { void render(); }
</code></pre>
If you think this somehow solves all JS framework issues, I have a bridge to sell you. Or there was never a meaningful problem in the first place.
OK, so we'll spend a year moving the unwieldy multitude of frameworks to instead be inside web components that will be distributed just as wantonly as frameworks are now. What's really gained there?
As long as there's something to gain for an aspiring developer by creating a <i>new</i> framework, there will always be churn as there will always be new frameworks. Rather than reducing churn we should aspire to make it less and less painful to the point of irrelevance.<p>Some ideas:<p>Standardization of certain APIs (see the craziness in the Javascript world regarding promises, though that night not even matter with 'async')
>The era of Framework churn is coming to an end, and now we can all go back to working on what makes our apps unique instead of spending precious time, energy, and money jumping to something new every year.<p>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.
Web components don't take care of the full ecosystem that is the front-end and will prove irrelevant to framework churn.<p>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.<p>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.<p>Framework churn is here to stay until browsers change the way the front-end works altogether.
I've been wanting to use Web Components since Polymer was pre 1.0. But, browser support still has a ways to go. I think we would all love a solution that has all our dependencies baked into the browser.<p>But, until that actually happens, I'll carry on using Vue.
They say history repeats itself, and I feel we have been here before. Is the web framework landscape not a little like the Windows desktop in the 90s? What does history say will happen next?
Considering how jarring the change from Ionic to Ionic 2 was (we haven't yet had time to migrate our 30k line app) I'm kind of worried how the upgrade path looks from Ionic 3 to 4. Moving forward is good, I suppose. But I would have appreciated some information on what this means for us that have yet to migrate to Ionic 2/3. Should we wait for version 4 to be completed?<p>Anyone have any input for a confused developer?
We have the revolutionary answer to framework churn! Nothing will ever be the same! Ya'll ready for this!<p>Behold! Web Components!<p>Can someone please queue the Picard facepalm meme?
You should never be using frameworks. <a href="http://www.catonmat.net/blog/frameworks-dont-make-sense/" rel="nofollow">http://www.catonmat.net/blog/frameworks-dont-make-sense/</a>
<i>To end Framework Churn once and for all, we need a way to create components that speak a language every developer and framework can understand. A component language that can be standardized but is also compatible with existing framework component languages.</i><p><a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a>
This is totally a shame.<p>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.<p>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<p>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)<p>Next time for sure I will stick with angular cli and a naked cordova