8 ms·

You don't even need an SPA. Having the backend + frontend share the same state makes development so much faster and easier it's shockingly refreshing. When buil

by _xnmw 5y ago

You don't even need an SPA. Having the backend + frontend share the same state makes development so much faster and easier it's shockingly refreshing. When building a SaaS project last year I decided to just ditch React/Angular/Vue and did everything server-side like it was 2005. I was extremely pleased at the result -- everything feels snappy, secure, and native for the browser. I was shocked at how much time and headache I saved: not having to design/deploy an API and all the trimmings (ACLs, CORS, JWTs etc.), not having to spend X hours a day wrestling with Webpack/hot reloading/npm/tree-shaking/state management, having direct access to backend secrets/state/APIs and just spitting out HTML, it's just so....lovely. It simplifies performance tuning as well, the only thing I need to optimize is the server, which is easy to do because I have 100% control and visibility, compared to debugging/optimizing JavaScript for a million different clients.

southerntofu 5y ago
And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). It's really the best way to do things: SPAs are great for applications, but for 99% of websites server-side rendering only has advantages.
- Spivak 5y ago
  Wait what? Other than "the client blocks JS" which is niche beyond niche the SPA is the one that actually performs better with a spotty network. Fully offline or "occasionally connected" is half the reason to use an SPA. Just as an example once downloaded FB messenger is fully functional over an unreliable network.
  - marcosdumay 5y ago
    Hum... I have never seen a SPA perform well with a spotty network. Yeah, I get what you are trying to get, that an SPA can retry failures, prioritize resources better, reload less data... They just never do that competently, as it is a shitload of work, and the "once downloaded" part is irrelevant, because people only ever load a couple of pages on most sites visits.
  - southerntofu 5y ago
    Did you try it? Try with 256Kb/s and 20% packet loss (and if your networking tooling allows it, bursts of >1s downtime every 20s) and tell me which one performs better. Yes that's actual conditions in which many people access the Internet in 2021 whether it's on cellular or crappy xDSL. I've yet to see a single SPA that can deal with such conditions, while native HTML/CSS will work like a breeze in any web browser. For bonus points, browser UI can tell you which requests take a long time and/or refresh any page while maintaining a cache, something most SPAs are really bad at doing, and you get SEO/interoperability for free due to your markup being a curl call away from any client.
- fivea 5y ago
  > And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). What? No. Not at all. If you're behind a subpar network, your dynamic HTML web app does not load/refresh/update at all, and your users start to get frustrated because your crappy webpage is broken and fails to even do the most basic things. This is not the case with SPAs, and some of the most pressing problems they solve: perceived performance, resilience to faulty network connections, and overall improved UX. Let's put it this way: with SPAs you can design your app to work even without a working network connection. That's how resilient SPAs are to networking issues. How do you pull that off with dynamic HTML? > but for 99% of websites server-side rendering only has advantages. No, not really. Unless you cherry-pick what goes into the 99%, even basic CRUD, form-driven pages the dynamic HTML way suffers from a multitude of drawbacks that are no longer issues in SPAs, both technical and organizational.
  - scns 5y ago
    > If you're behind a subpar network There is a (high) probability users will close the tab after waiting for over a minute for MBs of JS to download and parse.
    - cerved 5y ago
      in an SPA, that's cached, so not the second time
      - acdha 5y ago
        Have you measured this carefully? All of yours users will notice it on the first visit, so you need to think about that first impression but it’s also rarely the case that people load your page so frequently that everything stays in the cache forever. Mobile devices have small caches which purge more frequently than most developers think and that’s also true of CDN nodes, and continuous deployment acts as a ceiling for long-term caching. When I’ve measured this for real users on moderately busy sites (6 figure daily users, not Google-scale) the reported first page load times tracked the cold cache times for most users (70+%) even for people who’d visited before. If they were geographically clustered (news story, etc.) the cache hits on CDN nodes would be high but you couldn’t count on that.
cbm-vic-20 5y ago
And the thin/thick client/server wheel continues to turn.
hiitechk 5y ago
What did you use for your back-end and for spitting out the HTML?
- deleted 5y ago
  [deleted]
- _xnmw 5y ago
  Laravel. I have no particular love for PHP, but Laravel just "gets it right" and understands the needs of a web developer. After years of working with Python/NodeJS (Flask/Express), Laravel was like a key that fit a lock. The ecosystem of paid plugins and services around it are really well built as well.
  - midrus 5y ago
    I've always said that frameworks, tools, ecosystem, libraries, community, etc are far, far, far more important than the programming language. Also, nowadays PHP is not 10 year's ago PHP, same as nowadays's JavaScript is not 10 year's ago JavaScript. They're both "ok" languages to me. And yes, having used for many years Django, some playing with Rails on the side, and then everything under the sun for Node, I 100% agree Laravel is freaking awesome and I really wish I had discovered it earlier.
