4 ms·

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

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.
    - lomnakkus 9y ago
      Do you not count e.g. jQuery as a framework? Angular and React are also pretty late entrants. Before that there was Backbone, Ember, etc. > 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.
      - masiulis 9y ago
        > Do you not count e.g. jQuery as a framework? 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 https://github.com/UgnisSoftware/ugnis
        9y ago

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.
  - lomnakkus 9y ago
    Do you not count e.g. jQuery as a framework? Angular and React are also pretty late entrants. Before that there was Backbone, Ember, etc. > 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.
    - masiulis 9y ago
      > Do you not count e.g. jQuery as a framework? 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 https://github.com/UgnisSoftware/ugnis
      - 9y ago