4 ms·

I think he's fundamentally right even if he's wrong about certain details. SPA create a polarization between devs whereby they're either front end or backend.

I think he's fundamentally right even if he's wrong about certain details. SPA create a polarization between devs whereby they're either front end or backend. Full stack devs are slowed down compared to tools like Hotwire/Turbo, Liveview, HTMX, etc.. Furthermore you need a huge stack of tooling to make pages work and lots of javascript code needs to be downloaded to make most standard SPAs work today. Not to mention having to render html on the backend in a slower and more complicated manner than using any of the more recent enhancements of HTML that provide caching, high speed download out of the box.

mdasen 3y ago
This is probably correct...for now. However, I think the next decade will see SPAs become simpler and we're already starting to see it. In some ways, I'd argue that Livewire is an example of that. I think Remix (JS) offers a full-stack experience where you just create an `action` function of what you want run on the server. Remix can be pre-rendered on the server so pages don't need to download lots of JS before stuff is displayed to the user for the initial page load. I think WebAssembly is also going to be bringing innovations. .NET's Blazor is probably the furthest along at this point and it allows you to create an app that's rendered on the server and then WASM is downloaded in the background to enable all the interactivity. It can also operate like Livewire with websockets if you prefer. While Blazor might be here today, we'll probably see more coming. Rust's Leptos looks really cool and allows you to use its `#[server]` macro to define functions to be run on the server instead of the browser. I think that we're going to start seeing better options for creating SPAs without needing to maintain two separate codebases.