上一次寫前端趨勢這一類的東西，是在去年的這個時候。一年多過去了，又發生了怎樣的變化呢？

One JavaScript：移動應用

前有，使用 React 及 React Native 來開發 Android 及 iOS 應用。

後有，Dart 通過 Google 的 Flutter 框架來支援移動應用程式開發，該框架旨在為 Android 和 iOS 建立原生 UI。

使用同一種語言作為業務開發語言，再基於一個 DSL 來封裝基礎平臺的架構，已經成為了一種大的趨勢。過去，在後端的這種語言是 Java；現在，這種語言則是 JavaScript。

One JavaScript：Serverless 與 全棧

對於沒有後臺經驗的前端開發人員來說，使用 Node.js 開發後端應用是一種相當大的挑戰。大多數非科班的前端程式設計師，不知道從資料庫到 RESTful API 的一系列操作，並且還需要了解到部署等一系列的系統底層知識。因此，使用 Serverless 這種不關心基礎設施的技術，可以進一步地降低開發成本。

使用 AWS 來執行大量的 Serverless 計算的成本很高，但是自己搭建一個 Serverless 伺服器，來執行自己的 Serverless 應用，則變成了一種更廉價的方式。

有興趣的讀者可以閱讀我在 GitHub 上寫的《Serverless 架構應用開發指南》，地址：https://github.com/phodal/serverless

Function！Function！Function！

2017 年 9 月，在接手一個 React 專案的時候，發現在這個 React 專案裡，Lodash 已經變成了 Ramda。初次上手時，和我之前維護一個 Scala 的微服務有著一致的體驗，這貨真難懂。但是毫無疑問地是，它大大減少了程式碼量。只是不同的人寫出的函式式程式碼是不一樣的，所謂的千人千碼

函數語言程式設計可以減少一定量地冗餘程式碼，它也帶來了一定的新問題：可維護性及上手複雜度。

但是越少的程式碼，可能意味著更少的 bug，不是嗎？

架構：BFF

我的上一個客戶端專案裡，採用了 BFF 層，其對於大前端來說，是一種很友好的開發體驗。對於存在 Android、iOS 及 Web 應用的系統來說，BFF 層不僅僅可以減少應用的開發時間，還可以提高業務的靈活性——只需要在修改 BFF 層的情況下，就可以使三端達到一致。

問題：更臃腫的 SPA

在過去的幾年，大量地前端專案已經使用 Angular、Vue、React、Ember 等框架重寫。使用哪種框架，對於一個前端專案來說，差別並不大。

從零啟動一個前端專案是一件容易的事，但是問題的關鍵在於，我們不可能不斷地重寫前端專案。於是，對於前端專案來說問題變成了，如何去維護一個前端專案。

如果一個專案中的前端開發人員水平參差不齊，但是沒有輔以有效的程式碼改善方式，如 CheckStyle、Code Review、測試 等等。那麼，未來它必是一個痛苦的遺留系統。

在新的專案裡，我也著手去解決這樣的問題。

選型：Angular、React、Vue

我喜歡大而全的框架，而不是小而美的框架。小而美的框架，維護成本太高了——這裡討論的是維護成本，也就是你在這個軟體上可能還要繼續開發一年，兩年，而不是幾個月。所以，如果你沒有在一個前端程式碼庫裡，工作一年、兩年，不要和我討論這一個問題。小而美的框架裡，元件間依賴，版本間限制，上下游同步等，在時間線上就是各種麻煩的問題。在工作上，花費大量時間解決這種技術問題，真的很不爽——只會導致加班。

如果只做的是複雜的 Web 應用，基本上就是 Angular 了。因為要用 Angular，就需要會 TypeScript -> 強型別、RxJS、註解、依賴注入等等——需要學習的時間長，程式碼質量上有一定的保證，應該不怕遇到小白，笑~~。

不選擇 React 的主要原因是，React 只是一層 View，整個系統在配置上太麻煩了，Angular 上手即用。

如果同時做 Web 和 APP 應用的話，那麼在 Web 方面就是 React，畢竟 APP 可以用 React Native。

我沒有在複雜的 Web 應用裡，使用過 Vue，不好做太多評價。以我在一些公司專案上和個人專案上的使用經驗來說，Vue 的最大優勢是簡單，同時可以幫助我們漸進式的遷移前端應用。

對了，我更喜歡 TypeScript，因為它看上就像是 EcmaScript 的終極版。

你呢？2018 怎麼想的？