4 ms·

I haven't done any serious webdev since 2013. I thought Knockout.js was pretty slick at the time. I don't know how react works. I don't know how svelte works. T

I haven't done any serious webdev since 2013. I thought Knockout.js was pretty slick at the time. I don't know how react works. I don't know how svelte works. This article is so basic to me that I makes me wonder wtf these frameworks are actually doing and why this article even came to exist.

tomByrer 3y ago
From the creator of SolidJS (heavily inspired by Knockout.js by his own confession) & worked on eBay's Marko framework: https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh https://dev.to/ryansolid/maybe-web-components-are-not-the-fu...
LAC-Tech 3y ago
Front-end web dev heavily skews junior. People like Nolan really stand out.
earthboundkid 3y ago
TBF, Web Components were invented in 2013 and have not really changed since then.
- troupo 3y ago
  The idea of web components was presented in 2011 https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an... Since then they've become the complete antithesis of that vision
jongjong 3y ago
I think everyone got caught up in the mania. I've been coding for 15 years and I was a full stack dev throughout. TBH I thought Google's PolymerJS (which was closer to Web Components) would take the crown but React came out of nowhere and everyone jumped on that bandwagon en masse and the complexity of all front end frameworks just kept increasing year after year. In the meantime, browsers were forging ahead with a lot of nice features that had been planned for a long time and which would make the frameworks redundant and now that these features are available, the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them anymore due to large scale sunk cost fallacy... Not to mention all the vested interests (platform providers) who built on top of React.
- troupo 3y ago
  > the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them Yes, yes you do. Even with all the nice things there are very few things that are actually useful and usable. Even web components are no longer advertised as "framework replacements", but as "yeah, they are aimed at library and framework authors" (and vanishingly few libraries and frameworks use them due to their many shortcomings)
  - jongjong 3y ago
    I disagree. The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app in a certain way which turns out to be beneficial in the medium and long term as it makes it much easier to maintain. With many frameworks, I find that most of my debugging work is related to framework-specific gotchas. For example, just this week, I was debugging a VueJS app and it would run validation rules on an input field before it was ready and it caused a flickering red error border around the input box. It was a case where the content of the input field had to be sanitized; that input field needed a second rendering if the user pasted content directly into it (as opposed to typing). It took me a while to come up with a workaround because VueJS controlled the timing of when the validation rule would be enforced (on render) and I couldn't control the timing. I had to create an additional reactive 'isInputReady' variable and use it inside the validation function that I provided to the VueJS input component through the rules attribute... Kind of hacky but there is no friction-less way (without the browser prompting the user) to intercept clipboard data before the content was inserted into the input field; the only way to do sensitization of pasted data was through a re-rendering but I could not stop the red flicker without adding this extra isReady variable and making it part of the validation rule... Anyway my point is that when using a framework, you run into these types of tricky issues all the time and you have to come up with equally tricky workarounds. I don't run into these issues when using Web Components because I have full control over the rendering. I don't need to make a component reactive for cases where reactivity gets in the way.
    - troupo 3y ago
      > The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app Not really. The perceived simplicity of Web Components makes you deal with issues that you should never have to deal with, and reinvent your own libraries and frameworks for even the simplest things, and you will still run into unexpected gotchas. Especially if your components will be used by others (cross-root ARIA, SSR, styling, proper form participation etc.). But even for what are not even supposed to be issues. It's a good thing you mentioned an input box. Properly re-rendering an input box in response to certain events or state changes will be either lots of tedious manual work, or running into issues like losing focus, user input, and values. And there's literally nothing in web components to help you with that: use or create your own library to deal with it. The behaviour you described for Vue is surprising though... > I don't run into these issues when using Web Components because I have full control over the rendering. Not really you don't. For example, web components are eagerly rendered, and there's really not much you can do to prevent a rendering cascade when in reality you want something to load and render lazily. You can't coordinate between various components on the page, so they will all have their own idea of when to render.

tomByrer 3y ago

From the creator of SolidJS (heavily inspired by Knockout.js by his own confession) & worked on eBay's Marko framework: https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh https://dev.to/ryansolid/maybe-web-components-are-not-the-fu...

LAC-Tech 3y ago

Front-end web dev heavily skews junior. People like Nolan really stand out.

earthboundkid 3y ago

TBF, Web Components were invented in 2013 and have not really changed since then.

troupo 3y ago
The idea of web components was presented in 2011 https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell https://fronteers.nl/congres/2011/sessions/web-components-an... Since then they've become the complete antithesis of that vision

jongjong 3y ago

I think everyone got caught up in the mania. I've been coding for 15 years and I was a full stack dev throughout. TBH I thought Google's PolymerJS (which was closer to Web Components) would take the crown but React came out of nowhere and everyone jumped on that bandwagon en masse and the complexity of all front end frameworks just kept increasing year after year. In the meantime, browsers were forging ahead with a lot of nice features that had been planned for a long time and which would make the frameworks redundant and now that these features are available, the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them anymore due to large scale sunk cost fallacy... Not to mention all the vested interests (platform providers) who built on top of React.

troupo 3y ago
> the frameworks have gained a lot of inertia and it's hard to people to accept that you don't need them Yes, yes you do. Even with all the nice things there are very few things that are actually useful and usable. Even web components are no longer advertised as "framework replacements", but as "yeah, they are aimed at library and framework authors" (and vanishingly few libraries and frameworks use them due to their many shortcomings)
- jongjong 3y ago
  I disagree. The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app in a certain way which turns out to be beneficial in the medium and long term as it makes it much easier to maintain. With many frameworks, I find that most of my debugging work is related to framework-specific gotchas. For example, just this week, I was debugging a VueJS app and it would run validation rules on an input field before it was ready and it caused a flickering red error border around the input box. It was a case where the content of the input field had to be sanitized; that input field needed a second rendering if the user pasted content directly into it (as opposed to typing). It took me a while to come up with a workaround because VueJS controlled the timing of when the validation rule would be enforced (on render) and I couldn't control the timing. I had to create an additional reactive 'isInputReady' variable and use it inside the validation function that I provided to the VueJS input component through the rules attribute... Kind of hacky but there is no friction-less way (without the browser prompting the user) to intercept clipboard data before the content was inserted into the input field; the only way to do sensitization of pasted data was through a re-rendering but I could not stop the red flicker without adding this extra isReady variable and making it part of the validation rule... Anyway my point is that when using a framework, you run into these types of tricky issues all the time and you have to come up with equally tricky workarounds. I don't run into these issues when using Web Components because I have full control over the rendering. I don't need to make a component reactive for cases where reactivity gets in the way.
  - troupo 3y ago
    > The simplicity of Web Components forces you to plan ahead a little bit more and to architect your app Not really. The perceived simplicity of Web Components makes you deal with issues that you should never have to deal with, and reinvent your own libraries and frameworks for even the simplest things, and you will still run into unexpected gotchas. Especially if your components will be used by others (cross-root ARIA, SSR, styling, proper form participation etc.). But even for what are not even supposed to be issues. It's a good thing you mentioned an input box. Properly re-rendering an input box in response to certain events or state changes will be either lots of tedious manual work, or running into issues like losing focus, user input, and values. And there's literally nothing in web components to help you with that: use or create your own library to deal with it. The behaviour you described for Vue is surprising though... > I don't run into these issues when using Web Components because I have full control over the rendering. Not really you don't. For example, web components are eagerly rendered, and there's really not much you can do to prevent a rendering cascade when in reality you want something to load and render lazily. You can't coordinate between various components on the page, so they will all have their own idea of when to render.