摘要：无数的模板语言和框架应运而生但是技术始终被分割为前端和后端。这意味着一个页面可以有很多的这并不会对其余的页面有任何影响。提前绑定和编译预测是一个非常有效的部署方式。最后，这是我们对于这个特定问题的贡献。

原文地址

Naoyuki Kanezawa (@nkzawa), Guillermo Rauch (@rauchg) 和 Tony Kovanen (@tonykovanen)
周二，2016年10月25日

我们非常自豪的开源了Next.js，他是一个小巧的基于React、Webpack、Babel的客户端渲染universal JavasScript web app框架。

要开始使用Next.js，只需在一个有package.json的文件夹里执行以下命令：

$ npm install next --save
$ mkdir pages

生成pages/index.js：

import React from "react"
export default () => 
Hello world!

然后在package.json里添加一个script：

{
  "scripts": {
    "dev": "next"
  }
}

然后执行：

$ npm run dev

本文主要阐述该项目的设计理念和它背后的哲学思想。

如果想学习如何使用Next.js，请移步README，在那你只需花几分钟就能学习完所有功能。

首先我们会深入该项目的后端并逐一描述以下6个原则：

零配置，使用文件系统作为API

只有JavaScript，一切都是函数

自动服务端渲染和代码分割

完全可定制的数据获取方式

预测是提高性能的关键

部署简单

从很多年以前，我们就一直追求universal JavaScript applications的道路。

Node.js展示了这种可能性，客户端服务端代码共享，也扩展了开发者的视野。

为了能在Node上开发app和网页，开发者做了很多很多尝试。无数的模板语言和框架应运而生……但是技术始终被分割为前端和后端。

假设你选择Express和Jade开发，HTML会首先被服务端渲染，然后另外一个项目（jQuery或是其他类似库）才会接管过去。

这样的状况其实一点也不比传统的PHP方式好多少。从很多方面来说，PHP都更适合服务端渲染HTML这样的工作。在出现async/await之前，在JS中查询数据并不容易。捕获和处理request/response的异常也非常麻烦。

然而，一些值得关注的概念的出现，使得我们能够填补这个空白。其中最重要的就是能够根据数据返回对应UI的纯函数。

这个模型（因React而流行）非常重要，不过仅仅有他还不能从众多的模板系统中脱颖而出。另外一个重要的概念就是组件生命周期。

生命周期的钩子函数允许我们在前端接管某些之前由服务端渲染的的页面。比如说，你可以在一开始只渲染静态数据，监听服务端的更新，并根据数据改变页面。或者什么也不做，让这个页面保持静态。

Next.js是我们在这条路上更近一步的成果。

工具假设你的项目具有特定的文件结构。

一般来说，我们开始一个新项目时，都会新建一个文件夹，在里面放一个package.json，在./node_modules中安装模块。

Next.js扩展了这种结构，引入了一个放置顶级组件的文件夹叫pages。

例如，你可以新建pages/index.js，它会自动映射到/路由：

import React from "react"
export default () => Hello world

然后新建pages/about.js，它会映射到/about路由：

import React from "react"
export default () => 
About us

