6 ms·

I think part of the reason people talk past each other on this issue is because they're optimizing for different things. If you're working for a VC-backed start

I think part of the reason people talk past each other on this issue is because they're optimizing for different things. If you're working for a VC-backed startup with a central product that needs to move quickly and is going to require constant maintenance anyway, a framework might be a good fit for you. But I work in an academic lab. We don't have tons of money to maintain the apps that we've written. We need them to just keep working once funding has moved on to new projects. We're just finishing up a rewrite of an app from Vue to Web Components. It had dependency rotted to the point where we couldn't update anything because of dependency hell. Rather than spend hours trying to fix it, which we've done before and would have to do again until the end of time, I decided to experiment with Web Components. The experience was immediately so nice that we went all in. No regrets. We went from ~15 dependencies to ~1 (d3js). If you're curious to try the apps, old one[0] new one[1]. [0]: https://bam.iobio.io/ https://bam.iobio.io/ [1]: https://bam2.iobio.io/ https://bam2.iobio.io/

jitl 2y ago
If you can rewrite to remove all dependencies except for d3js, why couldn’t you do the same thing, but also retain a dependency on Vue? What is it about Vue that requires the extra dependencies - is it built system things? (I’ve never used Vue)
- apitman 2y ago
  Vue itself must be updated. And if you throw out the router, Vuetify, state management, etc, what is it adding above Web Components anyway?
  - athanagor2 2y ago
    As far as I know there's no simple and performant way to have the DOM be a function of the state with existing standards
    - hasanhaja 2y ago
      What do you mean specifically when you say? > DOM be a function of the state I understand the benefits of the mental model, but the tooling that delivers that generally have a lot of complexity that isn't trivial to parse and understand. I think the benefit of being able to parse and understand your abstractions (ones you build yourselves or buy off the shelf like a framework) is there are always gaps in the constraints under which they had originally been designed; so you'll always need to understand how it works under the hood. React's class-based components were simpler because the lifecycle methods were explicit, but the hook-based model is "easier"; however, the component lifecycle is still present. The demo code does look really clean, but in real life you quickly start to face the underlying complexity of the abstractions (e.g., useEffect, memoization, realizing how fine-grained your reactivity is is based on how you've drawn those component boundaries). You can write these optimizations yourself, or wait for the new auto-memoizing React compiler to land, but in all cases, the overall complexity remains the same (or is higher). And this isn't unique to React or other frameworks, and you'll always need to delve a little deeper. I agree that the DOM APIs could be more declarative (e.g., declarative custom elements proposal [1], declarative shadow DOM, `@scope` CSS as another way to scope styles), and there is activity in that space, both in the W3 Web Components Community Group and the Open UI Community Group. I'm trying to get more involved in those discussions and I'd recommend everyone who cares about the web and how we build for it to participate. I think the process of standardization for new features (through the proposals phases to finally landing in browsers) is the effort to raise the floor for all to build on top of. I remember when Promises were landing everywhere and feeling a little overwhelmed by what it meant to me because I was using Bluebird. Then the feeling of "maybe I can simplify what I'm doing and lean more on the platform" set in. Frameworks are a testbed for new ideas, and we can go further by trying to see what pieces we can pull out and standardize around (e.g., Signals proposal [2]), so we can go back to testing new ideas on top of that. [1] https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... [2] https://github.com/tc39/proposal-signals https://github.com/tc39/proposal-signals
    - apitman 2y ago
      I design my web components so they emit custom events and provide methods for parents to mutate them/trigger re-renders. This might not scale to huge apps but I don't have any interest in working on something like that.
  - haradion 2y ago
    Especially with Vue 3, most of the reactive state management you need for all but the largest and most complex of apps is built right into the core. Vuex and Pinia really aren't necessary for most users.
Jcampuzano2 2y ago
Sometimes I don't understand this argument because theres nobody forcing you to always be on the latest version of a framework. You could have just stayed on the version of Vue you were using without issues. Unless theres some compelling reason you could use it into the end of time and be just fine. Thats not to say that maybe for your use case you could have not used it in the first place or that removing the dependency was a bad idea - just that if you do like Vue there doesn't seem to be anything forcing you to always be on the latest version.
- WD-42 2y ago
  What happens when old versions stop receiving security updates?
  - Jcampuzano2 2y ago
    Rarely do security issues come from directly as a result of your choice of frontend/client framework which should really only be in charge of displaying your data. Almost all issues should be handled by your backend. Most cases where it becomes an issue is when people drop security best practices falsely believing their frontend/client validation is a security layer. Anybody thinking updating your frontend solves your security issues has deeper problems.
    - WD-42 2y ago
      > Rarely do security issues come from directly as a result of your choice of frontend/client framework Front end client frameworks now span the backend. Nextjs is the prime example. It has plenty of CVEs already.
      - Jcampuzano2 2y ago
        Well next is not a frontend framework and doesn't claim to be. Its very clearly a full stack framework. Vue by itself isn't.
        2y ago
wg0 2y ago
I'd argue that if you get the hang of it, development in Web components won't be slower than in any frameworks. So I don't understand why VC ecosystem can't get by without frameworks.
troupo 2y ago
I doubt you're authoring all web components by hand. I doubt you're not using any external dependencies.
- zelphirkalt 2y ago
  It would be good to tell us, why you doubt the GP in that regard.
  - troupo 2y ago
    Because authoring web components is pain. Because browser APIs and elements are quite limited so you're likely to pull in external deps tht provide better interfaces etc.
