What's next for Javascript?

We’ve survived a couple of things in the last 10 years or so of JavaScript. We’ve survived jQuery, we’ve survived grunt, gulp and we’re surviving webpack. We’ve almost survived redux (in my humble opinion mobx is what’s next) and we’re trying to survive REST like we did SOAP and other esoteric legacy ways of getting data from one point to the other.

Since there’s a lot of what’s nexts, let’s take a look at frontend frameworks. We’ve got the trinity of React, Angular and Vue, but the question remains the same. What’s next?

There are a couple of possible answers but I’ll pretend that Next is the one while giving an honorable mention to svelte that seems to be gaining some momentum.

Next over React?

It’s true that Next is pretty much a ReactJS wrapper and since ReactJS is pretty basic on its own it makes sense to wrap it in something. (Note: There’s also a Vue option - Nuxt)

The main issues we’ve had with React are pretty straightforward and general:

1. Everyone makes a different folder structure
2. Everyone uses a different router, styling method, build setup ...
3. Server Side Rendering (SSR) is a huge pain

Next solves this a bit - how?

Folder structure bonanza

Everyone has their favorite way to set up the folder structure of a React application - the only truly constant folder is the /components folder. This is problematic because it makes the review of many projects difficult and any existing solutions might be hard (i.e. ugly) to implement in a different folder setup.

Next does not solve this any more than the famous create-react-app did. One thing it does do, though, is the separation of the page components into a separate fixed folder called /pages - this makes the whole system much clearer by default.

From there on, while we’re still on our own, we at least have a central point.

A nice set of defaults

Even more problematic is the fact that everyone has a different set of libraries they like to use. Maybe we could go as far as to say a favorite “stack” inside React. Let’s take a look at some of Next’s defaults.

Styling

There’s a ton of styling options - the one that Next includes (styled-jsx) is a very nice one since it:

1. Allows you to write CSS in CSS. Not in quasi-css like many css-in-js libraries. You are able to copy paste your ad-hoc creations from the developer console to your code as-is.
2. Supports a ton of plugins to write in any advanced css flavor you like - LESS, SASS, etc.
3. Is a part of a React component (can of course be imported, if you prefer to keep your css outside) and can adapt to rendering changes - you can, for instance, change the actual css of the component when the props are changed.
4. Is local by default - you can repeat all of your general class names and they won’t drip out of the component. It can be selectively made global as well, if necessary, by adding a simple tag.

Routing

As mentioned before - NextJS has its own router. Not to go into too much detail, it’s necessary for it to have it in order to make SSR work and does not stop there - for example, it allows for automatic code-splitting, as per their docs:

Next.js does automatic code splitting and it is based on the pages in your app. For example, if one of your modules is used at-least in half of your pages, then it moves into the main JavaScript bundle. If not, that module stays inside the page's bundle.

This is an excellent feature that minimizes the code loaded per specific page.

The routing might be a bit clunky at first, compared to your favorite react-ultrastar-router, but it does bring a lot to the table.

Build pipeline

Avoiding a ton of cryptic webpack configuration, Next has its own build system that can be heavily customized while remaining relatively simple to figure out. It allows for custom webpack snippets and many more interesting configuration options that allow you to create a blueprint for all of your projects that anyone can understand pretty fast.

It can build a static page, it can build an SSR page. That’s pretty much all you need.

Server-side rendering

This is the main feature. This has always been a huge pain to manage with React applications and while there were some options none of them come close to how Next manages this. Once you adapt to the setup, server-side rendering is easily extendable and can cater to any desire. There’s a giant library of examples for Next.js that cover pretty much everything you’d like to implement.

There’s also an option of using a custom node.js server to further tweak the SSR side of things. It makes for a wonderful decoupling of the backend and frontend parts of a system. While it does require an actual server to host (that’s an SSR requirement anyway) it still keeps the frontend stuff separated from the backend (the two sometimes blend together when you have them both written in JavaScript) and increases the clarity of the code manyfold.

Goodies

Next also includes a fair number of goodies that can either be used or ignored but are really nice to have on speed dial. Here is a couple of the most notable ones:

1. Prefetching - further optimize navigation by prefetching pages before they are clicked
2. Export to a static app - you can use Next without SSR as well. It simplifies the code and keeps the option of SSR open for later development.

Conclusion

I’ve found that using Next is a breeze. It doesn’t fight you too much on the configuration front, it’s probably the best and easiest way of managing SSR and it brings a sensible set of defaults to the table.

I must note that this only skims the surface of Next - for any additional questions & comments & inquiries & threats regarding this article feel free to contact me.