無招勝有招：爲什麼咱們沒有及早悟到這個辦法？

使用原生JavaScript編寫正式的應用，在所不免會陷入複雜的境地，然而編譯器能夠鼎力相助。

注意：原文發表於 2016-11-26，隨着框架不斷演進，部份內容可能已不適用。

慢着！這個新框架也有運行時？呃……就此謝別，江湖再見。
—— 2018年前端開發者

咱們向用戶濫發了過多的代碼。

—— 但我和前端開發者們同樣，對此矢口否定。

畢竟，讓頁面加載一份 100KB 的 JS 實在垂手可得，不過是少用一張 jpg 罷了。

—— 當應用已經具有交互性時，更爲重要的是性能。

然而，我錯了。

100 KB 的 JS，並不等同於 100KB 的 jpg。

不只網絡開銷會下降程序的啓動性能，還有解析和評估腳本所耗費的時間，在此期間瀏覽器會徹底失去響應。在移動設備上，這種時間損耗的境況尤甚。

若你對此心存質疑，不妨在 Twitter 上關注 Alex Russell，Alex 雖然在框架圈裏朋友寥寥無幾，但他確實是言之有理。

Polymer 是相似 Angular、React 或 Ember 的替代方案，但仍未在前端界得到關注，天然也不是由於缺乏市場營銷。

總而言之，或許咱們須要反思一下框架這個事情。

框架真正解決了什麼問題？

通常而言，能夠認爲框架更爲容易管理代碼的複雜性。

框架使用 Virtual DOM 差別比較等技術，從更高層次對繁瑣的實現細節進行抽象。

然而……事實並不是如此。

最優的狀況下，框架能將複雜性的代碼從之前的必寫轉化爲不寫。

相反地，React 之類的思想之因此如此流行並得到成功，全因它們創造的新概念使得管理複雜性更爲容易。

框架是構築思想的工具，並不是代碼。

有鑑及此，咱們假設瀏覽器上若是再也不加載和運行框架的狀況呢？

與前述的 React 背道而行，假若用一種辦法直接把您的代碼轉爲原生的 JavaScript 呢？就如 Babel 將 ES6+ 的代碼轉爲 ES5 同樣，會輸出什麼樣的結果呢？

—— 這樣您的代碼在前期將不需再揹負大量的框架運行時，程序會變得飛快！

由於您的程序和瀏覽器之間，再也不有所謂的抽象層。

Svelte 登場

Svelte 就是爲此而生的新框架。

您使用 HTML、CSS 和 JavaScript 編寫組件（還有一些您能夠在5分鐘內學會的額外內容），在構建過程當中，Svelte 將其編譯爲微小且獨立的 JavaScript 模塊。

經過靜態分析組件模板，咱們能確保瀏覽器所作的工做盡量少。

Svelte 實現的 TodoMVC 壓縮後體積僅 3.6KB。

相較於沒有任何業務代碼的 React + ReactDOM，其壓縮後體積約爲 45KB。

在瀏覽器中，評估 React 使用交互式 TodoMVC 啓動和運行所需的時間，React 花費的時間大約是 Svelte 的 10 倍。

根據 js-framework-benchmark 所示，一旦啓動並運行你的 Svelte 程序，它的速度超級快！

它比 Reack 快，比 Vue 快，比 Angular 快，比 Ember 快，比 Reactive、Preact、Mithril 通通都快，一個能打的都沒有。

除了 Inferno，這是一個有力的競爭對手，它多是目前世界上最快的 UI 框架，由於 Dominic Gannaway 是一個嚮導程序。（Svelte 移除元素的速度較慢，咱們正爲此努力）

它基本上和原生 JS 同樣快，這是有其因由的，由於它就是原生 JS，只不過你不用真的去寫原生 JS 而已。

但，這不是最重要的

性能固然很重要。

不過用這種新的方法真正使人興奮的點就在於，咱們終於有辦法解決 Web 開發中最棘手的問題。

試考慮一下這個場景：

假設您要 npm install cool-calendar-widget 安裝一個小組件，而後在程序中使用它。

在以往您得先確認這個小組件所基於的框架（以及正確的版本號）是什麼，以後才能 npm 安裝和使用它。

若是 cool-calendar-widget 是一個 React 內置的組件，而您正在使用 Angular 的話，那麼……好吧，這狀況就令人以爲如鯁在喉，難如下嚥了。

可是，若是小組件的做者使用的是 Svelte（生成不依賴框架的代碼），則您可使用任何現有的技術來使用這個小組件（在代辦列表中，會提供一種方法將 Svelte 組件轉爲 Web Component 的方法）。

同時代碼分割也是一個很好的想法，只需加載用戶所需的初始的 UI 視圖，而後其餘視圖後續再取）。

可是存在一個問題。

即便您最初只是提供一個 React 組件而不是100個，您最終程序在運行時仍然須要 React 這個庫自己。

使用 Svelte，代碼分割會更加有用，由於框架是嵌入到組件中去的，而且組件體積也小。

最後談一下，我做爲一個開源維護做者，一直致力要解決的問題：用戶老是但願優先考慮他們提的 features，而忽略了不須要這些 features 的用戶的使用成本。

框架做者須要始終平衡項目長期的健康情況，以及知足用戶需求的願望。

這裏頭的困難大得使人難以置信。

由於項目是難以預測（更別提）急速增量的後果，它須要一些委婉的軟技能來告訴人們（這些人可能一直在熱情地幫您宣傳），他們提的功能並不足夠重要。

但若是用的是 Svelte，許多功能特性就能夠方便地被添加了，那麼那些不須要這些特性的人，也沒必要付出任何代價，由於實現這些特性的代碼，非必要的狀況下是不會被編譯器拿去生成最終產物的。

咱們只是初顯身手

Svelte 還很新。

百事待舉：建立 build 工具集成、添加服務端渲染 SSR、熱加載、transition 等等。

還有文檔、示例和入門教程等等。

不過您已經可使用它來編寫組件了，這是爲何咱們直接就發佈 v1.0 的緣由，您能夠閱讀入門教程，而後在 REPL 中小試身手，也能夠前往 Github 幫助咱們開啓下一個前端開發新時代！