- apitman 2y ago
  We're not even using lit. Feel free to check out the code[0]. It's not the best (we're still learning web components) but it's working pretty well for us so far. [0]: https://github.com/iobio/bam.iobio https://github.com/iobio/bam.iobio
  - troupo 2y ago
    Thanks! I'll take a look
    - troupo 2y ago
      That's quite a commitment to write "naked" web components by hand. Kudos on keeping external deps to an absolute minimum
      - apitman 2y ago
        They're not perfect. In particular accessibility probably isn't very good. But that hasn't been as high a priority since it's a dataviz app anyway.

jitl 2y ago

If you can rewrite to remove all dependencies except for d3js, why couldn’t you do the same thing, but also retain a dependency on Vue? What is it about Vue that requires the extra dependencies - is it built system things? (I’ve never used Vue)

apitman 2y ago
Vue itself must be updated. And if you throw out the router, Vuetify, state management, etc, what is it adding above Web Components anyway?
- athanagor2 2y ago
  As far as I know there's no simple and performant way to have the DOM be a function of the state with existing standards
  - hasanhaja 2y ago
    What do you mean specifically when you say? > DOM be a function of the state I understand the benefits of the mental model, but the tooling that delivers that generally have a lot of complexity that isn't trivial to parse and understand. I think the benefit of being able to parse and understand your abstractions (ones you build yourselves or buy off the shelf like a framework) is there are always gaps in the constraints under which they had originally been designed; so you'll always need to understand how it works under the hood. React's class-based components were simpler because the lifecycle methods were explicit, but the hook-based model is "easier"; however, the component lifecycle is still present. The demo code does look really clean, but in real life you quickly start to face the underlying complexity of the abstractions (e.g., useEffect, memoization, realizing how fine-grained your reactivity is is based on how you've drawn those component boundaries). You can write these optimizations yourself, or wait for the new auto-memoizing React compiler to land, but in all cases, the overall complexity remains the same (or is higher). And this isn't unique to React or other frameworks, and you'll always need to delve a little deeper. I agree that the DOM APIs could be more declarative (e.g., declarative custom elements proposal [1], declarative shadow DOM, `@scope` CSS as another way to scope styles), and there is activity in that space, both in the W3 Web Components Community Group and the Open UI Community Group. I'm trying to get more involved in those discussions and I'd recommend everyone who cares about the web and how we build for it to participate. I think the process of standardization for new features (through the proposals phases to finally landing in browsers) is the effort to raise the floor for all to build on top of. I remember when Promises were landing everywhere and feeling a little overwhelmed by what it meant to me because I was using Bluebird. Then the feeling of "maybe I can simplify what I'm doing and lean more on the platform" set in. Frameworks are a testbed for new ideas, and we can go further by trying to see what pieces we can pull out and standardize around (e.g., Signals proposal [2]), so we can go back to testing new ideas on top of that. [1] https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... [2] https://github.com/tc39/proposal-signals https://github.com/tc39/proposal-signals
  - apitman 2y ago
    I design my web components so they emit custom events and provide methods for parents to mutate them/trigger re-renders. This might not scale to huge apps but I don't have any interest in working on something like that.
- haradion 2y ago
  Especially with Vue 3, most of the reactive state management you need for all but the largest and most complex of apps is built right into the core. Vuex and Pinia really aren't necessary for most users.

Jcampuzano2 2y ago

Sometimes I don't understand this argument because theres nobody forcing you to always be on the latest version of a framework. You could have just stayed on the version of Vue you were using without issues. Unless theres some compelling reason you could use it into the end of time and be just fine. Thats not to say that maybe for your use case you could have not used it in the first place or that removing the dependency was a bad idea - just that if you do like Vue there doesn't seem to be anything forcing you to always be on the latest version.

WD-42 2y ago
What happens when old versions stop receiving security updates?
- Jcampuzano2 2y ago
  Rarely do security issues come from directly as a result of your choice of frontend/client framework which should really only be in charge of displaying your data. Almost all issues should be handled by your backend. Most cases where it becomes an issue is when people drop security best practices falsely believing their frontend/client validation is a security layer. Anybody thinking updating your frontend solves your security issues has deeper problems.
  - WD-42 2y ago
    > Rarely do security issues come from directly as a result of your choice of frontend/client framework Front end client frameworks now span the backend. Nextjs is the prime example. It has plenty of CVEs already.
    - Jcampuzano2 2y ago
      Well next is not a frontend framework and doesn't claim to be. Its very clearly a full stack framework. Vue by itself isn't.
      - 2y ago

wg0 2y ago

I'd argue that if you get the hang of it, development in Web components won't be slower than in any frameworks. So I don't understand why VC ecosystem can't get by without frameworks.

troupo 2y ago

I doubt you're authoring all web components by hand. I doubt you're not using any external dependencies.

zelphirkalt 2y ago
It would be good to tell us, why you doubt the GP in that regard.
- troupo 2y ago
  Because authoring web components is pain. Because browser APIs and elements are quite limited so you're likely to pull in external deps tht provide better interfaces etc.
apitman 2y ago
We're not even using lit. Feel free to check out the code[0]. It's not the best (we're still learning web components) but it's working pretty well for us so far. [0]: https://github.com/iobio/bam.iobio https://github.com/iobio/bam.iobio
- troupo 2y ago
  Thanks! I'll take a look
  - troupo 2y ago
    That's quite a commitment to write "naked" web components by hand. Kudos on keeping external deps to an absolute minimum
    - apitman 2y ago
      They're not perfect. In particular accessibility probably isn't very good. But that hasn't been as high a priority since it's a dataviz app anyway.