4 ms·

I am more a fan of the augmented style because it doesn't entrap you in dev lock-in to platforms. The problem with frameworks, especially web frameworks, is th

I am more a fan of the augmented style because it doesn't entrap you in dev lock-in to platforms. The problem with frameworks, especially web frameworks, is they reimplement many items that are standard now (shadowdom, components, storage, templating, base libraries, class/async, network/realtime etc). DOM rendering speeds have been improved due to virtualdom but is no longer needed with shadowdom. The web standards of today are amazing and take away the need for frameworks today: from templating to html templates [1], vanilla javascript with classes [2] and async [3] and better api access like fetch [4] and browser support for vdom with shadow dom [5], components with WebComponents [6][7], css now with lots of additions like variables [8] transitions[9]/animations[10], flex and media queries, canvas/svg/etc for interactivity, and so much more. There is little need to use frameworks except to sell books and conferences and keep developers locked in. React for instance jumped ahead and front ran WebComponents and ShadowDOM, those are both part of the browser and standards now. The killer feature phase of React is over. If you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice. [11] Google Lit is like a combination of HTML Web Components and React/Vue style components. The great part is it is build on Web Components underneath. [1] https://caniuse.com/template https://caniuse.com/template [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [4] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U... [5] https://caniuse.com/shadowdomv1 https://caniuse.com/shadowdomv1 [6] https://caniuse.com/custom-elementsv1 https://caniuse.com/custom-elementsv1 [7] https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components [8] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c... [9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition https://developer.mozilla.org/en-US/docs/Web/CSS/transition [10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation https://developer.mozilla.org/en-US/docs/Web/CSS/animation [11] https://lit.dev/ https://lit.dev/

CharlesW 3y ago
But if you introduce an open-source dependency to make web components usable, why not use a popular, complementary ecosystem like Vue? https://vuejs.org/guide/extras/web-components.html https://vuejs.org/guide/extras/web-components.html
- drawkbox 3y ago
  Staying closer to web standards is always best for maintainability and portability. I personally like custom direct standards but that doesn't always work in a team for some reason today. There will always be less dependencies in a straight standards solution, that makes for better maintainability and opsec. I also think it is better for web developers to know standards over just abstractions, it makes for better developers. Additionally, web standards like Web Components/templates/custom elements will always be faster at browser level. The article from OP mentions this: > But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. There are other reasons as well but these are the best reasons. I think using a framework for a team isn't a bad idea, but for products and personal projects I like going custom or newer framework like Lit simply because of the web standards being less abstracted away and due to that, less need to constantly update on others schedules due to dev lock-in. There is less weight in straight standards. If you remember React/Vue originally won due to virtualdom and being small parts that work into an existing web, but recently they have been very monolithic in that they take over the entire project. The web is more about augmentation as the article mentions and I agree, those items will be easier to maintain.
  - CharlesW 3y ago
    > Staying closer to web standards is always best for maintainability and portability. I understand that argument, but Lit isn't a web standard, and it's an esoteric choice compared to Vue, which works great with custom elements.
    - drawkbox 3y ago
      Yeah agreed, that is why I said "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice" Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now. I still prefer direct and custom with less dependencies but Lit is somewhat trying to communicate web standards while other current frameworks really want lock-in to the platform rather than caring about making sure devs understand the standards.

CharlesW 3y ago

But if you introduce an open-source dependency to make web components usable, why not use a popular, complementary ecosystem like Vue? https://vuejs.org/guide/extras/web-components.html https://vuejs.org/guide/extras/web-components.html

drawkbox 3y ago
Staying closer to web standards is always best for maintainability and portability. I personally like custom direct standards but that doesn't always work in a team for some reason today. There will always be less dependencies in a straight standards solution, that makes for better maintainability and opsec. I also think it is better for web developers to know standards over just abstractions, it makes for better developers. Additionally, web standards like Web Components/templates/custom elements will always be faster at browser level. The article from OP mentions this: > But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop. There are other reasons as well but these are the best reasons. I think using a framework for a team isn't a bad idea, but for products and personal projects I like going custom or newer framework like Lit simply because of the web standards being less abstracted away and due to that, less need to constantly update on others schedules due to dev lock-in. There is less weight in straight standards. If you remember React/Vue originally won due to virtualdom and being small parts that work into an existing web, but recently they have been very monolithic in that they take over the entire project. The web is more about augmentation as the article mentions and I agree, those items will be easier to maintain.
- CharlesW 3y ago
  > Staying closer to web standards is always best for maintainability and portability. I understand that argument, but Lit isn't a web standard, and it's an esoteric choice compared to Vue, which works great with custom elements.
  - drawkbox 3y ago
    Yeah agreed, that is why I said "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice" Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now. I still prefer direct and custom with less dependencies but Lit is somewhat trying to communicate web standards while other current frameworks really want lock-in to the platform rather than caring about making sure devs understand the standards.