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.
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
- Extracted from the Next.js announcement post.
- Extracted from the ZEIT Team AMA held on Mon, 30th Jan.
- Extracted from “Add Yarn support in new apps using — yarn option” pull request