One of the most fascinating technology improvements the past couple years is the growth of JavaScript.

JavaScript has gone from simple jQuery animations, and events to complex full end-to-end user applications with tools such as React, Vue, and Angular.

But as these JavaScript applications grow with features, the file size grows with it.

Your users might start seeing a blank page flicker.

And that blank page may take a few seconds to display any content.

This causes a bad experience for the user for their first visit.

You can utilize Node.js and make it work with your favorite JavaScript view library to render the initial HTML markup with some data.

What is SSR (server-sider rendering)?

It’s grabbing a JavaScript application or website and rendering it on the server side as static HTML and CSS.

Great, but why would you want to do that? Right?

Reason #1: Reduce initial load time

When a user first arrives to your awesome website or application, it will serve the initial HTML, image assets, and CSS styles.

Your internet browser is really good at serving that data fast.

But that’s not the only thing it may serve. The browser may also serve your app JavaScript code.

And this where things may get a bit time consuming for your browser.

See, JavaScript is fast, but the file size may be huge.

So downloading, the file to the browser may take a bit of time, especially if you’re in a limited connection internet bandwidth.

After downloading the JavaScript files, the browser is going to need to parse it to understand what the intent of the file is suppose to accomplish.

Maybe a few animations, click events, etc.

So if your app is dependent on JavaScript to serve your entire application or website, it may be a problem because of how slow it may get served.

This is where Node.js comes and saves the day.

Since Node.js is JavaScript, we can use it to grab your client side code that renders markup HTML (React, ember, etc), and serve it through server-side.

Even though this doesn’t help boot up your JavaScript code faster when the browser is downloading it, it will serve the basic markup HTML with some data faster to your users.

Reason #2: SEO friendly

Another benefit with server-side rendering is that your application or website is SEO friendly.

Even though Google claims that it’s gotten better at reading JavaScript after the document has loaded, experts such as Moz, SEO Search Land, and John Mueller still suggest to use raw HTML markup for best results.

Since server-side rendering is only responsible to output the initial markup then is enough for Google crawlbots.

Reason #3: JavaScript all

Since your markup code will be rendered by JavaScript and outputted by Node.js.

That means, you can take advantage of converting your server side rendered app into a single page application after the initial load.

This will let your users have a fast initial load to your application, and let them navigate through it in a native app like feel.

The cost

The biggest cost to this approach is time because of the amount of complexity that comes with bridging the server side with the client side.

This will require the engineer to make sure they’re making the back-end code to optimize the first to paint, and the TTI (time to interactive).

Conclusion

Using JavaScript on the server side will help address both performance, and SEO friendliness.

It also allows you to use your favorite view libraries and produce native like apps.

But it comes at a cost of time, and extra complexity.

Happy coding!

I like to tweet about JavaScript and post helpful code snippets. Follow me there if you would like some too!