Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-side rendering is a better choice for many applications (2020)

timr.co

Post reply on HN
Print view View original

111–120 of 286 posts

Re: Server-side rendering is a better choice for many applications (2020)

#111

Post by edanm »

vbezhenar wrote: post #75
superb-owl wrote: post #63

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.

The same argument could be used for splitting backend to multiple services, or even micro services. Frontend/backend separation seems pretty arbitrary. If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. With client-side rendering there's usually expectation of some monolith project using the single framework.

Frontend-backend separation isn't arbitrary at all. A few things that are often different between FE and BE:

1. Written in different languages.

2. Completely different deployment paths.

3. Causing completely different ways of scaling.

4. Focus on UI and UX is a very different mindset, with often some people preferring it to be a focus of their work, or not.

Re: Server-side rendering is a better choice for many applications (2020)

#112

Post by muspimerol »

thex10 wrote: post #79
muspimerol wrote: post #71

Earlier quoted context omitted.

As a frontend dev I can give you a few more reasons why I don't want to go back to writing templates as part of some backend framework: JavaScript is eventually needed for any non-trivial app. JS without a build system/dependency management is a maintenance nightmare. JS without linting, TypeScript, module syntax and unit tests is a maintenance nightmare. Reuse of components is much easier and more testable with fram…

Many apps with moderate interactivity don’t need thousands of lines of JavaScript. And using a backend framework for templating is not mutually exclusive to using a JS build system for helping transpile files and purge CSS and such.

> Many apps with moderate interactivity don’t need thousands of lines of JavaScript.

I mean, maybe? Depends what you mean by "many". I'm certainly not advocating for adding JS & frameworks where interactivity is not needed, and as I mentioned, for less than a couple thousand lines, an SPA framework is almost definitely the wrong choice. But my experience in the last 10 years is that very few projects do not grow to the point of requiring quite a bit of JS for interactivity. Async requests, complex client-side form validation, comboboxes, dynamic modals/content previews, showing/hiding long content, 3rd party integrations... these sorts of requirements are in nearly every app these days. And the HTML/CSS only solutions are just not good enough yet, unfortunately.

> And using a backend framework for templating is not mutually exclusive to using a JS build system for helping transpile files and purge CSS and such.

Sure, but at this point, why are you avoiding introducing a JS framework? All that stuff is built in to most JS frameworks (but not backend frameworks). You could piece it together yourself... but for what benefit?

Re: Server-side rendering is a better choice for many applications (2020)

#114

Post by esotericimpl »

safety1st wrote: post #97
datastack wrote: post #46

Lot of bashing of this idea, not sure why. The entire industry has shifted from "web developer" to frontend/backend developers. What used to be a web developer is now called full stack. It seems like a big deal to me and the entire shift is an indicator of how much the IT community is behind front end clients talking to a separate back end. Server side rendering is no longer considered normal. Server site rendering n…

I wouldn't say server side rendering is a "Thiel Truth," because it's a thing that is already popular and uncontroversial and agreed upon by millions. There is an echo chamber where this happened: * Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other co…

[dead]

Re: Server-side rendering is a better choice for many applications (2020)

#115

Post by ninkendo »

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

Re: Server-side rendering is a better choice for many applications (2020)

#116

Post by karmakaze »

ninkendo wrote: post #115

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

Mostly true--the hn.js would indicate otherwise:

  function vote (id, how, auth, _goto) {
    ...
    $('unv_' + id).innerHTML = unv;
    new Image().src = vurl(id, how, auth, _goto);
  }

Re: Server-side rendering is a better choice for many applications (2020)

#117

Post by ransackdev »

iamcalledrob wrote: post #99
ransackdev wrote: post #43

Earlier quoted context omitted.

I’ve rolled my own mvc framework before, In php even! This was years ago when CakePHP was the new hotness and Laravel didn’t exist. Take it from someone who had your mentality and set off to make a tiny and no bs mvc that just gets the job done, the amount of work these frameworks are doing for you (backend frameworks) that you don’t consider, is why you should run a framework. You don’t want to deal with processing…

> You don’t want to deal with processing a raw http request from the web server. You don’t want to split headers. You don’t want to sanitize input params, deal with character encoding, content types, gzipping, cache control, etags, basic authentication, flushing headers, chunking bodies, file streaming, tcp sockets, slow client avoidance, and probably 1000 other things I can’t recall. The Golang stdlib does all this…

Golang is in a special class on its own. Write some handler functions and pass around a context struct and call it a day. I wish every stdlib took care of all that stuff :)

Re: Server-side rendering is a better choice for many applications (2020)

#118

Post by karmakaze »

There are too many hedges and hand-wavy generalizations to take this seriously.

> Client-side apps are wads of Javascript that must be loaded and parsed before it can load and parse JSON which it can then transformed into HTML. Precisely nothing about this is optimal for browsers and networks. Many applications are used infrequently and browser caches are not magic (and disagree with you about how important you app is), therefore arguing 'each user only has to load it once' is bullshit.

The "wads of Javascript" is optional. The "must be loaded and parsed" can be trivial, and js is fast, so the "load and parse JSON ... into HTML" is FUD. As for the infrequency of app use, CDNs cache and deliver app source fast.

I'd like to see some actual numbers of the best-case Client-side apps and critique that, say maybe Svelte. Perhaps this post was somewhat relevant in 2020.

> Unless your app is something used frequently and for a decent period, with lots of low-latency interaction (forms do not count: think editing, iterating), it will certainly be faster server-side rendered.

Then it goes on to talk about mobile apps--I never considered this to be an either/or.

The biggest gains of SSR was SEO. I'm not a webdev, last I recall a hybrid SSR for first load, then Client-side app for rest is state-of-the-art.

Re: Server-side rendering is a better choice for many applications (2020)

#120

Post by greenie_beans »

lultimouomo wrote: post #38
nvm0n2 wrote: post #26

> What important truth do very few people agree with you on? Seems like answering with SSR would fail a Thiel interview for two reasons: 1. It's not important (in the grand scheme of things) 2. It's not a view that very few people hold. SSR was the standard way to do things for a couple of decades up until frameworks like React, and React itself now implements SSR, doesn't it? Thiel uses this question to try and dete…

> 1. It's not important (in the grand scheme of things) > 2. It's not a view that very few people hold. And yet it makes the author feel a contrarian free thinker. It turns out, it's the prototypical Thiel truth!

imo it's a prototypical anti-truth because it's not that contrarian even though the speaker thinks it is.
Post reply on HN