
Server-Side Rendering Is a Thiel Truth - signa11
https://timr.co/server-side-rendering-is-a-thiel-truth
======
darkhorse13
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.

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

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

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

[https://laravel-livewire.com/](https://laravel-livewire.com/)

There are similar projects for Phoenix/Elixir and Django:

[https://github.com/phoenixframework/phoenix_live_view](https://github.com/phoenixframework/phoenix_live_view)

[https://github.com/edelvalle/reactor/blob/master/README.md](https://github.com/edelvalle/reactor/blob/master/README.md)

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

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

------
strictnein
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](https://github.com/linkedin/dustjs)

    
    
       Asynchronous Javascript templating for the browser and server

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

~~~
setr
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)

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

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

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

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

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

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

~~~
1337shadow
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

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

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

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

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

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

~~~
Turing_Machine
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?

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

------
natch
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?

~~~
cmrx64
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?

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

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

~~~
natch
OK I see,thank you.

