JavaScript 正在殺死網頁瀏覽器

99% 無 JavaScript 的 Web：可能嗎？

JavaScript 是不可預測的、陳舊的，有時會讓我嘔吐。我不想再用它了。現在，這句話非常適合吸引您的注意力，但同時它也是錯誤的，因為開發人員不能沒有 JavaScript，尤其是前端開發人員。
這次探索是為了尋找避免 JavaScript 的方法。當我說「避免 JavaScript」時，我並不是建議使用轉譯為 JavaScript 的東西。我實際上的意思是，我只想在應用程式程式碼的最終輸出中使用非常少的 JavaScript。

在 YT 上觀看此內容

JavaScript 的過度使用：為什麼這是一個問題

當今的開發人員在從前端框架到 API 互動的所有方面都嚴重依賴 JavaScript。但我們真的需要如此依賴它嗎？正在發生的事情是這樣的：當有更簡單、更有效率的替代方案可用時，開發人員常常感到使用 JavaScript 的壓力。

採用流行的框架，例如 React、Vue、Angular 和 Svelte。這些對於創建動態和響應式網站來說非常棒，但對於更簡單的應用程式來說可能有點過頭了。它們引入了不必要的複雜性，最終增加了學習曲線並使維護變得令人頭痛。

那麼，JavaScript 有什麼問題呢？

廣泛使用會帶來幾個關鍵痛點，包括：

1. 載入時間較慢 – 大型 JavaScript 套件會降低頁面效能。您新增的每個庫都會增加項目的重量，從而導致載入時間變慢。
2. 客戶端渲染問題 – 許多框架不必要地依賴客戶端渲染，這可能會導致延遲和效能問題。例如，React 應用程式使用虛擬 DOM 重新渲染整個網頁，從而在網頁變得可互動之前添加更多時間。
3. 嚴重依賴 – 新增的函式庫越多，遇到相容性、版本更新和依賴衝突的問題就越多。
4. 隱藏的維護成本 – 跟上不斷的更新和過度依賴軟體包帶來的潛在破壞性變化在時間和資源方面都變得昂貴。

JIT 編譯器：天啊！

JavaScript 嘗試提高效能的關鍵領域之一是透過 JIT（即時）編譯。現代瀏覽器，例如 Chrome 的 V8 引擎，會在執行時將 JavaScript 編譯為機器碼。

目標是讓 JavaScript 盡可能快。

但是，這種最佳化是有代價的。 JIT 編譯器有時會改變 JavaScript 程式碼的行為，經常引入錯誤和意外問題，這可能會使您的 Web 應用程式變得脆弱。簡而言之，JIT 編譯器的最佳化可能是一場賭博。

常見的 JIT 編譯器錯誤

以下是一些更臭名昭著的錯誤：

• 錯誤編譯：如果 JIT 編譯器錯誤最佳化程式碼片段，它可能會產生不正確的輸出。
• 邊界檢查消除：在嘗試最佳化時，JIT 編譯器可能會跳過必要的檢查，例如陣列邊界，從而為崩潰打開大門。
• 冗餘消除：當 JIT 編譯器認為重複的程式碼是冗餘的時，它可能會消除重要的部分，從而導致不可預測的行為。

這些編譯器問題強調了廣泛測試 JavaScript 以避免意外問題的重要性。但更重要的是，它們顯示了為什麼我們需要盡可能減少 JavaScript以降低新問題的風險。

JavaScript 的客戶端替代方案

好消息是您不必陷入 JavaScript 循環。已經出現了幾種替代方案來減少 JavaScript，同時保持功能性。最令人興奮的兩個選項是 HTMX 和 WebAssembly。

HTMX：類固醇超媒體

HTMX 允許開發人員使用最少的 JavaScript 來建立動態、互動式 Web 應用程式。 HTMX 不再依賴 JavaScript 進行每次交互，而是從伺服器發送實際 HTML，從而減少了使用 React 等 JavaScript 框架重新渲染整個 UI 的需要。

想像一下：HTMX 讓您能夠直接從後端發送 HTML，從而減少客戶端流失，而不是發送回 JSON 回應以供前端處理。 HTMX 依靠傳統的 HTML 錨點和表單直接呼叫伺服器 - 完全不需要 JavaScript。

Why HTMX Rocks:

• Minimal learning curve – Add a few attributes to your HTML, and you're up and running.
• Works with HTML – Avoid manipulating the DOM using excessive JavaScript.
• Graceful fallback – Even if someone disables JavaScript in their browser, your HTMX-powered app will still function, albeit without some of the bells and whistles.

