作者 | Lew C 譯者 | 彎月

出品 | CSDN（ID：CSDNnews）

以下爲譯文：

1. 這些技術都需要瀏覽器插件才能運行。通常它們都需要平臺特有的瀏覽器插件才能在目標平臺上運行。Silverlight 就是一個很好的例子，當時使用 Linux 的人無法觀看 Netflix，因爲該網站採用了 Silverlight（Linux 不支持 Silverlight）。當然，我們有開源的替代方案，但沒有官方解決方案。

2. 它們引入了安全漏洞。Flash 就有此惡名（已知漏洞超過 1000 個）。瀏覽器必須加載插件才能顯示內容，此時瀏覽器的安全保護措施不再有效，因爲該插件擁有計算機上的所有權限。

3. 性能比不上純 HTML。就加載插件和顯示文本的速度而言，僅使用 HTML 和 CSS 的速度肯定超過了加載插件。

4. HTML 5 問世，CSS 得到了提升。突然之間，無需大費周折也可以建立美麗又愉悅的體驗感。有些瀏覽器討厭標準，而且還使用了特別手法或使用了特定於供應商的實現，雖然它們更好用，但是最終還是被幹掉了。

新時代的曙光

1991 年 8 月 6 日，互聯網誕生。隨後我們又經歷了互聯網泡沫。我們來想一想，1991 年互聯網問世，9 年後互聯網泡沫破滅，造成了 1.7 萬億美元的驚人損失。這意味着互聯網泡沫造成的損失相當於當年美國 GDP 的 15%。

我們經歷了這段歷史，因爲當時互聯網越來越流行，而我們編寫網站的方式也越來越標準。隨着時間的流逝，我們建立了 HTML 4 等標準，這些標準可以確保我們編寫的 HTML 可以在絕大多數 HTML 解釋器上運行。級聯樣式表（Cascading Style Sheets，CSS）也於 1996 年問世，而在此之前的一年，JavaScript 也進入了市場。你見過沒有 JavaScript 或 CSS 的網站嗎？我敢肯定，你的體驗一定不怎麼愉快。

但是，縱觀整個歷史，網絡的某些方面並沒有發生變化。平心而論，很多時候互聯網也是迫不得已：如果沒有迫不得已的原因，你肯定不想對 HTML 標準進行重大修改，所以對互聯網的工作原理進行大範圍修改的事情可能永遠都不會發生。於是互聯網就成了今天的樣子。

文檔

當互聯網剛問世的時候，人們並不能像如今一樣使用應用。可能有人還記得通過瘦客戶端，連接到另一端的大型機上。當時的 “應用” 僅僅是屏幕上的幾行文字。人們習慣了將一切都當作文檔處理，就像手頭可以閱讀的紙張一樣。因此，HTML 頁面最初的目的就是生成 HTML 文檔，這一點毫不令人奇怪。如果你曾用過 JavaScript，那麼肯定對 document.getElementById()等函數並不陌生。你在網頁上所做的一切操作都是爲了生成文檔，然後轉換文檔。

大多數網頁都太高，無法容納到一個窗口中。因此，用戶不得不用手指滑動頁面，或滾動鼠標。我想不出如今哪個網站可以正好顯示在一頁之內，因此開發人員必須要處理位於當前可見部分之上或之下的頁面。

但是，你仍然希望網頁的某些部分保持在特定的位置或以特定的方式對齊，那麼就需要使用 CSS 中的 position 等來控制元素的佈局。CSS 有數不盡的屬性（確切地說是 520 個），顧名思義，這些樣式會層疊到其子元素中。如果你試圖將文章的特定部分顯示成特定的樣子，那麼就會變得非常混亂。如果使用現有的樣式框架（比如 Angular Material），那麼情況也好不了多少，因爲你需要覆蓋框架自帶的 CSS，才能實現你想要的佈局。當然你可以使用! override 來覆蓋 CSS，但是如此做法不過是引鴆止渴罷了。讀到此處，你可能會想，“這個傢伙似乎對 CSS 毫不報希望啊。” 沒關係，我不會在這一點上與你爭論。但是，如果你的設計師對網頁外觀有一定的要求，那麼 CSS 就會變得非常複雜。

學習語言

