JavaScript 對全端框架的需求
「為什麼我們沒有適用於 JavaScript 的 Laravel？」。這是西奧在他最近的影片中提出的問題。
如果您不熟悉Laravel和Ruby-on-Rails等工具，它們是固執己見的全端框架（適用於 PHP 和 Ruby），具有許多遵循既定約定的內建功能，以便開發人員可以編寫更少的樣板檔案和更多的業務邏輯，同時將行業最佳實踐融入他們的應用程式中。
他回答這個問題時認為 JavaScript不需要這樣的框架，因為最好選擇你想要的工具並自己建立你需要的解決方案。
這聽起來很棒——如果你是一位經驗豐富的開發者，這也恰好是一個很好的靈活性——但我覺得他並沒有很好地支持這一說法，我來這裡是為了告訴你我認為他錯在哪裡。
在我看來，更好的問題是為什麼我們還沒有適用於 JavaScript 的 Laravel？答案是我們仍在努力。
在他對 JavaScript 世界中可以與 Laravel 或 Rails 相媲美的全端框架的總結中，他沒有考慮到一些重要的點：
-
人們真的想要一個 Laravel/Rails for JavaScript 。如果他們不這樣做，就不會進行如此多的嘗試來建立一個，他也不會製作一個影片，其唯一目的是回應“為什麼 JAVASCRIPT 沒有自己的 Laravel！？ 」
-
他沒有考慮 JS 生態系中底層工具的時機和成熟度。也許並不是說 Laravel for JavaScript不需要存在，只是由於生態系統本身存在一些重大差異，例如它們的歷史有多長以及創新主要發生在哪裡，所以它還不存在。
-
他也沒有詢問這些類型的解決方案適合誰。當然，並非所有開發人員都有相同的目標，因此有些人可能會選擇可組合方法，而有些人則喜歡使用框架。
那麼讓我們看看我們是如何走到今天這一步的，以及我們如何能夠將像 Laravel 或 Rails 這樣的全端框架引入 JavaScript 世界。
完成任務
在他的影片中，Theo 提出了這樣一個觀點：「現在 React 世界裡有一句俗話，那就是『如果你不使用框架，那麼你就在建立一個框架』」。批評，Theo 認為大多數JavaScript 開發人員都沒有抓到重點，建立自己的「自己的框架」實際上是一種優勢。
他認為 JavaScript 生態系統的模組化特性是一個巨大的優勢，但這聽起來對普通開發人員來說承受著很大的壓力，需要做出不必要的判斷呼叫並管理大量樣板程式碼。
當然，您的團隊需要創新並滿足特殊用例的需求。這些是優先考慮模組化的。他們盡可能調整、改進和榨取開發人員體驗 (DX) 和性能，以正確完成他們獨特的工作。
但另一方面，也有許多團隊的主要目標是在他們正在建立的產品方面創造價值和創新，而不是他們用來建立產品的工具。這些開發人員會青睞一個允許他們只專注於業務邏輯的框架。這為他們提供了一種穩定的方式來建立具有最佳實踐的東西，以便他們可以輕鬆地從一個專案推進到另一個專案。在這個陣營中，還有精幹、刻薄的獨立駭客，他們正在尋找框架，以便他們能夠快速行動並將想法推向市場！
這有點像Mac和Linux之間的差別。 Mac 的統一堆疊開箱即用，這意味著許多專業人士因其生產力而喜歡它，而如果您尋求靈活性並有時間和知識來根據自己的需求進行調整，那麼 Linux 是很棒的選擇。兩者都是有效的解決方案，可以共存以滿足不同的需求。
這種對生產力的關注使得 Rails 在當時如此強大，也是 Laravel 目前如此受歡迎的框架的原因。建立這樣一個 JavaScript 框架的多次嘗試足以證明，有很大一部分 JavaScript 開發人員也想要這樣的解決方案。
但也許這樣一個框架還不存在的原因與開發人員是否想要一個框架無關，而是為了使這樣一個框架組合在一起所需的重要因素直到現在才協調一致。為了使這樣的框架廣泛採用，它首先需要足夠穩定的底層技術來建造。之後，它需要時間和許多迭代周期才能達到成熟度，以便開發人員可以放心採用它。
這些因素在 JavaScript 世界中是否一致，為我們提供了 PHP 和 Ruby 已經擁有的框架類型？也許還沒有，但他們似乎正在慢慢走在一起。
比較生態系統
Theo 的要點之一是JavaScript 作為一種語言能夠實現一定程度的模組化和可組合性，而Ruby 和PHP 等語言則無法做到這一點，這就是為什麼Ruby 和PHP 生態系統可以得到全端框架的良好服務，但JavaScript不需要因為你可以自己創作東西。
雖然 JavaScript 是一種特殊的語言，它支援函數式和命令式範式以及動態特性，但它也有很多缺陷（儘管它最近已經有了很大的改進），所以你通常不會聽到它在就像西奧在這裡所做的那樣。事實上，您可能更有可能聽到 Ruby 及其作為模組化和靈活語言特性的讚揚。
因此，如果 JavaScript 作為一種語言的一些獨特屬性使它成為 Web 開發之王，那麼它又是什麼呢？
嗯，答案非常簡單： JavaScript 是瀏覽器的語言。
早在大多數 Web 開發都發生在伺服器端的時候，PHP、Java、Ruby 和其他語言佔據了主導地位。在這個時代，開發人員只會用 JavaScript 寫一小部分功能，因為大部分的工作都是在伺服器端處理。
但隨著Web 開發的發展，我們開始建立更豐富的應用程式，具有更動態、響應更快和即時的功能，許多程式碼從伺服器轉移到客戶端上的JavaScript，因為它（基本上）是唯一可以實現的語言。因此，您不再主要使用 PHP 或 Ruby 進行開發，並在其中撒上一點 JavaScript，而是將應用程式劃分為客戶端上的大量 JavaScript，以及伺服器上的 Ruby 或 PHP。
隨著 NodeJS 的到來以及在伺服器上編寫 JavaScript 的能力，JavaScript 的最後一個權力舉措隨之而來，這鞏固了它作為 Web 開發語言之王的地位。如今，開發人員可以（而且確實）用 JavaScript 編寫整個應用程式。這意味著您需要更少地了解一種語言，同時您也可以在前端和後端之間共用程式碼。這為前端和後端之間更好的整合開闢了一條途徑，它已經像滾雪球一樣進入了我們今天所知的生態系統。
因此，與其說 JavaScript 作為語言的獨特屬性使其成為 Web 開發的主導生態系統，不如說是其作為唯一可用於編寫客戶端程式碼的語言的獨特壟斷地位，而且它還可以用於伺服器 -邊。
正如 Theo 所說，「在 JavaScript 生態系統中，我們有無數的人正在製定出色的解決方案」。這是正確的。正是那些在該領域工作的無數開發人員為 JavaScript 建立了靈活性和模組化解決方案，而不是程式語言的固有品質。
由於 JavaScript 生態系統仍然是最熱門的生態系統，因此它擁有最多的開發人員，同時每天不斷吸引新的開發人員。這意味著我們擁有一個龐大、多元化的社區，主要做兩件事：
-
創新
-
大樓
創新者（和影響者）往往聲音最大，因此輿論很大程度上偏向他們。但也有很多建築或「正常」使用正在發生！只是創新者往往代表建設者說話。
那麼，鑑於 JavaScript 生態系統中正在發生的一切，嘗試為 JavaScript 開發人員建立一個持久的框架是否毫無意義，正如 Theo 所建議的那樣，或者無論創新者如何聲稱，我們是否都在實現這一目標？
顯示您正在使用的內容
Theo 也提到了目前一些 JavaScript 框架的名字，這些框架要么未能成功，要么在成為全面的全端解決方案時「似乎無法做到正確」。
他的觀點確實有道理。到目前為止，像Blitz 、 Redwood 、 Adonis或T3這樣的解決方案還沒有能夠像 Rails 或 Laravel 一樣在其生態系統中普及。
但這些事情需要時間。
看看上面的圖表。 Laravel 和 Rails 已經存在了 13-15 年！相較之下，使用的 JavaScript 框架才剛起步，其中一些框架（例如Wasp和Redwood ）正處於與 Laravel 和 Rails 最初幾年類似的開發階段。
正如您所看到的，好的解決方案需要時間才能成熟。即使其中一些框架開始停滯其最初的巨大增長，也證明對這些工具的需求確實存在！
困擾這些工具的主要問題是 Javascript 作為一個生態系統正在快速發展，因此對於像這樣的解決方案要長期生存，它不僅需要足夠固執己見，而且還需要足夠模組化以跟上生態系統的變化。
阻止框架達到這種狀態的一個因素是與錯誤的技術連結得太緊密。這是 BlitzJS 的 NextJS、Redwood 的 GraphQL 和 MeteorJS 的 Blaze。另一個因素是框架不夠大，因為在JavaScript 生態系統中，這似乎是一項過於艱鉅的任務，在這個生態系統中，事情發展得很快，每個人都“害怕固執己見”，因為他們可能會受到現場最響亮聲音的批評。
換句話說，避免自行發展壯大並真正實現全端的框架（如 Ruby-on-Rails 和 Laravel）就錯過了解決持續困擾 JavaScript 開發人員的最常見痛點的機會。
但是，JavaScript 生態系統正在成熟和穩定，我們正在從以前的嘗試中學習，並且將會出現一個足夠大膽的全端框架，可以一路走下去，做足夠多的事情，並堅持足夠長的時間以確保其地位。
向黃蜂打個招呼
Theo 在比較當今市場上的 JavaScript 框架時，也沒有提到我們目前正在開發的 React 和 NodeJS 全端框架Wasp 。
我們一直在努力讓Wasp成為真正的全端框架，滿足 Web 開發人員的需求，並填補 JavaScript 生態系統的空白，成為他們喜歡使用的框架。
對於 Wasp，我們決定做大、有主見、真正的全端。換句話說，我們將全力支持這個框架。
這意味著從首要原則出發思考並設計一種只有Wasp 使用的新穎方法，例如為我們的配置語言建置我們自己的編譯器，並真正實現全棧，同時保持其足夠的模組化，以便隨著生態系統的發展與生態系統一起發展。
這意味著我們在一開始就花了更多的時間嘗試不同的方法並建立基礎，最終從 2023 年底開始使我們的使用量大幅躍升。
今天看到 Wasp 被用來發布大量新應用程式和業務，甚至被一些大公司和組織內部使用（更多資訊很快就會正式發布），這對我們來說真的很酷！
Wasp 與 JavaScript 世界中其他全端框架的不同之處在於，它將主要抽象層分離到自己的設定檔main.wasp中。這個設定檔為Wasp 提供了處理大量樣板檔案、以基礎設施為中心的程式碼所需的知識，並允許它擁有這個獨特的初始編譯時步驟，在該步驟中，它能夠在生成Web 應用程式之前推理出您的Web 應用程式在後台為其編寫程式碼（在生成它時使用該知識）。
實際上，這意味著您所要做的就是在 Wasp 的設定檔中高層描述您的 Wasp 應用程式，然後使用您熟悉的技術（例如 React、NodeJS 和 Prisma）實現其他所有內容。這也意味著 Wasp 具有很高的模組化潛力，這意味著我們正在建立它來支援未來的其他前端框架，如 Vue、Solid 或 Svelte，甚至支援其他後端語言，如 Python、Go 或 Rust。
如果您是那種希望存在 Rails 或 Laravel for JavaScript 的開發人員，那麼您應該嘗試 Wasp （然後進入我們的 Discord ，讓我們知道您的想法）！
我們要去哪裡？
我們堅信 JavaScript 將會有一個全端框架，就像 PHP 的 Laravel 和 Ruby 的 Ruby-on-Rails 一樣。
目前看來，我們仍在努力實現這一目標。鑑於當前元框架和堆疊（例如 NextJS 和 T3）的流行，我們似乎很快就會實現這一目標。
但這些東西需要時間和耐心。
另外，你必須有足夠的勇氣去嘗試新的東西，因為你知道你的工作會受到生態系統中一些最響亮的聲音的批評。
這就是我們所準備的，也是我們全力支持黃蜂的原因。
到時候那裡見！
原文出處：https://dev.to/wasp/why-we-dont-have-a-laravel-for-javascript-yet-45bi
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式