最近，一位客戶聯繫我，詢問其 WordPress 網站上的「財務評估」javascript 應用程式不再運作。它有很多問題，最後，最簡單的方法就是重建它。

在此應用程式中，使用者可以輸入基本的財務和個人訊息，應用程式會告訴他們在財務規劃方面是否走在正確的道路上。這不是超級複雜的邏輯，但有相當多的邏輯。

我主要不是前端開發人員。我在後端最舒服。但我已經在 Vue、Angular、React 中實作了專案...它們工作，但我並不完全信任它們。隨著時間的流逝，我總是對依賴項（包括開發工具鏈本身）過時產生了一種隱隱的焦慮。

輸入微光

Gleam 是用於建立可擴展的類型安全系統的友善語言！
~ Gleam 的網站

自從 Gleam 首次宣布 v1 準備好投入生產以來，我一直對他們感到興奮。它的函數式風格、不變性、詳盡的模式匹配、類型推斷以及 Go 的簡單穩定性意味著 Gleam 滿足了我所有的喜好。

類型系統幾乎可以保證，如果您的程式碼可以編譯，它可以工作。我還沒有在我的 Gleam 程式碼中遇到過一個不是「我的錯，我忘了完成實現」的錯誤。

輸入光澤

Gleam 是為了在 BEAM（Erlang 傳奇的久經考驗的 VM）上運行而構建的，但它也有一個 Javascript 編譯目標。這意味著它可以輕鬆傳送到 Node 和瀏覽器。

Lustre 是 Gleam 卓越的前端框架。它是 Elm 到 Gleam 生態系統的忠實移植，並具有 Elm 的「模型 -> 視圖 -> 更新」狀態管理架構。

這是一個比其他前端架構更簡單的概念模型。 Lustre 的狀態管理模型並不是將狀態管理作為一個可選庫提供（我正在看你的 redux），而是它的核心。

您只需描述可以用來修改應用程式內的狀態的每個動詞，並將該動詞對應到返回模型更新版本的類型安全純操作。視圖函數（也是純函數）直接從該單一模型的狀態流動。

Lustre 還提供了一個託管效果系統，因此即使各種 I/O 操作可能會失敗，您的應用程式程式碼也可以使用完全純函數來實現。

純函數最酷的地方是什麼？在給定相同的輸入的情況下，它們保證始終提供相同的輸出。這使得它們可預測、易於測試並且極其穩定。純函數不會破壞。他們在數學上有點不能。

甜甜的樣板

Lustre 應用程式可能涉及位元更多樣板設定應用程式並建立所有類型等。但 ...

從來沒有一個更合適的框架來應用「樣板」一詞。它帶給我的自信就像將鉚釘釘入鋼板中。一旦就位，那東西就不會任何地方。

我很難表達與我之前使用 javascript 的經驗相比，這種感覺有多麼不同。如果我在另一個框架中完成，我的應用程式的 LOC 可能會更少。但我相信它不會破裂嗎？是不是就這麼簡單易懂了呢？

最終產品

我按時並在預算範圍內交付了我的應用程式。客戶對此非常滿意。我睡得很安穩，因為我知道這個專案確實完成了。

不僅如此，它還可以在所有地方的Wordpress中舒適地生活。我製作了一個短代碼來加載已編譯的資源，將其彈出到頁面上，就是這樣。

JS 套件經過壓縮和 gzip 壓縮後大小為 18.1 kb。這幾乎和 htmx 一樣小。大聲哭出來！

對於使用仍然相對晦澀的語言和框架來交付項目，我確實有一些保留。但知道應用程式不會崩潰，而且 Gleam 本身可以在一個下午學會，這些保留意見就得到了緩解。

最重要的是——老實說，如果我使用其他任何東西來構建它，我真的不認為我會對最終產品、工具鏈的穩定性或未來升級它的能力充滿信心.

我的心率

我現在開始寫這篇文章的全部動機：在生產環境中使用 Lustre 應用程式的感覺

這個應用程式發布已經有幾週了，我仍然喜歡時不時地重新訪問它。不是因為客​​戶要求改變。只是看代碼。

這麼說我幾乎感到尷尬，但我的大多數其他程式碼在某種程度上感覺像是一種責任。 特別是 javascript。即使它是 Typescript，即使它有測試。這讓我感到焦慮，就像佈滿了隱藏的地雷和誘殺裝置。

也許是技能問題。也許我只是被燒傷太多次了。

看著我的 Gleam/Lustre 程式碼讓我感到平靜。

就是這樣。這就是那條推文。

最後，我真誠地希望其他開發者能夠嘗試 Gleam 和 Lustre，這樣他們在思考他們的前端代碼時也能享受到同樣的禪宗般的幸福。

感謝您的閱讀。