6 ms·

> What were we thinking? You can make a mess or not a mess in any framework. The tech is not the problem. I bet in a few years you’ll have just as big a mess

by Swizec 2y ago

> What were we thinking? You can make a mess or not a mess in any framework. The tech is not the problem. I bet in a few years you’ll have just as big a mess with alpine+htmx as you do right now with vue+rest. Ultimately the only thing that matters is having clear interfaces, well defined modules, and the discipline to keep it clean. The rest is all window dressing. PS: SPAs were invented for a world where server compute and bandwidth are expensive and/or you need highly interactive low-latency UX. They were never meant for mostly static websites that are cheap to generate and cache.

WD-42 2y ago
I don't think it's going to be the same situation at all. First of all, the reason why I'm doing it in the first place is because Vue2 is completely deprecated. It's not even getting security updates, and migrating to Vue3 is such a hassle it's not worth it. This is a major maintainability issue. Now the new "stack" has about 5 JS dependencies total, all of which are very low surface area. It doesn't even require a build step. And Django is not going anywhere.
aaronbrethorst 2y ago
You can definitely make a mess with any technology. The key issues I have with SPAs are: 1. You have to build your app twice. I don't have a team large enough to write it once in Python and again in JS or TS. 2. The state of the art in SPAs moves so quickly it feels to me like you have to spend a significant amount of your productive time staying in place on the treadmill before you can even consider creating value for your end users. 3. The web browser does a lot of work for us in SSRs. SPAs make (have historically made) us reinvent a lot of this from scratch. I recognize that this has improved in some ways in recent years. It's still not as brain-dead simple as just having different web pages that render HTML. SPAs were invented for a world where server compute and bandwidth are expensive and/or you need highly interactive low-latency UX Agree completely. I think there is a ton of value in treating technologies like Svelte, React, and the like as terrific ways to create 'islands of reactivity' within mostly static pages. I can do a ton with Stimulus.js and htmx to simulate much of the behavior I'd get out of a well-designed Svelte component, but sometimes I really do need that extra 20% of polish I'll get out of Svelte or React—and I'm very glad that they exist for that. (and with that I'm going to get back to building a SvelteKit app, which you can find here: https://github.com/onebusaway/wayfinder https://github.com/onebusaway/wayfinder)
- pier25 2y ago
  What happens when there's overlap between the islands and /or Stimulus and/or htmx? I've never tried this but a priori it does feel mixing all those approaches could become messy.
  - aaronbrethorst 2y ago
    The only situation I've run into that is a bit of a mess is trying to reconcile loading a React dashboard chart thingy (https://tremor.so https://tremor.so) in a Rails web app where I'm using Turbo Drive to mediate page transitions—and that just required some careful reading of the documentation to reconcile.
- jemmyw 2y ago
  > 2. The state of the art in SPAs moves so quickly it feels to me like you have to spend a significant amount of your productive time staying in place on the treadmill before you can even consider creating value for your end users. I think this is no longer true, not how it used to be. Of course, you CAN chase the latest cool. However, if you stick with one of the more popular libraries then things should be stable. My react code now doesn't look very different to my react code in 2019. They've added new things but I haven't used them.
  - spion 2y ago
    > My react code now doesn't look very different to my react code in 2019 Server components, Next application directory breaking emotion for styling, stricter rules for hooks, the compiler breaking change tracking libraries such as MobX removing the need for useMemo and similar. This is just off the top of my head in React land.
    - jemmyw 2y ago
      > Server components Nope, not using. > Next application directory breaking emotion for styling I'm not even sure what this is. > stricter rules for hooks I've always been strict with the code, no changes have been required. > the compiler The compiler is still in beta, I've not even tried it, let alone let it near production code. I'm not that excited by it tbh. So you've pretty much confirmed what I said. None of these things were that important to jump on.

by Swizec 2y ago

WD-42 2y ago

I don't think it's going to be the same situation at all. First of all, the reason why I'm doing it in the first place is because Vue2 is completely deprecated. It's not even getting security updates, and migrating to Vue3 is such a hassle it's not worth it. This is a major maintainability issue. Now the new "stack" has about 5 JS dependencies total, all of which are very low surface area. It doesn't even require a build step. And Django is not going anywhere.

aaronbrethorst 2y ago

You can definitely make a mess with any technology. The key issues I have with SPAs are: 1. You have to build your app twice. I don't have a team large enough to write it once in Python and again in JS or TS. 2. The state of the art in SPAs moves so quickly it feels to me like you have to spend a significant amount of your productive time staying in place on the treadmill before you can even consider creating value for your end users. 3. The web browser does a lot of work for us in SSRs. SPAs make (have historically made) us reinvent a lot of this from scratch. I recognize that this has improved in some ways in recent years. It's still not as brain-dead simple as just having different web pages that render HTML. SPAs were invented for a world where server compute and bandwidth are expensive and/or you need highly interactive low-latency UX Agree completely. I think there is a ton of value in treating technologies like Svelte, React, and the like as terrific ways to create 'islands of reactivity' within mostly static pages. I can do a ton with Stimulus.js and htmx to simulate much of the behavior I'd get out of a well-designed Svelte component, but sometimes I really do need that extra 20% of polish I'll get out of Svelte or React—and I'm very glad that they exist for that. (and with that I'm going to get back to building a SvelteKit app, which you can find here: https://github.com/onebusaway/wayfinder https://github.com/onebusaway/wayfinder)

pier25 2y ago
What happens when there's overlap between the islands and /or Stimulus and/or htmx? I've never tried this but a priori it does feel mixing all those approaches could become messy.
- aaronbrethorst 2y ago
  The only situation I've run into that is a bit of a mess is trying to reconcile loading a React dashboard chart thingy (https://tremor.so https://tremor.so) in a Rails web app where I'm using Turbo Drive to mediate page transitions—and that just required some careful reading of the documentation to reconcile.
jemmyw 2y ago
> 2. The state of the art in SPAs moves so quickly it feels to me like you have to spend a significant amount of your productive time staying in place on the treadmill before you can even consider creating value for your end users. I think this is no longer true, not how it used to be. Of course, you CAN chase the latest cool. However, if you stick with one of the more popular libraries then things should be stable. My react code now doesn't look very different to my react code in 2019. They've added new things but I haven't used them.
- spion 2y ago
  > My react code now doesn't look very different to my react code in 2019 Server components, Next application directory breaking emotion for styling, stricter rules for hooks, the compiler breaking change tracking libraries such as MobX removing the need for useMemo and similar. This is just off the top of my head in React land.
  - jemmyw 2y ago
    > Server components Nope, not using. > Next application directory breaking emotion for styling I'm not even sure what this is. > stricter rules for hooks I've always been strict with the code, no changes have been required. > the compiler The compiler is still in beta, I've not even tried it, let alone let it near production code. I'm not that excited by it tbh. So you've pretty much confirmed what I said. None of these things were that important to jump on.