介紹

在 SPA 出現之前,Web 應用程式通常是多頁面的。這意味著每次用戶與應用程式互動時,伺服器都會發送完整的新頁面,然後瀏覽器會再次載入它。每次用戶在頁面之間導航時,都會發生完整的頁面重新加載,這可能會減慢速度並造成不太流暢的用戶體驗。類似的應用程式通常是使用伺服器端技術建立的,例如 PHP、Ruby on Rails、ASP.NET 等,這些技術在伺服器端產生 HTML 程式碼並將其發送到瀏覽器。

PHP Web 應用程式如何運作

Web開發人員是通用專家,他們同時負責前端和後端部分。隨著網路技術的發展和用戶的需求,需要新的解決方案,使他們能夠在沒有任何問題或等待的情況下使用互動式介面。

這就是第一個使用 BackboneJs 或 AngularJs 的 SPA 解決方案的出現。它們使我們能夠減少伺服器的負載(當時伺服器的資源有限),並在透過 JS 處理網頁時提供互動性,因為無需等待伺服器更新的新頁面。

這就是前端和後端部分的劃分。純粹前端開發人員的角色變得更加需求和多樣化。他們開始專注於建立使用者介面、使用 HTML、CSS 和 JavaScript,以及與 API 和伺服器互動。另一方面,後端開發人員變得更加關注資料處理、應用程式業務邏輯、使用資料庫和建立伺服器 API。

這就是我們進入 React、Angular2、Vue 和其他 Web 應用程式開發工具時代的方式。現在我們不再建立簡單的表單和列表,而是有 js 路由、狀態管理、瀏覽器 API、將授權令牌綁定到請求、資料映射等。

我們開始把簡單的事情複雜化。

透過這種方法,出現了以下問題:

  • 溝通協調困難。 Api 合約與通訊方法 — HTTP 1.1、Websocket、GraphQL。 JSON 解析和驗證。

  • 理解和認識上的分歧。例如,您可以開發一個建立許多查詢的前端應用程式,並將其視為正常且最佳化的 SPA。但對於後端來說,這是一個非常危險的情況,因為它現在需要大量的資料庫存取以及對這些資料的適當聚合,這會影響它的效能和維護。

  • 重複工作。後端的大多數 CRUD 操作在前端都有類似的行為。我們不只是從伺服器獲取列表,現在我們將其放入 store() 中,每個用戶操作都透過dispatch() 處理並等待請求執行,之後我們透過reducer() 更新store根據結果——後端對資料庫所做的一切,我們都會在前端重複。 (頁面重新加載和從伺服器將 SPA 恢復到當前狀態也值得一提 - 目前是一個單獨的痛苦)

  • 除錯和測試困難。現在您需要考慮可能的整合問題並在應用程式雙方的上下文中測試它們。是的,您可以為前端應用程式建立隔離的 e2e 測試,但它們不能保證生產中的可靠性。是的,有 ZoD 用於驗證伺服器回應,但它的使用百分比是多少?

  • 增加了開發時間和成本。對 API 合約的任何更改都需要兩個人同時進行。您不能像以前那樣直接將模板變更為伺服器。你需要集會、分成單獨的任務、商業分析專家等等來讓改變順利進行。

  • 搜尋引擎優化。由於我們的應用程式完全是透過 JS 建構的,搜尋引擎無法取得應用程式內容及其導航來正確索引它,因此需要 SSR 和 SSG 解決方案。

  • 安全。在頁面上輸入的任何關鍵資料在傳遞到伺服器之前都需要隱藏。此外,應用程式需要向伺服器請求大量個人訊息,從而洩露存取權杖。

那麼,通常的前端為什麼會消亡呢?

只需存取任何資源,您就會看到有多少職位空缺:

  • Python + Django

  • PHP + Laravel

  • NextJs + React

  • Nuxt + Vue

這些都是用於基於伺服器的 Web 應用程式開發的捆綁包。由於採用 Hydration 和 Resumability 方法,伺服器只能渲染介面的修改部分,而無需重新載入頁面。

他們提供什麼:

  • 伺服器應用程式現在不需要複雜的 HTTP 或 WS 合約並且雙方都支援它們,它可以使用更好的方法與 gRPC 等其他服務交換資訊。

  • 由於缺乏中間批准,更改過程更快,對於 1 人,用戶看到的結果會立即更改。

  • 測試可以全面檢查應用程式,消除整合測試並減少錯誤。

  • 您僅交換 HTML 標記,所有「請求-回應」邏輯對使用者來說都是隱藏的

  • 當您可以傳遞現成的範本時,為什麼還要傳遞大量 JSON 資料來將 SPA 還原到正確的狀態呢?

  • 你不需要擔心瀏覽器相容性,也不需要使用babel等工具,因為頁面上的JS程式碼很少。

隨著No-Code解決方案的出現、透過AI生成模板、龐大的伺服器資源和SEO需求——目前數量的前端開發人員和工具不再需要只開發前端部分。

企業主有一個合理的問題——“為什麼我需要雇用一個純粹的前端開發人員和一個純粹的後端開發人員來做一個簡單的應用程式?”

全端開發人員並不是一種管理時尚,就節省人員配備而言,現在它已成為中流砥柱。你不需要一個純粹的前端開發人員,你需要一個能夠製作整個應用程式、直接對資料庫或其他服務執行簡單操作並顯示結果的開發人員。

是的,毫無疑問仍然會存在需要前端和後端分離的複雜或“無頭”應用程式,但大多數應用程式將脫離 SPA 並沿著已經存在的方式發展,但現在我們有一個解決方案那些問題。隨著 HTMX 的出現,任何具有基礎知識的後端開發人員都可以建立 Web 應用程式。現在你甚至不需要了解 JS 就可以建立一個幾乎沒有邏輯的單頁應用程式。

你可能會問,「前端開發人員不僅負責 JS 邏輯,還負責 CSS 和適當的選擇器、HTML 及其語義,後端開發人員現在必須知道嗎? 」 — 不,現在人工智慧或「HTML 佈局設計師」可以根據 Figma 的佈局產生模板。 HTML 範本的邏輯和互動性現在在伺服器上定義。

結論

現在是思考您是否真的需要所有這些複雜的前端開發工具以及您是否應該保持純粹的前端開發人員的好時機。

我預計目前的前端開發人員將採用 60% 前端和 40% 後端的比例轉向全端資格,以保持相關專家的地位。 HTMX 只是開始,NextJs 或 Nuxt 工具的向量將會成長,Angular 類型的框架如果不能適應新的實作就會消亡,儘管 Angular 生態系統已經在 AnalogJs 上有了原型

資源


原文出處:https://dev.to/misterion96/the-front-end-development-were-used-to-is-dying-4e19


共有 0 則留言