最近，Twitter 上發生了 JS 開發者與 Laravel 和 Rails 開發者之間的熱烈討論。它始於 Laravel 的作者 Taylor Otwell 的一條長推文：
https://twitter.com/taylorotwell/status/1791468060903096422
簡而言之，他認為整個 JavaScript 生態系統缺乏像 Laravel 或 Rails 這樣真正的「全端」框架，而這些框架可以讓單一開發人員建立下一個 GitHub、AirBnb 或 Shopify。
我對此深表同情，因為我在建立ZenStack （Prisma ORM 之上的打字稿工具包）時有著相同的目標。事實上，我常在社區裡聽到這樣的話：
沒有人可以否認 JS 生態系統的受歡迎程度和快速增長，即使在非會員中也是如此。那麼這是為什麼呢？
歷史原因
人們創造自己的歷史，但他們並不是隨心所欲地創造歷史；他們不是在自我選擇的環境下成功的，而是在已經存在的、給定的、從過去傳承下來的環境下成功的——卡爾·馬克思
PHP 和 Ruby 從一開始就被設計為伺服器端語言。 PHP 於 1994 年建立，用於建立動態網頁，而 Ruby 於 20 世紀 90 年代中期出現，是為通用程式設計而設計的。
鑑於它們的伺服器端起源，PHP 和 Ruby 自然適合綜合框架，可以處理 Web 開發的各個方面，從路由和控制器到資料庫互動和模板引擎。這導致了 Laravel 和 Rails 等框架的建立，以提供完整的、固定的方式來建立 Web 應用程式。
相較之下，JavaScript 是作為網頁瀏覽器的客戶端腳本語言而誕生的。直到 2009 年 Node.js 推出之前，它與後端無關。如果您聽說過 Netscape Navigator 和 Internet Explorer 之間的“瀏覽器戰爭”，您可能會意識到前端中持續存在的混亂，這種混亂今天繼續以瀏覽器兼容性的名義讓前端開發人員瘋狂。因此，早期的網路是將不同的技術拼湊在一起。因此，JavaScript 開發人員開始習慣模組化，允許靈活地混合和匹配庫和工具以求生存。這就是為什麼與 Node.js 一起出現的 NPM 以驚人的速度成長，迅速成為世界上最大的軟體註冊中心。
這種不同的情況導致了不同的開發人員文化：
PHP/Ruby 開發人員： “給我一個可以正常工作的框架。我想要約定、穩定性和清晰的交付路徑。”
JS 開發人員： “不要限制我！我想要靈活性、最新的工具以及以我的方式建置的自由，即使這意味著需要更多的前期工作。”
因此，即使擴展到後端世界之後，單一的、「一刀切」的方法也很難在 Javascript 生態系統中行得通。
當代努力
一方面，這種文化導致不斷的演變，使整個生態系統保持興奮和創新。然而，這也會導致新人更決策疲勞和更陡峭的學習曲線。
“哪裡有泥土，哪裡就有黃銅。”有些人踏上了冒險之旅，建造一個類似 Rails 的、包含電池的框架來挑戰現狀。以下是一些流行的例子：
Full-stack JavaScript framework that integrates React, GraphQL, and Prisma. It simplifies development with a unified setup and automatic code generation, perfect for scalable applications.
Blitz.js extends Next.js into a full-stack framework featuring a zero-API data layer and Prisma for database access. It aims to simplify development by allowing direct server-side code calls from the frontend.
AdonisJS is a TypeScript-first web framework for building web apps and API servers. It offers a rich set of features out-of-the-box, including an ORM, authentication, and a powerful CLI, making it ideal for developers seeking a comprehensive and structured development environment.
他們會成為 JS 世界的 Laravel 或 Rails 嗎？現在說可能還為時過早，但至少 RedwoodJS 顯示出巨大的勢頭：
另一群人正試圖透過提供固定電池的工具包的「啟動套件」來解決這個問題。其中，最受歡迎的是Create-T3-App ，它結合了 Next.js、tRPC、Tailwind CSS 和其他強大的工具，為您建立類型安全的 Web 應用程式奠定了堅實的基礎。
有趣的是，T3 的建立者 Theo 似乎對 JavaScript 世界的整個努力持悲觀態度：
https://twitter.com/t3dotgg/status/1792136001345003748
樂觀的未來
任何可以用 JavaScript 編寫的應用程式最終都會用 JavaScript 編寫。 — 傑夫·阿特伍德
雖然我並不完全相信阿特伍德定律，但我確實預見到 JavaScript 在 Web 開發領域的光明前景。原因很簡單：
這是歷史上第一次可以使用程式語言開發整個網頁應用程式。
這是一個顯著的好處，特別是對於新手開發人員來說。感謝 TypeScript 優秀的類型推斷系統，我們不僅有能力這麼做，而且也願意這麼做。
Laravel 或 Rails 使用者常見的批評是，這些框架缺乏對系統中不同實體之間的關係進行建模的傳統方法，如下所示：
https://twitter.com/chantastic/status/1791531154212033004
雖然它可能還沒有達到 Laravel 或 Rails 的水平，但目前 JS 界的努力已經認識到了這個問題。如果您查看上述解決方案的工具包，您會發現一個通用名稱： Prisma
如果您還沒有聽說過 Prisma，它是一種現代的 TypeScript-first ORM，可讓您輕鬆管理資料庫模式，以極大的靈活性進行查詢和變更，並確保出色的類型安全性。這使 JavaScript 開發人員能夠實現 Laravel 和 Rails 中傳統的資料處理複雜性和輕鬆的關係建模，就像 Laravel 的 Eloquent ORM 一樣。
我在 Prisma 之上建立的ZenStack工具包旨在進一步縮小差距。它在架構之上加入了授權層，然後自動為您產生 API 和前端掛鉤。因此，簡單地說，一旦您完成了架構，您就幾乎完成了後端。然後，您可以選擇任何前端框架（例如 React、Vue 或 Svelte）來完成您的 UI。
開始就要考慮如何結束
JavaScript 會迎來 Laravel/Rails 時刻嗎？就我個人而言，我相信，或至少希望，標準化約定可以帶來整個生態系統的全局最佳化。然而，考慮到 JavaScript 的歷史和文化，實現這一目標可能需要大量時間。目前還不清楚人工智慧是否會加速這一過程，或徹底顛覆它。
所以，看來我們只能拭目以待了。然而，我們不要在這場辯論中迷失方向，忘記我們的初衷，正如李羅賓遜所說：
https://twitter.com/leeerob/status/1792215708715122752
所以，我在最後引用W3C Web平台設計原則中的一句話：
使用者需求先於網頁作者的需求，網頁作者的需求先於使用者代理實現者的需求，後者先於規範編寫者的需求，後者先於理論純粹性。
原文出處：https://dev.to/zenstack/php-laravel-ruby-rails-javascript-36dc
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式