如果前端不使用SPA又能怎樣？- Hacker News

banq發表於2020-10-29
前端

一篇《如果前端不使用SPA又能怎樣？》引發討論，這篇文章探討除了React.js以外其他框架：Remix，RedwoodJS和Blitz.js。
以Remix為例，它將資料載入與路由重新聯絡起來，然後給出了一個驚人的承諾，即預設情況下不會提取任何客戶端資料。這些框架還考慮了狀態碼和快取策略。RedwoodJS使用GraphQL和Prisma自動建立類似於ORM的介面。
值得一提的是Turbolinks。Turbolinks 5的目標是：在沒有應用程式任何合作的情況下，獲得SPA體驗所需要做的最低限度是什麼？
這是一個很小的JavaScript庫，它位於現有的伺服器呈現的應用程式之上，並用類似SPA的部分頁面載入代替了完整的頁面載入。無需從頭開始載入頁面，而是使用AJAX載入頁面，替換頁面內容，並且客戶端導航更新您的URL。基本上，它防止了實際頁面轉換的“閃爍”，並節省了完全載入新頁面的所有其他成本。Turbolinks是從Ruby on Rails專案衍生而來的，可與Rails很好地配合，但不需要它。
就改善使用者體驗的權重而言，Turbolinks是一個傑出的產品：它為複雜的使用者體驗帶來了極少的複雜性和很小的尺寸影響。
該文還提到了伺服器端的狀態框架：主要競爭者是Laravel Livewire（PHP），Stimulus Reflex（在Ruby on Rails中使用）和Phoenix LiveView（在Phoenix中的Elixir中使用）。這些框架令人興奮，並且也極度叛逆，因為它們與“前端+不可知API層”模式截然相反，而且它們還全心全意地接受了每個人都想避免的事情：伺服器上的可變狀態。
 
各種觀點：
從我第一次接觸Angular以來，我就一直感覺到這個問題。除非您想製作一個真正的互動式非同步應用程式（例如Google Docs或Facebook Chat），否則它會變得更加複雜和脆弱，而實際上沒有任何好處。
當SPA成為規範，甚至需要使用React構建靜態網頁時，開發效率也越來越低。我看到整個團隊都在努力構建簡單的應用程式，並浪費了數月的時間，而這些團隊過去通常只用一兩個開發人員在幾周內就在經過驗證的伺服器端框架上進行開發。但是，這不再符合最佳實踐和行業標準。一切都需要是SPA，微服務，分散式資料庫，Kubernetes等。這些元件和層需要透過反覆試驗將其粘合在一起。
我很高興常識開始流行，越來越多的開發人員開始意識到整合的端到端框架對於許多現實應用程式開發場景非常有用。
 
有趣的是，我發現事實恰恰相反。我從事前端程式碼的開發已有十多年了，但是我從來沒有比現在做得更快，編寫的錯誤程式碼也更少。那是因為我已經成為一名更好的開發人員了嗎？當然可以。但總的來說，我不認為這最終是原因。我認為這是技術的成熟。我作為一名程式設計師的發展幾乎不是線性的，過去的5年與我在前5箇中取得的增長不匹配。前端工具從來沒有比現在更好。
我相信，構建Web應用程式的門檻已經降低，並且程式設計師比以往任何時候都更多。您可能不是在前端開發和javascript方面試圖構建複雜的UI和應用程式的專家。因此，您選擇了一個沒有必要經驗的人，並使用真正簡單易上手的框架，將他們投入到很多深度（前端）正規化中進行工作，但是會因濫用這些複雜問題而使它們陷入困境。
另一個因素是，由於SPA是有狀態的，因此複雜性會激增。一頁不是在每隔幾秒鐘重新整理一次無狀態頁面，而是導致錯誤在會話持續時間內抬起頭。這些經驗不足的人負責設計不會擴充套件且不會成為義大利麵條的程式碼庫。但是，如果設計合理，這些問題將大為消除。
我並不是在主張SPA是解決所有問題的方法。我認為整個行業都嚴重濫用SPA，但這並不是對SPA本身的抱怨。而是因為選擇錯誤的技術來解決當前問題的人。
 
根本的問題不是SPA模式不好，而是要花費大量的技巧和精力來製作適當的SPA。顯然，技能和時間是稀缺資源，其結果是大多數SPA都是廢話。
與jQuery時代相比，所有這些基於元件的OTOH框架無疑為我們帶來了一種更好的方式來產生互動式體驗。這根本與SPA不相關。您可以在多頁應用程式中使用React / Vue / etc。問題在於，要混合（互動）伺服器渲染的HTML，您現在需要在伺服器語言和前端框架之間複製標記。解決方案是在後端和前端使用相同的框架，並只編寫一次元件。
 
我現在正在使用TALL堆疊（Tailwind，Alpine.js，Laravel和Livewire）構建一個應用程式，並且我的生產力令人難以置信。所需的構建步驟非常少（根據.blade.php檔案中使用的類，編譯Tailwind以減小大小）。我非常喜歡CRUD，圖片上傳等操作。一開始我很懷疑，但現在我喜歡這種構建Web應用程式的方式。不知道它的擴充套件性如何，但是對於一個簡單的MVP，我一直沒有要求更好的堆疊。
  
我在工作中專業地編寫了完整的SPA。我們使用React，Apollo，GraphQL，Webpack等。TALL堆疊充滿了新鮮空氣。我當時甚至無法開始解釋我的喜悅。只是高興。
現在，我不得不寫那些無限的JS程式碼，相沖突的依賴項，緩慢的構建時間，React鉤子狀態管理等時間。
當我與我的同事談論技術時，他們似乎都喜歡JS開發人員的糾結，並願意使用釋出的任何新框架。我一直在努力爭取良好的舊可靠SSR。儘管經常被稱為“怪異”，但是卻偏愛老式技術。
我想我更喜歡更好的開發人員體驗和更短的生產/上市時間，而不是花幾天時間嘗試建立一個專案並找出奇怪的怪癖和問題，例如“無伺服器的現代Web應用程式”這樣複雜的混亂。
 
我使用Turbolinks + Stimulus方法取得了巨大的成功。有兩種常見的模式，例如，延遲載入內容（基本上是具有URL屬性的<div>，您可以透過AJAX進行激勵載入），並確實傾向於Rails的遠端連結/伺服器javascript響應模態和小頁面更新。
與大多數React / SPA程式碼庫（您可能在一整天中將一整天的時間傳送出去）相比，仍然具有很高的生產力，能夠在幾個小時內完成一個應用的幾頁真是太好了。
 
大約2年前，我第一次在新的Rails應用程式上使用了Turbolinks，但由於受到影響而感到震驚-就沒有頁面載入和整體速度而言，它就像是SPA。
我堅信這是針對大多數用例的解決方案，結合了對React元件或Stimulus之類的選擇性使用的組合，在這些情況下您需要更復雜的UI元件。



 

相關文章