5 ms·

What's confusing you? (not in a hostile way, genuinely curious) Server side rendering is challenging to do correctly for any app with transient state, inter-ap

What's confusing you? (not in a hostile way, genuinely curious) Server side rendering is challenging to do correctly for any app with transient state, inter-app navigation can be slow, it has user experience challenges around interactivity. It also has advantages, like providing a more resilient history stack and a faster initial render. There's no one reason why an app would choose a SPA over a "traditional" SSR app, but there are definitely advantages and disadvantages to both. It shouldn't be a surprise that many web apps, especially ones with a lot of client state to manage or a high level of interactivity, find SPA a more attractive option. Sure, there are definitely examples of overzealous SPAs (cough Reddit cough), but there are also plenty of complex sites that are being SSR'd and that hurt for the interactivity and intra-app navigation speed of a SPA (thinking about kludgy enterprise software). Ultimately, for most projects of any significant size, you end up using both in some way. Lots of companies will use a static site, CMS, or simple SSR'd app to handle "front-of-house" concerns - homepage, marketing, blog, login page. The main app will typically be a SPA.

pdimitar 7y ago
> Server side rendering is challenging to do correctly for any app with transient state, inter-app navigation can be slow, it has user experience challenges around interactivity. - What's an inter-app navigation btw? I honestly don't know. - Transient states have never been a problem in my backender career for 18 years. Only when somebody figures it's a good idea to dump a raw object with 3 levels of preloaded associations in an HTTP session, which they quickly learn to never do again (cookie size limits). - UX challenges around interactivity can and are handled very nicely by being strictly an SSR project and sprinkle Vue.JS where it makes sense, with impressive results. (Sure, some projects need the complexity and the machinery of React, I am not denying that.) --- As for raw speed, well, maybe it's time to start admitting Python Django and Ruby on Rails aren't that fast then, is it? PHP's Laravel is okay due to PHP 7 mostly, and due to diligent pursuit of performance, for which their team deserves a round of applause. Node.JS is also okay however its struggle to properly utilize all CPU cores and the finicky evented I/O stack that crumbles under not-that-big-a-pressure are a turn off. I started working with Elixir's Phoenix ~3.5 years ago and only had apps return in more than 5ms when you do complex SQL queries (which part of the time can be alleviated with query optimisation). While Rails' ActiveRecord easily swallows 150-200ms just serializing and deserializing from/to the DB, on an i7 CPU! Python's Django is better, but not by much. Laravel is OK but still not that impressive in 2020, when commodity i3/i5 CPUs ace various real-world benchmarks otherwise. --- My point here is: Let's not conflate "most SSR frameworks are crap and are written in slow languages" with the more general "SSR is slow". No, it really isn't, if using the right tools. Most web projects in my life could have been served from a Raspberry Pi 4 and written in Elixir's Phoenix and never break a sweat (maybe you'll need to attach an SSD though, because microSD cards are usually breaking easily). (Or Rust's Rocket, which makes you feel like you are visiting a static HTML page. It's that fast.) Elixir has, on average, 1% to 3% overhead, while Rust's is hard to even measure (likely 0.1% or below). So 97% to 99.9% of the time, those languages' web frameworks simply wait on I/O. And that's not the case with the vast majority of web frameworks out there, sadly.

pdimitar 7y ago

> Server side rendering is challenging to do correctly for any app with transient state, inter-app navigation can be slow, it has user experience challenges around interactivity. - What's an inter-app navigation btw? I honestly don't know. - Transient states have never been a problem in my backender career for 18 years. Only when somebody figures it's a good idea to dump a raw object with 3 levels of preloaded associations in an HTTP session, which they quickly learn to never do again (cookie size limits). - UX challenges around interactivity can and are handled very nicely by being strictly an SSR project and sprinkle Vue.JS where it makes sense, with impressive results. (Sure, some projects need the complexity and the machinery of React, I am not denying that.) --- As for raw speed, well, maybe it's time to start admitting Python Django and Ruby on Rails aren't that fast then, is it? PHP's Laravel is okay due to PHP 7 mostly, and due to diligent pursuit of performance, for which their team deserves a round of applause. Node.JS is also okay however its struggle to properly utilize all CPU cores and the finicky evented I/O stack that crumbles under not-that-big-a-pressure are a turn off. I started working with Elixir's Phoenix ~3.5 years ago and only had apps return in more than 5ms when you do complex SQL queries (which part of the time can be alleviated with query optimisation). While Rails' ActiveRecord easily swallows 150-200ms just serializing and deserializing from/to the DB, on an i7 CPU! Python's Django is better, but not by much. Laravel is OK but still not that impressive in 2020, when commodity i3/i5 CPUs ace various real-world benchmarks otherwise. --- My point here is: Let's not conflate "most SSR frameworks are crap and are written in slow languages" with the more general "SSR is slow". No, it really isn't, if using the right tools. Most web projects in my life could have been served from a Raspberry Pi 4 and written in Elixir's Phoenix and never break a sweat (maybe you'll need to attach an SSD though, because microSD cards are usually breaking easily). (Or Rust's Rocket, which makes you feel like you are visiting a static HTML page. It's that fast.) Elixir has, on average, 1% to 3% overhead, while Rust's is hard to even measure (likely 0.1% or below). So 97% to 99.9% of the time, those languages' web frameworks simply wait on I/O. And that's not the case with the vast majority of web frameworks out there, sadly.