6 ms·

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

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.
    - spion 2y ago
      Important or not, libraries you depend on may jump on it and abandon backward compatibility
      - jemmyw 2y ago
        They may. One of the promises of the compiler though is that you don't need to change how you write your code. It will determine how to run.
threatofrain 2y ago
The state of the art moves way faster for MPA / hybrid. Way way faster. Next.js, Nuxt, etc. are strictly more things to learn and keep track of, both technically and practically. Almost all the recent innovation for the last half decade has been about MPA and hybrid apps. Where are you getting the story about hot innovation happening on the SPA side?
- aaronbrethorst 2y ago
  I have absolutely no idea what you’re asking me.
  - threatofrain 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. The churn that people complain about is coming from the MPA/hybrid side. Where do you get this idea that you're seeing way more innovation on the SPA side?
    - WD-42 2y ago
      It’s the same churn. What was once create react app is now next.js If you go to the official react website now it recommends next.js as a starting point for react development. It’s just what SPAs evolved into.
      - threatofrain 2y ago
        It's not the same churn. SPA conversation has largely frozen. Anyone writing SPAs using vanilla React would be seeing a flurry of conversation go by that's specifically not about them — for the last 8 years. Next is a headache if you specifically want a pure SPA. It's not the evolution of SPA, it's a counter-response to too much early focus on SPA and not enough on front-facing MPA and hybrid apps. That's why Next exploded. Where are people even experiencing conversations on SPA architecture? What is the most popular discussion on SPA right now? On the other side I'd say RSC, React Compiler, isomorphic components, keeping server secrets away from client, hydration, streaming, or whether to eliminate all client state, are all hot topics right now for MPA/hybrid. So where and what are the hot conversations for SPA? Where is the churn? What are some hot YouTubers talking about new developments in SPA?
Swizec 2y ago
> 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. I have not found this to be true in almost 15 years of doing this[1]. Would be very curious to hear where you’ve found that you have to build the app twice. Typically my approach has been to put Serious Business Logic on the server behind an API. This lets you contain all the important stuff in one place and ensure a ground truth for all your clients (web, mobile, BI, 3rd party integrations, async jobs, etc). You build this once. Then the client acts as a pretty interface for all this same data. Anything that smells like business logic, you put on the server and call an API. You also build this once because you’re not building any of it on the server. Those secondary clients (BI, 3rd party integrations, async jobs, etc) are also where MPAs built on next+rpc or django and friends start falling apart. They’re not gonna load your webpage and parse the html or run the JS you sprinkled on top. You’re gonna have to build an API anyway. At that point you may as well make sure that all your clients talk to the same ground truth business logic so your API and your MPA turn into thin layers on top of core business services. Congratz, now your MPA is essentially an SPA that runs on the server and you have a backend-for-frontend. You’re just making API calls on the server and not taking advantage of your visitor’s globally distributed compute and bandwidth. But it does make auth/secrets easier because you can mostly trust the server-client. [1] Seriously, one of my earliest talks was on this newfangled thing called Backbone and how SPAs solve common problems we had with web tech back then (~2011). It’s in Slovenian though

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.
  - spion 2y ago
    Important or not, libraries you depend on may jump on it and abandon backward compatibility
    - jemmyw 2y ago
      They may. One of the promises of the compiler though is that you don't need to change how you write your code. It will determine how to run.

threatofrain 2y ago

The state of the art moves way faster for MPA / hybrid. Way way faster. Next.js, Nuxt, etc. are strictly more things to learn and keep track of, both technically and practically. Almost all the recent innovation for the last half decade has been about MPA and hybrid apps. Where are you getting the story about hot innovation happening on the SPA side?

aaronbrethorst 2y ago
I have absolutely no idea what you’re asking me.
- threatofrain 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. The churn that people complain about is coming from the MPA/hybrid side. Where do you get this idea that you're seeing way more innovation on the SPA side?
  - WD-42 2y ago
    It’s the same churn. What was once create react app is now next.js If you go to the official react website now it recommends next.js as a starting point for react development. It’s just what SPAs evolved into.
    - threatofrain 2y ago
      It's not the same churn. SPA conversation has largely frozen. Anyone writing SPAs using vanilla React would be seeing a flurry of conversation go by that's specifically not about them — for the last 8 years. Next is a headache if you specifically want a pure SPA. It's not the evolution of SPA, it's a counter-response to too much early focus on SPA and not enough on front-facing MPA and hybrid apps. That's why Next exploded. Where are people even experiencing conversations on SPA architecture? What is the most popular discussion on SPA right now? On the other side I'd say RSC, React Compiler, isomorphic components, keeping server secrets away from client, hydration, streaming, or whether to eliminate all client state, are all hot topics right now for MPA/hybrid. So where and what are the hot conversations for SPA? Where is the churn? What are some hot YouTubers talking about new developments in SPA?

Swizec 2y ago

> 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. I have not found this to be true in almost 15 years of doing this[1]. Would be very curious to hear where you’ve found that you have to build the app twice. Typically my approach has been to put Serious Business Logic on the server behind an API. This lets you contain all the important stuff in one place and ensure a ground truth for all your clients (web, mobile, BI, 3rd party integrations, async jobs, etc). You build this once. Then the client acts as a pretty interface for all this same data. Anything that smells like business logic, you put on the server and call an API. You also build this once because you’re not building any of it on the server. Those secondary clients (BI, 3rd party integrations, async jobs, etc) are also where MPAs built on next+rpc or django and friends start falling apart. They’re not gonna load your webpage and parse the html or run the JS you sprinkled on top. You’re gonna have to build an API anyway. At that point you may as well make sure that all your clients talk to the same ground truth business logic so your API and your MPA turn into thin layers on top of core business services. Congratz, now your MPA is essentially an SPA that runs on the server and you have a backend-for-frontend. You’re just making API calls on the server and not taking advantage of your visitor’s globally distributed compute and bandwidth. But it does make auth/secrets easier because you can mostly trust the server-client. [1] Seriously, one of my earliest talks was on this newfangled thing called Backbone and how SPAs solve common problems we had with web tech back then (~2011). It’s in Slovenian though