Server-Side Rendering Is a Thiel Truth | Hacker News Reader

Server-Side Rendering Is a Thiel Truth

timr.co

77 pointssigna1143 comments

I feel like we are going to go full circle pretty soon, with more people realizing that server-side rendering is better for most websites/apps. I say this as someone who has used Angular and Vue extensively (and still do). The problem is, it is extremely easy to get things wrong, and I have seen mediocre (not great, but not bad) front-end devs make a complete mess using these frameworks.

The fundamental problem with serverside rendering is that it requires a round trip if the model changes. With modern interactive apps, the model changes a lot. People don't like waiting for things.

That is why I said most, not all. There are also things like intercooler.js (https://intercoolerjs.org/) which provides a nice middle ground.

Laravel LiveWire looks like a good middle ground for enabling more dynamic user interfaces from a server application:

https://laravel-livewire.com/

There are similar projects for Phoenix/Elixir and Django:

https://github.com/phoenixframework/phoenix_live_view

https://github.com/edelvalle/reactor/blob/master/README.md

Not to mention that server side rendering increases cpu load on your servers. Of course that may be a feature if you're a customer who's tired of slowly loading webapps.

Server side rendering CPU should be a round-off error compared with the cost of a network connection to a data store.

There's a factor, though, that never seems to find its way into this conversation: the native web handles a lot of client-side state (model) for you, for free. We forget this because React and Vue elevate things like temporary input buffers, and dropdown states, and validation, to the application-logic level. This gives you the flexibility to do with it whatever you want: want to bind your text input's content to something else in real time? Go for it! But it also means that for the bottom 90% of common cases, application logic has to manually juggle all of those values itself, which it didn't used to have to do. This means our mental concept of "model changes" has become much larger in scope than it actually is for a server-rendered app.

In server-rendered apps, the client/server boundary plays the role of a natural boundary between transient and domain-model state. Of course the pain points come when that approximation is wrong, but in most cases that's a pretty rare occurrence.

This is actually the primary thing I like about server-rendering. Not the performance side, but the reduction in state. The reduction in contingencies and in the potential for broken cases. When most of your state gets thrown away on every view change, there's so much less to keep track of.

> With modern interactive apps, the model changes a lot. People don't like waiting for things.

Given how long I have to wait for the ever fashionable JS heavy SPA's to do _anything_, I'd almost be willing to bet it would still take less time.

Try opening reddit on a mobile phone.

My home server was more responsive when I was half way across the world.

I don't think we are going full circle. Microsoft Blazor, WebAssembly is showing a lot of promises.

Patiently waiting for WebAssembly to take off. I cant wait to get out of JS hell on client side.

HTML+CSS is a beautiful thing for ui. Its JS thats holding it back. If we had, say C# on the client side, imagine the web landscape by now.

You mean that you're waiting for WebAssembly to be able to access the DOM ? Or is there anything else you're specifically waiting for ?

WebAssembly to access the DOM.

Can you tell more about this please ? Because this is what I find:

> By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript

https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...

Even for small projects, I would choose Vue client-side rendering over back-end rendering. I'm a back-end dev so I don't do it because I love front-end work, I just haven't found a better way to do it. I can update the back-end API and front-end use on one machine and deploy both in a minute.

Sometimes all the work is client-side with third-party services as back-ends.

The only other solution I like is to have server-side rendering with live updates like Phoenix/Elixir, Vaadin/Java, or Rails/Ruby. These have scaling limitations but probably beyond what most of our apps need to support.

I think the other thing to worry about with live updating is client interaction security footprint. In most platforms you better be damn sure that your client rerendering code is bulletproof, because if an adversary finds an input permutation that hogs CPU or worse, panics your backend you'll really be up the creek, though Phoenix/liveview can take advantage of erlang process isolation in a way that it's way less of a concern.

I believe it was LinkedIn who took a hybrid approach a while back. I have no idea if this is still the way things are done, but somewhere in the 2012/2013 time period they would in general render things server-side. If the site was having load issues, they would turn the server-side rendering off and then the clients would render instead.

This was achieved using their fork of DustJS: https://github.com/linkedin/dustjs

   Asynchronous Javascript templating for the browser and server

> So is your app mostly forms or displaying content? User preference panels? Mortgage applications? Implement it with server-side rendering with a sprinkling of JS to implement widgets the web lacks. If only part of your app requires low-latency interactions, use client-side rendering only there.

While I understand it's easy to make the argument that SSR is better, lighter, etc. It's easy to quickly violate the "Single Responsibility Principle" in that you now have two systems with little knowledge of each other both in control of rendering the UI.

I lived the era of jQuery with apps just being a bunch of jQuery extensions + SSR. Eventually the app needs to make XHR (type ahead search, nested picklists, etc), and you end up in a situation where there was just one thing controlling presentation.

well no, you have a very strict layering of control

server owns it at first, and generates the base system

client-side js then owns it, and does whatever it wants

there's no back and forth, or dual simultaneous control of the UI. There's only one owner at a time; just two different systems who ever own it (and single-responsibility-wise: separating static UI from dynamic UI)

The concern is not about race conditions or shared memory where two things would be editing it at a time. Even though the server always renders it first then the frontend, you still need to share knowledge across both the backend and frontend about all the details of all the components to know how to change the values in jquery or whatever you want to do. Any time you change something on the backend, you have to make sure the jquery stuff is updated to still work, and potentially in many different places if you have different interactions that can update the same state. It makes for very tightly coupled and brittle code.

It’s still a matter of preference, you might still prefer that over a full frontend react codebase. But having seen both nightmare jquery messes and react messes, they can both be painful to work with. I definitely don’t agree that things were much simpler in the old days.

Ah but there's alot more "front end engineers" who know some javascript in the world than graybeards who know how to write server-side code well. So the business case for saving money on new hires is a strong argument for "make a javascript mess".

Who said it needs to be written well? I'd wager that the kids these days making messes in JavaScript could probably manage to do the same in Python or Ruby. Also, heck, this has been going on long enough that this point that some of them may even be starting to have a bit of grey in their beards and recognize a few of these tradeoffs...

Especially since back in the day they made those messes in PHP.

I think it also has alot to do with the current zeitgeist in the industry. We have tech heavyweights like Facebook with React and Google with Angular pushing this method of web development which is causing a bandwagon effect. I don't think businesses see it so much as a cost saving measure but think this must be the "right" way to do it because that's what Facebook and Google do. Nobody gets fired for choosing React or Angular. Suddenly there's a huge demand for "front end engineers" so if you're just starting out and want to get your foot in the door as a webdev you're probably going to need to know something like React or Angular. I don't believe it's an issue of younger devs not being able to learn server-side coding but just a lack of demand for it outside of the enterprise.

I've seen another problem, that's probably not going to happen with any of you careful hackers, but still seen it: where developers barely implement any security on their backend API and just go with filtering the results on the frontend side ...

With server side rendering of course you can still not-secure user input, but at least with template rendering, what you see is what you can see.

It "feels" (my personal biases and experience caveats apply) like "full stack" engineers aren't really that, but are rather great front-end developers with the back-end being an after thought.

Agreed, for me "full stack" really means the opposite: system and networks, backend / databases, and frontend. In most projects, even just mastering half of jquery does the job, as long as you at least know HTML with SEO and CSS well.

But then again, that's also IMHO

It adds optional infrastructure at the back end.

Infrastructure has direct and indirect costs, must be built maintained scaled monitored paid for etc etc.

You need a very very good reason to choose to implement optional back end infrastructure.

None of these reasons would be strong enough to convince me to start building and maintaining and paying for that infrastructure.

Are you implying that you would not need a back-end service without server side rendering?

> “Many important, profitable, applications aren't used enough to make a native mobile app worthwhile. Most online shops, banking, festival ticketing, government forms, etc. Therefore you will not have to support both server-side rendering and an API for your native apps”

A well done native app is always, faster, more robust and more enjoyable to use than a web UI. Even if your app is used relatively rarely, offering a significantly better user experience means it will be used more. And that’s a very important thing.

But users won't install it though. Your app can be a smooth magical experience but you have to get over the hump of getting users to go to the store and download it.

Unless I'm using your service daily I'm not going to bother with an app and just use the website.

Same here. In fact, unless can understand why whatever it is can’t be offered through a web page, or I have no choice, I will not install an app. The reason is security. The more closed-source binaries you put on your phone, the larger your attack surface.

You may not install apps without a good reason, but people install apps at a high rate. They love apps.

Hmm... I've seen claims that a 10% install rate is phenomenal when it comes to getting users to install your app, with 1-2% more typical.

Do you have data that shows otherwise?

Install rates ... depend on many factors. It can be difficult to get installs using advertising and other marketing channels.

But getting regular visitors to your web to install your app is by far the easiest way to get installs.

I think there’s a difference between desktop and mobile. Maybe you’re talking about mobile here?

I also had this sentiment, but I feel like VSCode as of late has pretty much proved this wrong. There's no discernable difference in responsiveness to me between it and any other native IDE I've used. And it's a pretty complex example.

VS Code is really good, even better than Slack. They just demonstrate that JavaScript can build some nice UI when not constrained to a browser.

Nice responsive site. How is this site implemented?

Oh no, you say. The article didn’t say “all” apps should be done with server-side rendering, it said “many.”

OK then, which ones? Well since we’re quoting the article, I’ll just put this here:

“the less complex your client-side is ... the less justification there is for client-side rendering.”

Now again, tell me, how is this site implemented?

What site are you criticizing exactly? The blog is a bunch of HTML served up with only the usual google panopticon JS, and is certainly not doing client-side rendering. HN is also a bunch of HTML with just a titch of JS - and little of it generates HTML (which would be client-side rendering). Tell me again, what are you complaining about?

Relax, I was complimenting the site, which performs beautifully on a mobile device. And rhetorically pointing out that it is rendered by browser technology (WebKit), which, last time I checked, was considered client side. But hey I could be wrong, so feel free to educate me.

In web dev parlance client side rendering refers to dynamically generating HTML from some data format (eg, serving a template and having the JS render it and add it to the DOM, instead of applying the template on the server and sending the resulting HTML). You're right that the browser's rendering engine ultimately does all the work of generating the images that get displayed, but that has to happen anyway and isn't a distinction that gets talked about (much) in web dev land.

OK I see,thank you.

Reply on news.ycombinator.com