Codementor Events

The Complexity Of SSR Is Too Damn High!

Published Jun 16, 2017Last updated Dec 12, 2017
The Complexity Of SSR Is Too Damn High!

A couple of months ago VueJS team wrote a thorough guide about server-side rendering. By its length and complexity of concepts, it is clear that SSR is not a walk in the park; they recognize it bay saying:

Properly configuring all the discussed aspects of a production-ready server-rendered app can be a daunting task. Luckily, there is an excellent community project that aims to make all of this easier: Nuxt.js. Nuxt.js is a higher-level framework built on top of the Vue ecosystem which provides an extremely streamlined development experience for writing universal Vue applications.

Of course this is not VueJS fault, the complexity of SSR is too damn high no matter which framework is being used.

Another issue not present in that guide is that some plug-ins don't support SSR since they don't inject the necessary code into the DOM when the page is loaded server side. I faced this problem with authentication libraries, a critical functionality in any application!.

Personally, I wouldn't choose SSR for a project even if it requires it, I would opt for classic non-spa solutions using HTTP/2 Server-Push to load assets faster. In the end that's what the big fishes like Akamai and Cloudflare are using.

But of course, that's only my humble rant/opinion. I would like to hear your thoughts and experience with SSR.

Discover and read more posts from Esteban Negri
get started
post commentsBe the first to share your opinion
Alex
4 years ago

Three years later, checking in to see how you feel about NUXT and SSR.

Arend de Boer
7 years ago

After much consideration I decided to go with nuxt and are quite happy with it. If a lib does not support SSR, there is always the option to use it after the application is hydrated, which for the mentioned example of social login should be no problem (I hope because it is the next thing I have te implement) But who knows, maybe I’ve bet on the wrong horse and it will bite me later on.

Esteban Negri
7 years ago

Thanks Arend for the feedback. I hope it works well for you, Evan recommends Nuxt so I suppose you are on the right track. Your decision is the most logical, libs and custom solutions are trendy but they hit against the wall with the SSR issue.

Ember and Nuxt are reasonable solutions, the only caveat regarding Nuxt is that is not mature enough but this is the status quo of the Javascript ecosystem, we have to deal with it.

Adrien Boullé
7 years ago

Hi!
In my opinion, you miss one point here: SEO.
In some cases, you NEED ssr.

I work in a start-up and we have created a bot-based website builder on Angular2.
For now, our users websites are just a blank page with a <web></web> tag for the google cache and the bots. And if your connection is bad you might wait for the bundle to load before seeing anything more.

So ssr was not an option, we absolutely HAD to do it. The Angular team have integrated an Angular2 side project called Angular Universal which does ssr for angular apps. It’s quite new and we have to fine some tricks to handle some parts of the code as the use of window for example and we are almost ready to release and I have to say it was quite an interesting to do technically speaking :)

Esteban Negri
7 years ago

Just to clarify I’m not ‘against’ SSR on the contrary, everything was SSR before SPAs and we didn’t have these issues back then.

The problem is that the SPA architecture is opposite to SSR so in order to support it you need to tweak and hack your app.

Regarding SEO VueJS Team suggest this alternative: https://github.com/chrisvfritz/prerender-spa-plugin

The way the VueJS SSR guide is written clearly states that SSR should be your last option not because it is something bad but because of all this hacking tweaking and overengineering that must be done in order to support it.

Show more replies