
Ask HN: What happened to server-side rendering? - knasmai
A few years ago, there was a lot of talk about Isomorphic rendering of JavaScript, but seems to have died down recently.<p>Are any products still using it? What happened?
======
lelf
Phoenix.LiveView — you can't ignore it, the coolest thing happening right now
about server-side rendering.

Demo:
[https://youtu.be/Z2DU0qLfPIY?t=2628](https://youtu.be/Z2DU0qLfPIY?t=2628)

Links: [https://leveljournal.com/why-phoenix-liveview-is-a-big-
deal](https://leveljournal.com/why-phoenix-liveview-is-a-big-deal)
[https://elixirforum.com/t/phoenix-liveview-
info/16569](https://elixirforum.com/t/phoenix-liveview-info/16569)

PS please stop calling it isomorphic — this is disgrace for the mathematics.

~~~
quickthrower2
Calling it isomorphic might be a disgrace for mathematics, but in terms of the
Greek meaning of single form, it’s accurate.

~~~
kyriakos
I speak Greek natively, isomorphic literally translates into "same form"

------
_bxg1
The main advantage of server-side rendering of client-side templates is
cutting your initial load time to a bare minimum (not having to wait for
scripts to load/compile, taking advantage of page caching, etc.). However,
this usually only matters when you're afraid of users getting impatient and
bouncing, which tends to be true of sites that mainly display content and
don't have a ton of interactivity, and sites like that usually shouldn't be
using client-side rendering in the first place.

So you have two buckets: web apps that don't care too much about shaving
milliseconds from the initial load, and content sites that shouldn't be
shipping heavy JavaScript in the first place. The target market for hybrid
rendering is the tiny slice of sites in-between those two, so it's a minority
of use-cases. Though it is also used by sites in the latter category that are
shipping heavy JavaScript anyway and having regrets.

~~~
jypepin
A big one for the need of server side rendering is SEO. Without server side
rendering, most web crawlers don't have access to your content and you can't
rank for SEO.

~~~
raquo
SSR for the purposes of SEO can be achieved in a simpler way, without
complicating your whole app to support SSR.

Just pre-render the page in headless chromium / puppeteer when a search engine
bot requests it and return the resulting html.

~~~
davidjnelson
This is pretty slow though right? Those speed penalties will impact your
google search ranking.

~~~
raquo
I haven't had a chance to try it myself yet, but from what I've read the extra
delay is sub 100ms. Caching or pre-rendering the HTML output for bots in
advance is an option too depending on the particular use case.

I would certainly consider this ahead of SSR driven by "isomorphic" Javascript
for frontend-heavy apps.

------
mxstbr
Universal rendering is widely used in the React ecosystem, in large part
thanks to Next.js[0] making it simple to set up and run.

Many large sites like Marvel.com, Nike.com, Invisionapp.com, hulu.com and many
more run on server-side rendered React, see the Next.js showcase for a more
complete list: [https://nextjs.org/showcase](https://nextjs.org/showcase)

[0]: [https://github.com/zeit/next.js/](https://github.com/zeit/next.js/)

~~~
leerob
Agreed. I'm a big fan of Next.js and haven't had any major problems with it.
While there have been some quirks and nuances I had to learn[0] it still
provides the easiest platform for SSR out of the box.

[0]: [https://leerob.io/blog/things-ive-learned-building-nextjs-
ap...](https://leerob.io/blog/things-ive-learned-building-nextjs-apps/)

~~~
chatmasta
I'm evaluating next.js for a new project. But coming from create-react-app,
I'm a bit skeptical of these "frameworks" that seem to provide little benefit
beyond developer tooling (i.e. setting up webpack, hot reload etc). create-
react-app was great in the beginning, but months later was really annoying. I
get the feeling next.js could end up like that. At least you can eject from
CRA.

I'm curious if anyone has gone the "roll your own" route with SSR + react,
starting with a simple approach and adding complexity only as it becomes
necessary. Has anyone done this and maybe also used next.js? I would love to
hear a comparison, because at the moment I'm unconvinced next.js is really
necessary if you know what you're doing, or you intend to maintain the project
for more than 2 years.

~~~
davidjnelson
The spectrum chat team, which GitHub acquired, wrote that they wish they had
started with next.js [https://mxstbr.com/thoughts/tech-choice-regrets-at-
spectrum/](https://mxstbr.com/thoughts/tech-choice-regrets-at-spectrum/)

~~~
mxstbr
That's my blog post! If you have any questions let me know.

------
heynk
At my team, we use next.js for pretty much every 'web-based' product.

[https://github.com/zeit/next.js/](https://github.com/zeit/next.js/)

It gives you SSR with React out of the box. It's really nice to work with, and
flexible enough that we haven't had issues with more customized situations.

------
zamalek
While not JavaScript, there's now Razor Components[1]. It doesn't work exactly
like isomorphic JS, as it operates more like a terminal session (the server
sends down VDOM mutations to the client). I'm not entirely sold on the
approach yet, but I am going to be keeping an eye on it.

[1]: [https://docs.microsoft.com/en-us/aspnet/core/razor-
component...](https://docs.microsoft.com/en-us/aspnet/core/razor-components)

~~~
sansnomme
I wonder what took so long for DOM-deltas-over-websockets tech to show up. It
was only in the last two years or so for stuff like Plotly's Dash and Elixir
Phoenix's LiveView to become popular even though we had Websockets and event
driven networking for ages.

~~~
mercer
If I understand correctly, Chris McCord actually did something similar back in
his Rails days
([https://github.com/chrismccord/render_sync](https://github.com/chrismccord/render_sync)),
but the issues he ran into actually led him to create both Phoenix and,
eventually, LiveView.

I'm sure others are better at explaining the details, but from what I gather
this approach is now more viable than it was in the past with other stacks
because 1) Phoenix is really efficient and fast with rendering templates, 2)
The Erlang/Elixir-specific channels/process approach makes it much easier to
have tons of websocket connections open _and_ maintaining state, and perhaps
3) javascript got a lot faster.

------
aeharding
I've had great success with Vue's builtin SSR -

[https://vuejs.org/v2/guide/ssr.html](https://vuejs.org/v2/guide/ssr.html)

Great for FB/twitter share scraping, google scraping, etc. Also much better
startup speeds.

Once you get it configured it's very little additional work to maintain.

I have it set up to do things like determine mobile/desktop depending on the
`user-agent` to determine the prerendered page to serve, and then the client
side JS takes over depending on the viewport size and will either a) Rebuild
(less than 1% of the time) changing the markup from desktop->mobile of
mobile->desktop or b) Continue happily

~~~
dmortin
> Great for FB/twitter share scraping, google scraping, etc.

Google scraping? How/why can it be used for google scraping? Doesn't google
return html result pages?

~~~
jazoom
I believe they mean Google can easily scrape your page. Otherwise known as
"SEO" in this context.

~~~
dmortin
Thanks. I know what SEO is, the word "scraping" confused me, because it
usually refers to people scraping the pages of various services.

~~~
jazoom
Yes, and in this case it also means one party scraping the webpage of another.

I also had to read the comment twice to understand it.

------
artellectual
I built a solution for server side rendering using Elixir / Plug and Chrome
Headless via Chroxy. It simplifies server side rendering greatly since it
doesn’t care about the client side library you use. I have been using it to
power my site[1] which is written in React.

I also happen to make the Elixir Foundation series of videos[2] that show how
to do serverside rendering using elixir. So I’m dog fooding the dog food.

[1] [https://www.codemy.net](https://www.codemy.net)

[2] [https://www.codemy.net/sets/elixir-
foundation](https://www.codemy.net/sets/elixir-foundation)

------
dfabulich
For sites using React, Angular, Vue, and Ember, the "talk" has died down
because it's just a standard feature of the platform. Server-side rendering is
part of the table stakes at this point for JS frameworks.

------
cwisecarver
Obligatory plug for Phoenix LiveView:
[https://github.com/phoenixframework/phoenix_live_view](https://github.com/phoenixframework/phoenix_live_view)

edit: This actually has examples
[https://dockyard.com/blog/2018/12/12/phoenix-liveview-
intera...](https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-
real-time-apps-no-need-to-write-javascript)

~~~
Scarbutt
Is there a demo server somewhere? wonder how well it will work if you are at
200ms from the server.

~~~
cwisecarver
I don't know of any off the top of my head or a quick google search. I do
know, from the latest ElixirTalk podcast, that it's very careful about what it
sends over the wire, only the parts that have changed. If you're interacting
with an API to get the same information for a SPA you're probably going to
have similar latencies.

------
azangru
> Are any products still using it?

Of course they are. Lots.

The New York Times. The Intercept. AirBnB. Just off the top of my head.

~~~
sbhn
[https://homeidea3d.com](https://homeidea3d.com)

------
lr4444lr
My two cents:

1) Lack of reliable real time ability to detect device and compute size. 2)
Increased computation complexity of what to render - why put that load on the
server when devices are now commensurately as fast - or even faster given the
trend to distributed services that maximize network throughput over power.

I'm not even sure why it was so popular in the first place; client server
separation is a good thing, IMHO.

~~~
Can_Not
Best practice would be to wrap anything that is both unnecessary for SEO and
non-trivial into <no-ssr> tags. No need to render a datetimepicker widget on
the server, especially if Google bot is requesting the page.

------
bfoks
Remember that Google Bot uses Chrome 41[1]. So some features from ES6+ might
not be supported. It's always a good idea to use Babel during compiling a SPA
without SSR.

[1]
[https://developers.google.com/search/docs/guides/rendering](https://developers.google.com/search/docs/guides/rendering)

------
Scarbutt
I would say is more relevant now, the time to build and complexities of SPAs
has make many companies switch more to multipage SSR react with additional
react JS for the browser, for SSR, SSR react is superior (because of
components) to stuff like pugs IMO.

~~~
Can_Not
You can use pug with SSR with VueJS (and/or NuxtJS).

------
k0t0n0
> There was a lot of talk about Isomorphic rendering of JavaScript, but seems
> to have died down recently.

It's no way near dead, just look at nuxtjs/nextjs/Gatsby. they are getting
more popular day by day. Recently I worked on an E-commerce platform using
next.js and Gatsby.

I have to say its really cool and good user experience overall. the only issue
I had was the complexity of the code. You have to think about backend/frontend
at the same time. I will definitely use it where it makes sense.

------
martin-adams
I believe a significant motivation of SSR was to be indexed by Google, then
Google said they will start crawling JS rendered pages:

[https://webmasters.googleblog.com/2014/05/understanding-
web-...](https://webmasters.googleblog.com/2014/05/understanding-web-pages-
better.html?m=1)

So maybe that took the wind out of the sails.

~~~
jypepin
Beware tho, Google has still not officially said it was able to parse SPAs as
well as server-side rendered pages and have still at multiple occasion (and
still recently) said that although it can deal with JS, its not perfect and
leads to issues. So if SEO is important I wouldn't skip SSR.

------
jotto
It's still relevant, just difficult. I think the herd jumped into SPAs before
they understood the implications.

I was one who jumped in, then tried to automate my way out of client-side slow
renders with [https://www.roast.io/](https://www.roast.io/) (uses a headless
browser to server-side render a JS app)

------
NicoJuicy
I can integrate js in a viewengine in asp.net MVC for reuse of HTML components
( yes, server side rendering based on the v8 js engine)

I also use razor though, but this is a neat workaround instead of using a
headless browser.

The right mix of using scaffolders in. Net ( server side) and client side
components can decrease development time exponentially

------
leowoo91
I'm still surprised how many people are not aware of client-side rendering
being unstable, because they don't see the final result per visitor, but a
prediction most of the time. Testing cross-browser is another story, though it
can help a bit, is also usually omitted.

------
badsavage
Server-side rendered React with Clojure is my favorite way to deal with a
website

------
torte
The talk died down because it became a standard way of doing things now. It
isn't something special anymore and the tooling has evolved to make it more
seamless.

------
andrei_says_
It’s happy and well, being the main source of rendering in most of my live
apps.

------
moltar
Nuxt is in full swing

------
aboutruby
Most people have realized it's actually complicated to do it right and just
gave up on server-rendering their React apps (e.g. Reddit).

~~~
StellarTabi
If we are using reddit as the standard for what's difficult to do right, then
apparently everything is too difficult to do right. Case in point, their two
mobile websites before react are both unusable garbage. I write SSR JS apps
and React/SSR is _not_ the one to blame in reddit's scenario.

------
austincheney
1) What do you mean by server-side rendering of JavaScript? It sounds like you
mean executing JavaScript on the server that otherwise is destined to execute
on the client-side. I execute JavaScript on the server/terminal all the time
and don't call it _server-side rendering_.

2) What is your motivation? What problem do you think you are solving with
_server-side rendering_?

~~~
Scarbutt
He's talking about web apps.

~~~
austincheney
He/she is probably talking about single-page apps. But it isn't clear.

~~~
Scarbutt
_He /she is probably talking about single-page apps_

If you want to be pedantic about it, sure.

~~~
austincheney
I am not being pedantic. You and the op are having difficulty with
specificity. I was clear about that and somehow that means I should be called
names and down voted for asking an appropriate question.

If I wanted to trolled by framework children I would go back to reddit.

