10 ms·

The end of Framework Churn

65 points by Sujan 9y ago

aargh_aargh 9y ago
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.
- Sujan 9y ago
  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.
  - pjmlp 9y ago
    I look forward to see the Web finally catch up with 90's. Maybe in a couple of years we get our Delphi and VB component designers and toolboxes for the Web.
- sydd 9y ago
  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.
hprotagonist 9y ago
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. https://xkcd.com/927/ https://xkcd.com/927/
- majewsky 9y ago
  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.
  - hprotagonist 9y ago
    fair enough; thanks for explaining your decision, too. 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.
  - coldtea 9y ago
    >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 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.
    - marcosdumay 9y ago
      > And more often than not, they are right. And yet, every time that the number of standards is reduced, it is by this same process. So, yes, it is the one way to do it. And yes, more often than more, it fails completely. So, let me ask you, what is the point of complaining that somebody is going through that?
      - coldtea 9y ago
        >And yet, every time that the number of standards is reduced, it is by this same process 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.
eric_b 9y ago
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.
- catpolice 9y ago
  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.
interlocutor 9y ago
Web Components solve a number of problems with other component libraries such as React. 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 https://github.com/wisercoder/uibuilder
- catpolice 9y ago
  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-from-text-editor-elements.html 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.
barkingcat 9y ago
As much as hacker news frowns on humour replies. I really frankly laughed out loud when I read "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.
- masiulis 9y 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.
  - lomnakkus 9y ago
    > it's ridiculous to claim that Web Components can stop the Framework Churn when they predate most of the frameworks 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.
    - masiulis 9y ago
      > How on Earth do you figure that? 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.
      - 9y ago
bandrami 9y ago
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?
joshiefishbein 9y ago
Web components don't take care of the full ecosystem that is the front-end and will prove irrelevant to framework churn. 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.
H1Supreme 9y ago
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. But, until that actually happens, I'll carry on using Vue.
zackify 9y ago
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.
caleblloyd 9y ago
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. 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.
- ergo14 9y ago
  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.
kitotik 9y ago
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. 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...
- ergo14 9y ago
  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.
- autokad 9y ago
  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.
pkrumins 9y ago
You should never be using frameworks. http://www.catonmat.net/blog/frameworks-dont-make-sense/ http://www.catonmat.net/blog/frameworks-dont-make-sense/
- coltonv 9y ago
  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.
- amsheehan 9y ago
  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.
dehef 9y ago
This is totally a shame. 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
- dehef 9y ago
  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.
- Sujan 9y ago
  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.
jl6 9y ago
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?
tabeth 9y ago
As long as there's something to gain for an aspiring developer by creating a new 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. Some ideas: Standardization of certain APIs (see the craziness in the Javascript world regarding promises, though that night not even matter with 'async')
coldtea 9y ago
>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. 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.
revelation 9y ago
Web components are syntactic sugar and a registry (yes, Java coming to a browser near you!) around the following: interface Component { void render(); } 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.
ralmidani 9y ago
As I've said before, universal web components are a pipe dream. 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.
- TimTheTinker 9y ago
  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 http://www.jjg.net/elements/pdf/elements_ch02.pdf
danieka 9y ago
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? Anyone have any input for a confused developer?
- Sujan 9y ago
  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-angular https://github.com/ionic-team/ionic/tree/core/packages/ionic... & https://github.com/ionic-team/ionic/blob/core/packages/ionic-angular/BREAKING.md 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.
  - danieka 9y ago
    Thanks, that's comforting to hear.
SoMisanthrope 9y ago
I haven't _seriously_ written code in about 15 years. That said, I hire and manage people that do code (and do it damn well!). So, we discussed this article and the question was posed "How do you keep up with the newly-minted-hipster-cool-named widgets that get produced, every two weeks?" The answer: "Most of that stuff is trendy and flames out in a matter of a couple of months, just wait and watch..." Some good wisdom, I think.
hilti 9y ago
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. 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.
placebo 9y ago
>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. 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.
z3t4 9y ago
Or you could just ditch HTML and XML, and use only JavaScript and CSS. You still use elements like input, button img, but under an abstraction layer.
tabtab 9y ago
Tag based interfaces? Sounds kind of like client-side Coldfusion.
halis 9y ago
We have the revolutionary answer to framework churn! Nothing will ever be the same! Ya'll ready for this! Behold! Web Components! Can someone please queue the Picard facepalm meme?

