1. 程式人生 > 其它 >Flutter 打包與轉譯 編譯 Flutter 即將佔領整個 Web 開發

Flutter 打包與轉譯 編譯 Flutter 即將佔領整個 Web 開發

Flutter 即將佔領整個 Web 開發 https://mp.weixin.qq.com/s/o4y3LTEBADTCnN4tNusUTA

Flutter 即將佔領整個 Web 開發

Lew CCSDN2021-03-22

作者|Lew C 譯者|彎月

出品 | CSDN(ID:CSDNnews)

以下為譯文:

現如今的各個網站,包括你現在正在使用的這個網站,都是通過HTML、JavaScript和CSS編寫的。如果要求在建立網站的時候,不要使用這三種技術中的任何一種,你可能就會問為什麼。

然而,縱觀整個Web開發的發展歷史,我們就會發現該領域湧現了很多技術,比如曾經的Flash、Silverlight等,所有具備競爭力的技術都曾嘗試在瀏覽器的市場中分一杯羹,希望開發人員使用不同的技術來建立網站。然而,它們最後的結局大多雷同:出師未捷身先死。而我又憑什麼告訴你這片廣闊天地中又多了一位競爭對手呢?尤其是該領域的眾多技術在經過數年的努力之後,無一能夠找到出路。

彆著急,我們先來分析一下過去這些技術的共同點:

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

  2. 它們引入了安全漏洞。Flash就有此惡名(已知漏洞超過1000個)。瀏覽器必須載入外掛才能顯示內容,此時瀏覽器的安全保護措施不再有效,因為該外掛擁有計算機上的所有許可權。

  3. 效能比不上純HTML。就載入外掛和顯示文字的速度而言,僅使用HTML和CSS的速度肯定超過了載入外掛。

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

如此種種跡象表明,選擇原生HTML建立新Web應用更加容易。畢竟,如果建立Web體驗所採用的技術被棄用,而且收不到安全修復程式,那麼你將別無選擇,只能另選一種新的支援語言重新編寫應用。但是,為什麼如今會是這樣一種局面呢?為何HTML成為了蓬勃發展的網際網路的支柱呢?

新時代的曙光

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

宣告:本文由CSDN翻譯,轉載請說明來源。