摘要：無數的模板語言和框架應運而生但是技術始終被分割為前端和后端。這意味著一個頁面可以有很多的這并不會對其余的頁面有任何影響。提前綁定和編譯預測是一個非常有效的部署方式。最后，這是我們對于這個特定問題的貢獻。

原文地址

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，參與未來方向的討論。