爲了創建一個簡單的網站，你需要使用三種不同的語言，即 HTML、JavaScript 和 CSS，而且這只是針對網站本身的。網頁必須美觀，但如果你不知道如何編寫高效的 JavaScript 或 CSS 的樣式不好的話，恐怕就很難了。

如果你希望網站執行任何操作，則可以使用 Angular 或 React 之類的框架。隨着你通過 npm 引入軟件包，應用的規模也會增大，所以你還需要使用打包工具（比如 Webpack 等），將所有軟件包都打包到一起，並適當地縮小規模。Webpack 本身就是一個主題（而且還是一個大主題），但它是一個值得考慮的主題，而且相當一部分 Web 應用都是用它構建的。

打包與轉譯

在建立網站，並擁有了自己的軟件包後，你需要使用打包工具來打包客戶端應用，還需要確保能夠在瀏覽器中正常工作。根據使用的瀏覽器，你還需要添加一些功能，以便用戶的瀏覽器可以使用你的網站。如果你使用的是 TypeScript 之類的語言，則 Webpack 還可以將其轉譯爲 JavaScript。雖然這沒有什麼不好，但是這個過程非常複雜，而且還有很多可變因素。如果你的網站崩潰了，那麼究竟是哪裏出了問題？是代碼出了問題，還是在壓縮代碼的過程中出了問題？是 Webpack 沒有正確打包代碼，還是轉譯的過程出現了問題？這些複雜的流水線會加劇調試或查找根本原因的難度。

Flutter 好在哪裏？

即便你聽說過 Flutter，可能也是在移動應用開發的語境下。究竟如何將 Flutter 應用到 Web 開發呢？對於普通的 HTML 網頁，你可以將頁面作爲文檔來處理。但在 Flutter 中，“頁面”（或用戶與之交互的內容）實際上是繪製到 HTML 畫布上的。Flutter 控制着繪製到屏幕上的每一個像素，而且它不使用 HTML、JavaScript 或 CSS 來定義外觀或邏輯。（從技術的角度來看，原生 Dart 代碼通過 dart2js 轉換成了 JavaScript，但業務邏輯實際上並不是用 JavaScript 編寫的。）

這句話讓你喫驚的地方可能有兩個：首先，沒有 HTML；其次，所有的內容都是繪製到畫布上的。我能理解，這話聽起來有點奇怪，至少直接繪製到畫布上的性能可不好。下面，讓我們進一步研究一下。

繪製到畫布而不是文檔

首先，我們不使用 HTML 編寫網頁，也不會將內容寫入文檔。初聽之下，感覺很奇怪。但是，使用 HTML 開發網頁時，你究竟做了哪些工作？我們在前面就討論過了，你創建的文檔對於用戶設備的窗口來說太大了，你需要滾動。你正在閱讀的這篇文章，頁面的高度就超過了窗口大小，你需要不斷向上滾動。

仔細想一想，我們設計的用戶界面超過了窗口的縱向大小，用戶必須滾動頁面才能瀏覽全部內容，這不是很奇怪嗎？如果你希望用戶從左到右（不是從上到下）滾動窗口，該怎麼辦？恐怕在普通網頁上可不容易實現。

在 Flutter 中，如果想讓某一部分內容水平滾動，就只需要將小部件包裝到 SingleChildScrollView。你也可以指定滾動條的方向，無論滾動條是在垂直方向還是水平方向上滾動。

因爲 Flutter 的基本概念是，在單獨的小部件中繪製文檔，而不是將文檔繪製到屏幕上，所以開發人員完全可以控制如何佈局應用程序。

只使用一種語言

如前所述，爲了創建一個出色的網站，你必須掌握 HTML、JavaScript 和 CSS。這也意味着，你所需的知識無法在這些語言之間融會貫通，例如，你不能在 HTML 中使用任何 JavaScript 的知識。HTML 純粹是標記語言，CSS 純粹是樣式語法，而 JavaScript 純粹是編程語言。這些語言都不包含類型檢查等功能，所以雖然 CSS 看似很完整，但在用戶使用頁面的時候，就會悄無聲息地出問題。

Flutter 採用了 Dart 語言，並使用 Dart 編寫了應用程序的所有外觀和業務邏輯。Dart 具有靜態類型檢查，而且即將推出 null 安全性，因此應用程序中的每一行代碼，無論是描述應用的外觀，提供樣式，還是控制業務邏輯，都是類型安全的。

