re: Server Side Rendering pros and cons. When to use it and when to choose something else VIEW POST

VIEW FULL DISCUSSION
 

As interesting this topic is - didn't we have this in the 2000's? Where all these rich serverside frameworks emerged? What I find a smart move is to serve a basic - perhaps even statically prerendered - version of the site and hydrate it on the client. But I did that in 2013 with JSPs, where I painted everything needed already on the page; including a script tag with serialized JSON to have an initial state going.

Don't get me wrong: I like the idea moving towards a Jam Stack, but it is something like new vine in old bottles :]

 

But I did that in 2013 with JSPs

Was it actual hydration or re-render?

 

It wasn't called hydration at the time. What I did was rendering an initial state of a document, put a script block inside where the state was rendered as a variable - simply an object, which was then picked up by backbone to get the frontend going.

That gave me a fast startup and a fully SPA-like UX in a traditional multidocument application.

We moved an existing application from traditional serverside baked in the early 2000s to a more modern version, where you had small SPAs so to say.

Unfortunately I left in 2015. So I can't tell how it came out. But a full SPA would only be consequential. 😉

So in a sense we played at the time with such types of concepts already.

Only, that you could now dismiss fully fledged web frameworks and go with Gatsby or vuepres mix and match with APIs living in AWS or on premise.

code of conduct - report abuse