Mariano Viola

jQuery, WordPress, and PHP aren’t considered remarkable web technologies anymore. However, they are still immediate and understandable tools if you need to quickly design, develop, and publish a website or a blog. This concept isn’t far from what Rails did and still does for web apps.

Combining Rails—which is a web development methodology more than a simple framework—with a developer-friendly deployment solution like Heroku, you can figure out why a lot of successful apps started in this way.

I consider those systems speaking blueprints that stimulate the developer’s creativity by clearly communicating what she can do and what she can achieve. In some cases, they can limit you with strict design rules, but they are an alternative to a disarmingly blank page with infinite possibilities.

A Step Back

With single-page apps, we subverted a stricter but simple and clear mechanism in which documents are linked with some pieces of text. We did it in the name of a better end-user experience and to fulfill our user’s contemporary needs and habits. Despite that, we realized pretty quickly that we caused them other problems. We forced our users to download a full website by just accessing a single page, so we took a step back, starting to pre-render on the server, rehydrate on the client, splitting and lazy load code over routes, and introducing complex and sophisticated caching mechanisms to deliver performant single-page apps. In the meantime, we forget as developers that we are humans too, and as happens for end-users, we need immediacy and well-designed tools with clear rules and clues to be productive. If it is true that JavaScript has bloomed in a flourishing ecosystem, which gives us freedom of choice and limitless opportunities, it is also true that for every — even simple — new project, we need to spend precious time and energies to chisel an ever-growing body of alternatives and techniques. This is to say that, even if we are living in the middle of JavaScript time, probably we haven’t our WordPress and our Rails, yet.

The Next JavaScript Blueprint

Next.js is ”a small framework for server-rendered universal JavaScript web apps, built on top of React, Webpack, and Babel”¹. Can Next.js become a part of the JavaScript blueprint? Anyhow I fully agree with the vision of @rauchg, one of its creators:

This is why with ZEIT we created Next.js. We think the React programming model combined with some of the strengths of what the “PHP way” had given us will give us a very strong productivity (and therefore economical) advantage for years to come.²

Leave Build Tasks to Computers

Moreover, Next.js leaves to the computer the responsibility to optimize, split, and deliver your assets. It abstracts the Webpack work, a task that in my opinion should be solved automatically through frameworks/libraries, browsers, networks, and protocols, not by human beings. Frankly, I’m quite surprised that even if we often talk about AI applied to fascinating scenarios, we still have to spend time manually configuring and building web assets. About this point I completely agree with @dhh and the philosophy behind Rails:

What’s clear is that we want the core Rails principles of convention over configuration to carry over. Nobody should HAVE to configure their webpack.config.js. It should surely be possible, but not required.³

If Next.js aims to simplify your front-end development experience, Now, a service from the same creators of Next.js does the same for the application deployment. The following lines give you an idea of what I’m trying to argue:

Until now, our npm installations took advantage of a few tricks to speed up package downloads, heavily parallelize and reduce disk I/O as much as possible, similar to how yarn by Facebook works today. We’ve now taken this model further, by introducing a global shared cache of public modules that avoid repetitive work in each deployment. For example, if you deploy node-canvas, which involves a lengthy C++ compilation, our build servers only do it once and securely share it with all our customers. With this update, almost every build step will see a noticeable improvement. If your projects contain an npm-shrinkwrap.json or yarn.lock file, you’ll see a pretty dramatic change, in the order of 2 to 30 times faster.⁴

Es ist Zeit

Next.js and Now are cool tools, they could be a response to our fatigue, and no, I’m not merely promoting ZEIT, what I’m trying to do instead, is to highlight what in my opinion, is an original combination of libraries and services that can help JavaScript developers to save time and to be focused on what matters.

---

Footnotes

1. Extracted from the Next.js announcement post. ↩

2. Extracted from the ZEIT Team AMA held on Mon, 30th Jan. ↩

3. Extracted from “Add Yarn support in new apps using — yarn option” pull request ↩

4. Extracted from Faster JavaScript Deployments ↩