th5 5y ago
I prefer laravel as well but it’s definitely not as snappy as an spa since I have to load a full page of html at each click. What are you doing differently that I should be doing? Currently, I’m doing a hybrid sometimes where I’ll have jquery do a call inside the page when I want one particular area to be fast.
- _xnmw 5y ago
  KISS. Keep the HTML minimal and the full page reload is often just as fast as an AJAX call. For the parts that need to be realtime/interactive I use Livewire. Livewire is annoying to work with sometimes, and the author got carried away with that whole AlpineJS nonsense (reinventing the whole problem), and Livewire is still immature, but the basics work well (just keep your Livewire components extremely simple and it works great).
  - datavirtue 5y ago
    Yeah, I cant count how many times I have seen SPAs have tons of calls to an endpoint that passes back huge amount of data when the client needed a single property from the response. This can get artificially bad in large companies that require devs to onboard each endpoint through an API exchange/gateway...because they avoid creating new endpoints.
- kroltan 5y ago
  Keep your markup lean, serve styles separately so they can be cached.
- Joeri 5y ago
  Take a look at the tall stack. It abstracts away the js that does partial page updates. https://tallstack.dev/ https://tallstack.dev/
- speg 5y ago
  Check out htmx. I use it for thing like table pagination. Server side I check for htmx headers, and if so omit headers/footers are just return the body. htmx then handles the html swap and boom, you’ve just turned the page without reloading the whole page. Simple and straightforward. I also use a plugin to preload the responses on mouseover in some cases for even more snapiness.
Zenbit_UX 5y ago
I love when devs blow off SPAs because they think they're geniuses or above JS. You spun up a shitty 1995 style site that every menu on the toolbar triggers a page reload and patted yourself on the back. Congrats on sending the same html and css with every page load, I'm sure your low network speed users love it. Eureka exclaimed the "full-stack" developer, who needs javascript!?
- echelon 5y ago
  The HTML is probably smaller than the JavaScript blob. If you can get the HTML within the same order of magnitude as JSON itself, then it's perhaps a compelling argument to ditch SPAs. The bandwidth delta would be minimal, and the development overhead would be much less substantial. Note that this is how the web used to be. Small HTML markup. We even started baking structured meaning into the HTML (Semantic Web, "Web 3.0") so that documents could be consumed like APIs. But then JSON and the platform giants put an end to p2p web payloads and rich document schemas. That was a mistake.
- midrus 5y ago
  Probably you're not aware yet that there are also "modern ways" to do server side templates/html. Nowadays you have things such as Unpoly, Htmx, Hotwire, Livewire, etc which can be added incrementaly to any traditional MVC applications leading to an incredible reduction in the amount of work necessary to ship something robust if you're a single developer or in a small team. SPAs can be great for large teams with different skills/profiles, and large companies with a lot of money though.
  - gime_tree_fiddy 5y ago
    Unfortunately, this kind of discussion ends up turning into a knife fight these days here. I tried using HTMX recently for mainly a CRUD app for personal use, with limited dynamic loading. Still felt the need to rely on JS(Jquery) for loading images and triggering refresh on list of items without full page reload[1]. Did a small A/B test from dev POV using Vue.js, as it is one of the more lighter frameworks. Ended up leaning more towards Vue.js, as had to do some non-conventional(from HTMX POV)[1] things for a simple CRUD app not relying on full page loads/refreshes. Hopefully there is another step in this evolution.
rattlesnakedave 5y ago
Why does this always come up? Maybe the author does need the SPA. This comment does not seem particularly relevant to the contents of the article.
- _xnmw 5y ago
  CORS is just one more problem from the class of performance problems that only SPAs have. Seems very relevant to me.
  - rattlesnakedave 5y ago
    > only SPAs have That’s a bold claim.
- lostcolony 5y ago
  Because if you're re-examining your need of CORS and evaluating whether it makes sense to instead host everything from the same host, you can also re-examine your need of an SPA and evaluate whether it makes sense to instead just render everything server side; it'll solve even more problems if you can.
  - rattlesnakedave 5y ago
    > it'll solve even more problems Wow. Why doesn’t everyone do this?
    - _xnmw 5y ago
      Actually, a lot of people do. Ever heard of Laravel, Django or Ruby or Rails? Outside of the React/JS world, a lot of developers are happy solving real business problems instead of working with hacks that were built on top of browser DOMs.
      - rattlesnakedave 5y ago
        That’s great to hear. Hopefully I can grow up to be one of them some day.