65 points by Sujan 9y ago

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.

Sujan 9y ago
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.
- pjmlp 9y ago
  I look forward to see the Web finally catch up with 90's. Maybe in a couple of years we get our Delphi and VB component designers and toolboxes for the Web.
sydd 9y ago
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.

hprotagonist 9y ago

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. https://xkcd.com/927/ https://xkcd.com/927/

majewsky 9y ago
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.
- hprotagonist 9y ago
  fair enough; thanks for explaining your decision, too. 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.
- coldtea 9y ago
  >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 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.
  - marcosdumay 9y ago
    > And more often than not, they are right. And yet, every time that the number of standards is reduced, it is by this same process. So, yes, it is the one way to do it. And yes, more often than more, it fails completely. So, let me ask you, what is the point of complaining that somebody is going through that?
    - coldtea 9y ago
      >And yet, every time that the number of standards is reduced, it is by this same process 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.

eric_b 9y ago

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.

catpolice 9y ago
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.

interlocutor 9y ago

Web Components solve a number of problems with other component libraries such as React. 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 https://github.com/wisercoder/uibuilder

catpolice 9y ago
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-from-text-editor-elements.html 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.

barkingcat 9y ago

As much as hacker news frowns on humour replies. I really frankly laughed out loud when I read "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.

masiulis 9y 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.
- lomnakkus 9y ago
  > it's ridiculous to claim that Web Components can stop the Framework Churn when they predate most of the frameworks 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.
  - masiulis 9y ago
    > How on Earth do you figure that? 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.
    - 9y ago

bandrami 9y ago

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?

joshiefishbein 9y ago

Web components don't take care of the full ecosystem that is the front-end and will prove irrelevant to framework churn. 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.

H1Supreme 9y ago

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. But, until that actually happens, I'll carry on using Vue.

zackify 9y ago

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.

caleblloyd 9y ago

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. 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.

ergo14 9y ago
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.

kitotik 9y ago

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. 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...

ergo14 9y ago
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.
autokad 9y ago
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.

pkrumins 9y ago

You should never be using frameworks. http://www.catonmat.net/blog/frameworks-dont-make-sense/ http://www.catonmat.net/blog/frameworks-dont-make-sense/

coltonv 9y ago
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.
amsheehan 9y ago
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.

dehef 9y ago

This is totally a shame. 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

dehef 9y ago
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.
Sujan 9y ago
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.

jl6 9y ago

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?

tabeth 9y ago

As long as there's something to gain for an aspiring developer by creating a new 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. Some ideas: Standardization of certain APIs (see the craziness in the Javascript world regarding promises, though that night not even matter with 'async')

coldtea 9y ago

>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. 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.

revelation 9y ago

Web components are syntactic sugar and a registry (yes, Java coming to a browser near you!) around the following: interface Component { void render(); } 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.

ralmidani 9y ago

As I've said before, universal web components are a pipe dream. 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.

TimTheTinker 9y ago
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 http://www.jjg.net/elements/pdf/elements_ch02.pdf

danieka 9y ago

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? Anyone have any input for a confused developer?

Sujan 9y ago
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-angular https://github.com/ionic-team/ionic/tree/core/packages/ionic... & https://github.com/ionic-team/ionic/blob/core/packages/ionic-angular/BREAKING.md 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.
- danieka 9y ago
  Thanks, that's comforting to hear.

SoMisanthrope 9y ago

I haven't _seriously_ written code in about 15 years. That said, I hire and manage people that do code (and do it damn well!). So, we discussed this article and the question was posed "How do you keep up with the newly-minted-hipster-cool-named widgets that get produced, every two weeks?" The answer: "Most of that stuff is trendy and flames out in a matter of a couple of months, just wait and watch..." Some good wisdom, I think.

hilti 9y ago

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. 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.

placebo 9y ago

>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. 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.

z3t4 9y ago

Or you could just ditch HTML and XML, and use only JavaScript and CSS. You still use elements like input, button img, but under an abstraction layer.

tabtab 9y ago

Tag based interfaces? Sounds kind of like client-side Coldfusion.

halis 9y ago

We have the revolutionary answer to framework churn! Nothing will ever be the same! Ya'll ready for this! Behold! Web Components! Can someone please queue the Picard facepalm meme?