Mariano Viola

Is ZEIT a Lighthouse in Our Web Development Dark Age?

jQuery, WordPress and PHP aren’t considered cool web technologies anymore, but 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 – to 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 which stimulate the developer creativity by clearly communicate 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 its 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 users 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 client, splitting and lazy load code over routes and by introducing complex and sophisticated caching mechanisms in order to deliver performant single page apps.

In the meantime we forgetting 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 is bloomed in a flourishing ecosystem, which give 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 the 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”1. 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.2

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 humans beings. Frankly I’m quite surprised that even if we often talk about AI applied to fascinating scenarios, we still have to spend time to manually configure and build 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 own webpack.config.js. It should surely be possible, but not required.3

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 argument:

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 avoids 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 a npm-shrinkwrap.json or yarn.lock file, you’ll see a pretty dramatic change, in the order of 2 to 30 times faster.4

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 really matter.


References

  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