In a world where many apps break without JavaScript, HTMX ensures wider compatibility and better performance. It goes back to basics, making requests directly from HTML elements, tackling interactive components like forms or clickable elements without bloating your app with scripts.

WebAssembly: A Performance Powerhouse

When it comes to WebAssembly (Wasm), the intent isn’t to replace JavaScript entirely, but to handle tasks that are computationally heavy. This could be game performance, data science calculations, or image processing, where JavaScript just doesn’t cut it from a performance standpoint.

With WebAssembly, you can compile languages like C, C , and Rust to perform specific, computation-heavy tasks on the client-side without using JavaScript. This makes WebAssembly ideal for tasks like video editing, gaming, or data processing, all within a web browser.

WebAssembly’s Major Benefits:

• Highly performant: Optimized for CPU-heavy tasks that JavaScript struggles with.
• Runs directly in the browser: Like JavaScript, it benefits from browser support but doesn’t require JavaScript parsing/rendering inefficiency.
• Portable: Same code can be compiled and run across browsers with superb efficiency.

For any site that needs to handle lots of computation, WebAssembly can speed things up and slash loading times.

Server-Side: Time to Ditch JavaScript?

While JavaScript was once confined to the client side, the introduction of Node.js has made it extremely popular on servers too. Node has a lot going for it: Asynchronous event handling, non-blocking I/O, and, of course, using one language across the stack. But JavaScript’s pitfalls (dynamic typing, security risks like prototype pollution, and increased complexity) still linger.

Luckily, we’ve got 100% alternatives to JavaScript on the server side. Here are a few:

1. Go (Golang)

Go’s lightweight goroutines allow for highly concurrent, scalable systems without the memory overhead of threads. This language is especially suited for applications that need blazing-fast performance with large-scale traffic.

2. Django (Python)

Django is a favorite when it comes to security. It reduces vulnerabilities like prototype pollution and Redos Attacks (which JavaScript is prone to). While it might not scale like Go, Django is perfect for smaller or security-conscious applications.

3. PHP (Laravel)

PHP has always been a reliable backend language, and its modern framework, Laravel, makes small to medium projects easy to manage. With automatic routing and a great ecosystem of plugins, PHP still has its place in the development world, despite JavaScript's rise.

4. Ruby on Rails

For rapid development, Ruby on Rails offers an elegant, developer-friendly environment. While it might not be the best at handling large-scale applications, it's perfect for small teams aiming for quick, scalable solutions.

The Hidden Costs of JavaScript Frameworks

Using more JavaScript, especially for everything on both the client and server sides, incurs a number of hidden costs. The larger your JavaScript bundle, the more problems you'll face. Here's what you're up against:

• 套件膨脹 – 新增的函式庫和相依性越多，最終輸出就越會因不必要的程式碼而膨脹。
• 增加維護 – 讓這些依賴項保持最新會產生維護開銷，並且在庫進行重大更新時可能會破壞您的應用程式。
• 重大變更 – 框架更新（甚至小型函式庫更新）可能會破壞現有功能，讓您必須重寫大部分程式碼。

解決方案？優先考慮性能和安全性

最終，減少 JavaScript 不僅是為了避免錯誤或緩慢的載入時間，而是為了建立更快、更簡單、更安全的 Web 應用程式。透過將繁重的計算卸載到WebAssembly，使用HTMX 本地處理UI 更新，並將後端邏輯移至Go 或Python等更安全的語言，您將大大改進您的網路專案。

雖然完全消除 JavaScript 可能不適合每個人，但盡可能減少 JavaScript 絕對值得追求。這一切都是為了使用現代替代方案來避免將 JavaScript 變成開發人員的瓶頸。

結論

無論您的目標是最小化客戶端還是伺服器上的 JavaScript，您都可以使您的 Web 應用程式更精簡、更快、更安全。 HTMX 和 WebAssembly 為 JavaScript 密集型前端開發提供了令人興奮的替代方案，而 Go、Django 和 Laravel 是後端的可行選擇。

JavaScript 會繼續存在，但我們不需要一切都依賴它。透過策略性地減少 JavaScript 的佔用空間，我們最終可以建立效能更好且無縫擴展的應用程式。

準備好減少 JavaScript 並控制您的網頁應用程式了嗎？今天就開始嘗試吧！

以上是JavaScript 正在殺死網頁瀏覽器的詳細內容。更多資訊請關注PHP中文網其他相關文章！