我们相信这是一个很好的起步默认配置，而且非常便于项目浏览。当需要更复杂的路由时，我们也允许开发人员自行控制[#25]。

启动一个项目所需要的所有操作仅仅是运行：

$ next

除非必要，没有额外的配置。自动代码热替换，自动错误报告，自动source maps，自动为老旧浏览器编译代码。

每个Next.js的路由都是一个仅仅是一个export一个函数或一个继承自React.Component的子类所构成的ES6模块。

这个方式和其他类似模型相比的好处是，整个系统都能保持高可组合性和可测试性。一个组件可以被直接渲染也可以被其他顶级组件导入并渲染。

组件也可以改变整个page的：

import React from "react"
import Head from "next/head"
export default () => (
  

    
      
    
    
Hi. I"m mobile-ready!
  
)

并且，不需要任何包装或改动就能对整个系统进行测试。只需在你的测试集中导入并shallow-render你的路由。

拥抱CSS-in-JS。通过使用glamor使得我们能在完全不理会CSS解析和编译的情况下拥有完整的CSS功能：

import React from "react"
import css from "next/css"

export default () => 
Hi there!

const style = css({
  color: "red",
  ":hover": {
    color: "blue"
  },
  "@media (max-width: 500px)": {
    color: "rebeccapurple"
  }
})

我们认为这种方式提供了无与伦比的性能，可组合性以及和服务器端渲染流程的良好集成。我们在FAQ中会讨论更多关于这个决定的一切。

有两个非常想实现同时又非常困难的任务：

服务端渲染

代码分割

在Next.js中，每个pages/下面的组件都会自动的连同内联的脚本一起被服务端渲染。

当组件是通过或路由自动加载时，我们会获取一个基于JSON的页面，这个页面同样会包含他自己的脚本。

这意味着一个页面可以有很多的imports：

import React from "react"
import d3 from "d3"
import jQuery from "jquery"

… 这并不会对其余的页面有任何影响。

这点对于那些需要技术业务需求不同的团队互相合作的场景下特别有用。一个组件的性能问题不会影响到整个系统。

服务端渲染的静态JSX确实非常了不起，但现实世界的应用往往需要处理来自不同API调用的数据。

Next.js给React的组件添加了一个重要的扩展：getInitialProps。

import React from "react"
import "isomorphic-fetch"
export default class extends React.Component {
  static async getInitialProps () {
    const res = await fetch("https://api.company.com/user/123")
    const data = await res.json()
    return { username: data.profile.username }
  }
}

我们关于转换哪些功能的立场简单来说就是：我们紧紧跟随V8。因为我们的目标是服务端和客户端的代码共享，当我们用Chrome或者Brave开发，并在Node上执行代码时，这种做法给了我们极好的体验。

正如你所见，我们的扩展非常简单：getInitialProps必须返回一个能resolve为一个JavaScript对象的Promise，该对象会被用来生成组件的props。

这使得Next.js能很好的和REST APIs、GraphQL，甚至是全局状态管理Redux等很好的协作，这有一个示例在我们的wiki上。

无论组件是服务端渲染的还是通过客户端路由动态加载的，都可以使用同一个方法获得数据：

static async getInitialProps ({ res }) {
  return res
    ? { userAgent: res.headers["user-agent"] }
    : { userAgent: navigator.userAgent }
}

我们认为即使没有网络也能给予用户即时响应的能力使得完全服务端渲染偏向“单页应用”或“完全没有服务端渲染”两个极端。

在www.zeit.co我们在Next.js上实现了一种技术，让我们能同时享受两种方式各自的好处：每个标签都会在后台通过一个ServiceWorker提前获取组件的JSON表现。

一旦预加载完成，如果你在页面上随意跳转，你点击的某个链接或路由已经提前加载好了。

更好的是，因为数据也通过一个专用的方法getInitialProps，我们能提前加载而不用怕引发不必要的服务端负载和数据加载。这比之前的web 1.0预加载机制强多了。

我们创建Next.js是因为我们相信同构的应用是未来web应用的重要组成部分。

提前绑定和编译（预测）是一个非常有效的部署方式。

部署一个Next.js应用只需要运行next build和next start。

你的package.json文件和以下类似：

{
  "name": "my-app",
  "dependencies": {
    "next": "*"
  },
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
  }
}

这样，你就简单的部署成功了。

最后，这是我们对于这个特定问题的贡献。我们认为他在灵活性和好用的默认配置之间取得了不错的平衡，不过这肯定不是解决所有问题的方法。

在接下来的几周里，我们希望能更多的讨论和思考其他解决方案，比如Vue.JS, Gatsby, Ember+Fastboot等等。
如果你有兴趣加入我们的社区，做出自己的贡献，请一定要加入zeit.chat, 查看issues，参与未来方向的讨论。