輕鬆佈局

一般來說，網站顯示的數據來自其他源頭：無論是數據庫、API 還是其他來源，我們都希望數據能夠按照預期顯示出來。想象一下，我們有一組從 API 返回的對象，而你使用了 Angular 的對象來顯示它們。通常，你需要將這些對象加載到支持組件中，然後使用 * ngFor 迭代所有對象。你需要添加 div。但是，這些沒有樣式的 div 看起來會過於蒼白。如果你希望列表中的各項顯示在列或行中，則必須使用 CSS 或 flexbox 來實現。

而在 Flutter 中，你可以使用 Column 或 Row 來佈局這些數據，Column 或 Row 的 children 屬性可以接受對象數組。仔細想一想，在大多數情況下，你可能會希望對象列顯示成一排或一列。在 Flutter 的幫助下，你可以快速完成視覺上的佈局，然後再爲列表中的各項設置樣式。根據我的經驗，你可以更快地完成腳手架和原型製作，同時不影響最終結果。

控制窗口中的每個像素

由於 Flutter 會將每個像素渲染到屏幕上，因此設計人員和開發人員可以完整地控制自己想要的應用或體驗。渲染屏幕上的每個像素聽起來會造成巨大的性能損失，但請不要誤會我的意思，這種做法當然不如渲染 HTML 的速度快，但是在 GPU 的加速下，性能也得到了提升。根據傳統的做法，設計 HTML 的網頁意味着，你必須考慮不同的瀏覽器。然而，在 Flutter 中，給 Text 小部件設置的字體無論在何處顯示，最後的效果都一樣，因爲 Flutter 可以控制每個像素的外觀。

再見，Webpack！

由於 Flutter 使用了 Dart，因此在針對目標平臺編譯 Flutter 應用時，它會把所有相關的軟件包（也是用 Dart 編寫的）都轉換成 JavaScript。Dart 是一種類型安全的語言，不支持反射，因此編譯器可以更好地瞭解應用需要調用什麼以及不需要調用什麼。這有助於我們進一步將應用的規模降到最小。在 Web 上構建 Flutter 應用不需要使用 Webpack，因爲它不需要 Webpack，這是 Flutter 本身的一大優勢（至少在我看來是優勢）。並不是說 Webpack 有問題，Webpack 是一款高質量的軟件。只不過它是複雜的流水線中的一款複雜的工具。

但是我們的目標還沒有實現

Flutter 不僅可以提供新潮的網頁，引人入勝的動畫和精美的體驗，而且還可以更進一步。我們需要服務器端渲染（server-side rendering，SSR），以便我們的網頁可以被搜索引擎抓取，然後執行搜索引擎優化（SEO）。目前 Flutter 網站只面向人類用戶，不能被搜索引擎解讀，因此會對網站搜索和查找信息的方式產生巨大影響。（人們正在就此問題進行討論，近期內還沒有解決方案）。

此外，將所有內容繪製到畫布上確實對性能有影響，但沒有那麼糟糕。我構建了一個測試應用，使用了大量視覺效果，在 MacBook 上能夠以接近 60fps 的速度運行。在沒有經過任何優化的情況下，即使拖動屏幕，也仍然可以正常工作，在性能不足時會逐步降低背後的圖像的清晰度。

在被視爲 Web 開發的主流技術之前，Flutter 還需要改進幾個關鍵領域。話雖如此，畢竟 Flutter 誕生才兩年，其性能和功能集已經達到了令人驚歎的水平。

如果可以創建一個性能卓越的網站，而且只需一種語言就可以設計、樣式化和編寫完成 Web 應用的業務邏輯，你感覺怎樣？如果開發流水線無需再使用 Webpack 呢？如果你能及時獲得服務器端渲染，而且基於 HTML 的傳統網站所擁有的 SEO 優勢也統統沒落下呢？你會動心嗎？

如果所有這些都成爲現實，那麼 Flutter 就會贏得整個 Web。

原文鏈接：https://betterprogramming.pub/flutter-is-about-to-win-over-the-web-be0a205af03d

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/o4y3LTEBADTCnN4tNusUTA