kansface 5y ago
No contract between the front and back end is obviously an extremely tight coupling. I’ve seen this end really badly when you have to cleave them after the fact (particularly with embedded JS in server side templating). For a small product without much velocity, I’d be OK with the approach.
antoaravinth 5y ago
This is exactly, what I wanted the frontend developers to do. Junior developers introduce new library/framework just because it looks "cool to work with", later it becomes a problem, which will then be replaced by another library (its a endless loop these days).

by _xnmw 5y ago

southerntofu 5y ago

And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). It's really the best way to do things: SPAs are great for applications, but for 99% of websites server-side rendering only has advantages.

Spivak 5y ago
Wait what? Other than "the client blocks JS" which is niche beyond niche the SPA is the one that actually performs better with a spotty network. Fully offline or "occasionally connected" is half the reason to use an SPA. Just as an example once downloaded FB messenger is fully functional over an unreliable network.
- marcosdumay 5y ago
  Hum... I have never seen a SPA perform well with a spotty network. Yeah, I get what you are trying to get, that an SPA can retry failures, prioritize resources better, reload less data... They just never do that competently, as it is a shitload of work, and the "once downloaded" part is irrelevant, because people only ever load a couple of pages on most sites visits.
- southerntofu 5y ago
  Did you try it? Try with 256Kb/s and 20% packet loss (and if your networking tooling allows it, bursts of >1s downtime every 20s) and tell me which one performs better. Yes that's actual conditions in which many people access the Internet in 2021 whether it's on cellular or crappy xDSL. I've yet to see a single SPA that can deal with such conditions, while native HTML/CSS will work like a breeze in any web browser. For bonus points, browser UI can tell you which requests take a long time and/or refresh any page while maintaining a cache, something most SPAs are really bad at doing, and you get SEO/interoperability for free due to your markup being a curl call away from any client.
fivea 5y ago
> And as a bonus, your site works perfectly in degraded environments (poor network conditions, no JS runtime). What? No. Not at all. If you're behind a subpar network, your dynamic HTML web app does not load/refresh/update at all, and your users start to get frustrated because your crappy webpage is broken and fails to even do the most basic things. This is not the case with SPAs, and some of the most pressing problems they solve: perceived performance, resilience to faulty network connections, and overall improved UX. Let's put it this way: with SPAs you can design your app to work even without a working network connection. That's how resilient SPAs are to networking issues. How do you pull that off with dynamic HTML? > but for 99% of websites server-side rendering only has advantages. No, not really. Unless you cherry-pick what goes into the 99%, even basic CRUD, form-driven pages the dynamic HTML way suffers from a multitude of drawbacks that are no longer issues in SPAs, both technical and organizational.
- scns 5y ago
  > If you're behind a subpar network There is a (high) probability users will close the tab after waiting for over a minute for MBs of JS to download and parse.
  - cerved 5y ago
    in an SPA, that's cached, so not the second time
    - acdha 5y ago
      Have you measured this carefully? All of yours users will notice it on the first visit, so you need to think about that first impression but it’s also rarely the case that people load your page so frequently that everything stays in the cache forever. Mobile devices have small caches which purge more frequently than most developers think and that’s also true of CDN nodes, and continuous deployment acts as a ceiling for long-term caching. When I’ve measured this for real users on moderately busy sites (6 figure daily users, not Google-scale) the reported first page load times tracked the cold cache times for most users (70+%) even for people who’d visited before. If they were geographically clustered (news story, etc.) the cache hits on CDN nodes would be high but you couldn’t count on that.

cbm-vic-20 5y ago

And the thin/thick client/server wheel continues to turn.

hiitechk 5y ago

What did you use for your back-end and for spitting out the HTML?

deleted 5y ago
[deleted]
_xnmw 5y ago
Laravel. I have no particular love for PHP, but Laravel just "gets it right" and understands the needs of a web developer. After years of working with Python/NodeJS (Flask/Express), Laravel was like a key that fit a lock. The ecosystem of paid plugins and services around it are really well built as well.
- midrus 5y ago
  I've always said that frameworks, tools, ecosystem, libraries, community, etc are far, far, far more important than the programming language. Also, nowadays PHP is not 10 year's ago PHP, same as nowadays's JavaScript is not 10 year's ago JavaScript. They're both "ok" languages to me. And yes, having used for many years Django, some playing with Rails on the side, and then everything under the sun for Node, I 100% agree Laravel is freaking awesome and I really wish I had discovered it earlier.

th5 5y ago

I prefer laravel as well but it’s definitely not as snappy as an spa since I have to load a full page of html at each click. What are you doing differently that I should be doing? Currently, I’m doing a hybrid sometimes where I’ll have jquery do a call inside the page when I want one particular area to be fast.

