4 ms·

The current SPA vs MPA debate is conflating multiple things, when really I think the current trend isn't a move away from SPAs, it's a move towards server side

The current SPA vs MPA debate is conflating multiple things, when really I think the current trend isn't a move away from SPAs, it's a move towards server side rendering. Server side rendering is completely compatible with a SPA architecture, thats exactly what tools like Hotwire/Turbolinks and Livewire are doing, and in many ways makes it easer and more light weight. I believe the current frustration is with having to build APIs as a bridge between your backend and frontend with many of these JS SPA toolkits. With a server rendered "html on the wire" type architecture you don't need to build flexible apis. No need to plan ahead what you need, no more separate API authentication (at an object level), fewer moving parts in your stack. I think the future (for a large subset of website/apps) are frameworks that take a "hybrid" component approach, where you are defining in one place your sever and client code. If you open up a simple automatic bridge on the component level between back and frontend you remove an awful lot of leg work from building a site. There is always going to be a need for all these different architectures though, there will never be "one true solution". (Disclaimer, I'm building a hybrid component toolkit called Tetra http://tetraframework.com http://tetraframework.com, so I'm somewhat biased)

em-bee 4y ago
the API is exactly why i love SPAs. remember the good old days when desktop applications were common? to me, creating an SPA feels exactly like writing a desktop app. i have a backend that does everything i need for a server, and i write a client, that accesses that server through its API. it's very clean and easy to manage. in my case i haven't been doing any backend coding for half a decade, because there is nothing left to be done. i just write client after client after client that does whatever is needed, using the backend as storage for state and data. it's so easy now. i can write multiple different clients that access the same data. i don't even have to write browser based clients. i can actually write true desktop clients, and they too are able to access the same data through the same API. need a mobile frontend? no problem either. in fact even for applications where an SPA is supposedly not suitable, i am still going to make it an SPA because otherwise i'd have to create a new backend instead of reusing the one i already have. so for me an SPA is now the cheapest, most efficient way to build any webinterface. so yeah, SPAs will persist.

em-bee 4y ago

the API is exactly why i love SPAs. remember the good old days when desktop applications were common? to me, creating an SPA feels exactly like writing a desktop app. i have a backend that does everything i need for a server, and i write a client, that accesses that server through its API. it's very clean and easy to manage. in my case i haven't been doing any backend coding for half a decade, because there is nothing left to be done. i just write client after client after client that does whatever is needed, using the backend as storage for state and data. it's so easy now. i can write multiple different clients that access the same data. i don't even have to write browser based clients. i can actually write true desktop clients, and they too are able to access the same data through the same API. need a mobile frontend? no problem either. in fact even for applications where an SPA is supposedly not suitable, i am still going to make it an SPA because otherwise i'd have to create a new backend instead of reusing the one i already have. so for me an SPA is now the cheapest, most efficient way to build any webinterface. so yeah, SPAs will persist.