Ask HN: What happened to server-side rendering?

Phoenix.LiveView — you can't ignore it, the coolest thing happening right now about server-side rendering.

Demo: https://youtu.be/Z2DU0qLfPIY?t=2628

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

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

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.

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

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

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

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.

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

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

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

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

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

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.

Obligatory plug for Phoenix LiveView: https://github.com/phoenixframework/phoenix_live_view

edit: This actually has examples https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

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

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.

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

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.

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

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

So maybe that took the wind out of the sails.

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/ (uses a headless browser to server-side render a JS app)

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

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.

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

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.

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

Nuxt is in full swing

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

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?