_xnmw 5y ago
KISS. Keep the HTML minimal and the full page reload is often just as fast as an AJAX call. For the parts that need to be realtime/interactive I use Livewire. Livewire is annoying to work with sometimes, and the author got carried away with that whole AlpineJS nonsense (reinventing the whole problem), and Livewire is still immature, but the basics work well (just keep your Livewire components extremely simple and it works great).
- datavirtue 5y ago
  Yeah, I cant count how many times I have seen SPAs have tons of calls to an endpoint that passes back huge amount of data when the client needed a single property from the response. This can get artificially bad in large companies that require devs to onboard each endpoint through an API exchange/gateway...because they avoid creating new endpoints.
kroltan 5y ago
Keep your markup lean, serve styles separately so they can be cached.
Joeri 5y ago
Take a look at the tall stack. It abstracts away the js that does partial page updates. https://tallstack.dev/ https://tallstack.dev/
speg 5y ago
Check out htmx. I use it for thing like table pagination. Server side I check for htmx headers, and if so omit headers/footers are just return the body. htmx then handles the html swap and boom, you’ve just turned the page without reloading the whole page. Simple and straightforward. I also use a plugin to preload the responses on mouseover in some cases for even more snapiness.

Zenbit_UX 5y ago

I love when devs blow off SPAs because they think they're geniuses or above JS. You spun up a shitty 1995 style site that every menu on the toolbar triggers a page reload and patted yourself on the back. Congrats on sending the same html and css with every page load, I'm sure your low network speed users love it. Eureka exclaimed the "full-stack" developer, who needs javascript!?

echelon 5y ago
The HTML is probably smaller than the JavaScript blob. If you can get the HTML within the same order of magnitude as JSON itself, then it's perhaps a compelling argument to ditch SPAs. The bandwidth delta would be minimal, and the development overhead would be much less substantial. Note that this is how the web used to be. Small HTML markup. We even started baking structured meaning into the HTML (Semantic Web, "Web 3.0") so that documents could be consumed like APIs. But then JSON and the platform giants put an end to p2p web payloads and rich document schemas. That was a mistake.
midrus 5y ago
Probably you're not aware yet that there are also "modern ways" to do server side templates/html. Nowadays you have things such as Unpoly, Htmx, Hotwire, Livewire, etc which can be added incrementaly to any traditional MVC applications leading to an incredible reduction in the amount of work necessary to ship something robust if you're a single developer or in a small team. SPAs can be great for large teams with different skills/profiles, and large companies with a lot of money though.
- gime_tree_fiddy 5y ago
  Unfortunately, this kind of discussion ends up turning into a knife fight these days here. I tried using HTMX recently for mainly a CRUD app for personal use, with limited dynamic loading. Still felt the need to rely on JS(Jquery) for loading images and triggering refresh on list of items without full page reload[1]. Did a small A/B test from dev POV using Vue.js, as it is one of the more lighter frameworks. Ended up leaning more towards Vue.js, as had to do some non-conventional(from HTMX POV)[1] things for a simple CRUD app not relying on full page loads/refreshes. Hopefully there is another step in this evolution.

rattlesnakedave 5y ago

Why does this always come up? Maybe the author does need the SPA. This comment does not seem particularly relevant to the contents of the article.

_xnmw 5y ago
CORS is just one more problem from the class of performance problems that only SPAs have. Seems very relevant to me.
- rattlesnakedave 5y ago
  > only SPAs have That’s a bold claim.
lostcolony 5y ago
Because if you're re-examining your need of CORS and evaluating whether it makes sense to instead host everything from the same host, you can also re-examine your need of an SPA and evaluate whether it makes sense to instead just render everything server side; it'll solve even more problems if you can.
- rattlesnakedave 5y ago
  > it'll solve even more problems Wow. Why doesn’t everyone do this?
  - _xnmw 5y ago
    Actually, a lot of people do. Ever heard of Laravel, Django or Ruby or Rails? Outside of the React/JS world, a lot of developers are happy solving real business problems instead of working with hacks that were built on top of browser DOMs.
    - rattlesnakedave 5y ago
      That’s great to hear. Hopefully I can grow up to be one of them some day.

kansface 5y ago

No contract between the front and back end is obviously an extremely tight coupling. I’ve seen this end really badly when you have to cleave them after the fact (particularly with embedded JS in server side templating). For a small product without much velocity, I’d be OK with the approach.

antoaravinth 5y ago

This is exactly, what I wanted the frontend developers to do. Junior developers introduce new library/framework just because it looks "cool to work with", later it becomes a problem, which will then be replaced by another library (its a endless loop these days).