Hacker News Reader

Comment by duxup | Hacker News Reader

This reads like sort of a grand collection of mostly legitimate individual technical complaints about a lot of things JavaScript / Browser.

But I still can't get past the fact that when I work for a company that wants to write a web app it is just like magic that it works across all these operating systems, phones, and etc provided they have a capable browser.

To me that utility is amazing. I don't see how to get around that, and for all the issues listed, I don't see a reason to throw the baby out with the bathwater / not really sure what the alternative is supposed to be.

As for privacy, if we weren't doing things in a browser as much and you had to install an app... would OSes be a better host / not have all these issues?

View on HN

I don't understand why there's so much avoidance of server-side rendering.

Personally I'm really interested in it but honestly I've only started to dip my toes in it, and I don't think that really fixes most of the issues in the article.

Granted the article is sort of a goulash of not incorrectly but not entirely connected ideas. Like a lot of JavaScript criticisms you couldn't possibly address them all, maybe that means something ;)

What would you like to see being solved by server-side rendering? Genuinely curious.

Because client-side rendering is free (at least to the site), while server-side rendering costs actual money.

That matters a lot when you start running things at scale.

By the time a web app has megabytes of JS and fetches just to show its initial content, is it actually saving money?

If most of that is cached in the browser, then theoretically, yes.

But then the average smartphone can't handle the JS and works so slow that the money you saved from not having a backend is never going to be recouped by your high bounce rate (i.e. people leaving the website out of frustration of its slowness).

Well, you can at least appreciate the simplicity of a server just being a simple API that all of your clients use in the same way rather than the server having an API and then also generating the page for one specific idiosyncratic client that has this weird feature where you can serve layout to it.

Also, once you have any interactivity, there's a point where it's nicer when all of the application is in the domain of Javascript instead of only parts of it.

Server-side rendering has some nice upsides, but there are various trade-offs, good and bad, at play here.

> Well, you can at least appreciate the simplicity of a server just being a simple API that all of your clients use in the same way rather than the server having an API and then also generating the page for one specific idiosyncratic client that has this weird feature where you can serve layout to it.

Maybe I am misreading you because this sounds to me like "we only want to hire JS devs".

You can have your APIs on one server and the html rendering on another.

When done this way, I think there's more incentive to actually optimize API requests.

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.

> 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.

I too don't but from my numerous discussions with many colleagues I get the vibe that they conflate "slow and badly implemented SSR frameworks" with "SSR in general is slow".

This has a lot to do with the religious sticking to PHP, Python and Ruby on the backend, which are practically the worst choices of all. Even Node.JS performs better. Or Java, when written well and not having 20 layers of enterprise-y stuff.

Reply on news.ycombinator.com