I’m loving evey moment. It’s thousands of lines of code and dependencies removed. It’s faster.
I feel like I’m waking up from a bad fever dream that was web development for the last 10+ years. 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.
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.
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)
I've never tried this but a priori it does feel mixing all those approaches could become messy.
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.
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.
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.
Code written with the react compiler in mind will inevitably be MUCH slower without the compiler, as its not going to manually add any memoization. Likely to the point where its not going to be usable without it.
Unless maybe you want to start talking about CRDTs? But that's kind of niche, and CRDTs are actually an old conversation, one which started before React was first released. That should give you a sense at the pace of conversation for SPAs.
On an aside, SolidJS has been taking a huge momentum hit recently, I think the drop in downloads is a lagging indicator. It's not an easy space, I love SolidJS and recognize that Ryan Carniato likely took a career hit to work on Solid, but my bet is that Solid will fail to catch critical mass. Really sad as I love the Solid experience.
Where are you getting the story about hot innovation happening on the SPA side?
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?
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?
JPM is recently building greenfield SPAs using Tanner's router. I'm writing an SPA right now for drone automation platform for 1M+ population cities. I recently helped plan out a rewrite for an SPA for a vision ML startup worth 2B. For every front-facing user property that you see there are dozens more internal tooling apps backing it, from dashboards to CMS.
If you're building an SPA then Next does nothing to help you. It just gets in your way. There has been no churn for SPAs as the conversation has frozen for nearly a decade. One might point out CRDTs but that conversation began about a half decade before React was even released.
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
If you're using Django Template Language, I highly, highly recommend using https://django-cotton.com to create high level UI components to encapsulate common functionality.
Cotton is really nice!