JavaScript的服務器端開發比Java更好嗎？它可能只取決於正在開發的應用程序。我現在可以聽到來自Java開發人員的發聲。
從Java開發人員的角度來看，使用Spring Boot生態系統和JavaScript與Express進行Web開發的簡單比較。
本文的目標
這是一個不太技術性的比較（您可以在其他地方找到更具體的技術比較）。我只想概述當您是一名Java開發人員時，如何在Node.js中開發Web應用程序。
所以請記住，這篇文章充滿了個人意見。
在開始之前，我概述了一些前提：
- 我是一名使用Java語言的軟件開發人員。我已經開發了基於Java的軟件大約15年了。
- 我目前正在學習JavaScript開發（自2007年以來我一直在編寫前端JavaScript，但服務器端JavaScript已成為它自己的野獸）。
我想要比較什麼
我想強調一下開發基於Node / Express堆棧的應用程序與基於Spring Boot的應用程序相比時所感受到的一些差異。
為什麼我要比較這些
TL; DR：在完成一個簽約項目之後，我決定測試另一個生態系統來檢查它是否可以避免一些Java最受批評的點。
我最後一個客戶是一家正在創建加密交換的公司（是的，在當今市場上很常見，但對於一家意大利公司來說並不常見）。他們讓我加入他們的團隊（三個不同的開發團隊）並幫助他們建立自己的平臺。我主要開發用於授權和身份驗證的微服務，核心事務處理，以及客戶的KYC微服務和不同微服務之間共享的代碼庫等其他東西。
這是一個大而有趣的項目。
但在與其他團隊和人員的討論中，我經常聽到對基於Java的Web開發的批評，轉而支持Python或Go。其他語言似乎沒有遭受Java的一些批評是：
- Java很冗長。
- Java中的一切都是界面混亂的。
- Java應用程序的內存消耗是壓倒性的。
- 磁盤空間消耗也可能是壓倒性的。
- 發展需要很多時間。
在編寫數百個基於Docker的微服務時應該考慮使用3.和4.我認為這個規模問題可能是無稽之談，因為如果你有數百個微服務運行，你的組織可能是相當有利可圖的，你可以買得起“昂貴” “實例支持內存貪婪的Java應用程序。
我必須誠實，有時我認為，在2019年，上述所有五點都是合理的批評，所以我想嘗試自籌資金項目來測試其他一些技術。
由於我需要進行Web開發而不一定是基於微服務的項目，在快速（非常快速地）看GO之後，我決定反對這種語言。我認為它是一種很棒的語言（從我讀到的內容）但它不適合我當前的項目。
所以我看了Python並開始使用Python，但我需要編寫一些JavaScript代碼，因為我將使用Puppeteer作為PricePaladin（一種價格跟蹤和監控工具）的基本組件， 並在審查了非常好的 語言比較之後 我決定使用Node.js.
對照
語言
如果您是Java開發人員，您會發現JavaScript並不難學。當你處理回調時，你肯定會凍結。你會發現Promises，並且在一天結束時，你將使用async-await語法糖，使一切恢復正常。
也就是說，JavaScript聽起來有點奇怪，但今天的JavaScript絕對沒問題（正如我之前所說，它不是2015年的JavaScript）。它簡單，功能強大且簡潔。
我留下關於動態打字的所有觀察結果，在我看來，這並不是什麼大不了的事。
Node.js是單線程的
好的，對於Java開發人員來說，這是最“令人震驚”的事情之一。但片刻之後震驚消失了。您應該考慮一切都在一個線程上運行（在任何Java Web應用程序上，您有多個線程），並且回調函數（異步函數）在執行它們時排隊並執行，但所有代碼都在單個線程上運行（Node.js的速度和低內存消耗的關鍵）。從Java開發人員的角度來看，這意味著：
- 不要運行CPU時間密集型代碼，否則在執行新的排隊功能之前，所有內容都將等待CPU空閒。
- 如果出現問題並且Node.js崩潰，那麼 一切都會 崩潰：在Web應用程序服務多個併發請求的情況下，所有請求都會崩潰。您沒有Java Web應用程序的隔離。
JS相當於Spring Boot Ecosystem：Express.js，Passport.js，Sequelize
如果我們僅限於與MVC Web應用程序部分的比較，Spring Boot絕對是非常棒的：輕巧，快速，完整且極其可配置。從這個角度來看，與Express.js提供的相比，Java開發人員並沒有任何重大缺陷。
Express.js也提供相同的潛力。根據個人品味，可以更好地理解或不是路由：不是在Java註釋級別定義，而是在路由文件級別定義。
更一般地說，Spring Boot表示將代碼組織到包（模型，服務，控制器）中的非常精確的方法，而在Express.js上下文中則沒有這樣的指導。儘管如此，可以重新應用類似的代碼結構，並且通常有一些項目的代碼結構與Spring Boot項目類似。
對於身份驗證部分，Spring Security是“終極工具”......但如果用於某些特別複雜的情況，它也是“馴服的野獸”。JavaScript對應的是Passport.js，它非常強大，但結構和成熟度較低。然而，您感覺它能夠處理與Spring Security相同的情況和條件。在任何情況下，該框架也廣泛支持開發通用認證機制，例如JWT認證或其他常見的auth機制。Spring Security的成熟度尚未與Passport.js相匹配，但我認為Spring Security提供的80％的功能也是在Passport.js中實現的，有時候更簡單。
從我的觀點來看，Java中的ORM一直是Java應用程序的致命弱點。Java標準大致是Hibernate（儘管有各種各樣的選擇，無論多麼廣泛，如Jooq和MyBatis），而對於與關係數據庫相關的JS世界，最受歡迎的庫是Sequelize。
Hibernate與Sequelize
TL; DR：Hibernate仍然是最完整，最成熟，最通用的解決方案，但成本非常高！Sequelize可能會覆蓋90％的用例。
我不討厭Hibernate，但我肯定不喜歡它。它過於設計，緩慢而複雜。它就像一頭大象。但是，它可以對任何受支持的數據庫執行任何操作。相反，Sequelize小而簡單但無法管理所有用例。
我通過使用Sequelize發現的一些事情：
- 你會有一個不那麼難，但絕對不是那麼容易的時間嘗試使用蛇案件的桌子的領域。您可以逐個手動指定它們（但這太過分了），或者您可以使用一些黑客將名稱轉換為蛇案例。這是一個簡單的解決方案，但它的缺點在於它會破壞遷移命令行工具。無論如何，用於引入命名約定定義的靈活性的所有請求都被丟棄並被忽略是不可接受的。
- 它不完全支持複合鍵。正如這裡明確指出的那樣 ，“雖然可以在Sequelize中創建複合主鍵，但Sequelize當前不支持複合外鍵，因此無法引用具有複合主鍵的模型/表。”從我的角度來看，這是不成熟的。
- 由於時區解釋，你必須做一些很好的技巧來管理日期字段（這真是出乎意料）。
- 將實例添加到兩個實體（例如Book和Author）之間相關的字段時，會立即保存實體。這並不是什麼大不了的事，但表明Sequelize遠不如Hibernate複雜，後者有內部機制來決定何時刷新數據。
在Sequelize中也有一些我喜歡的東西，比如在運行時創建查詢的容易性（這是輕而易舉的，你可以在運行時編寫一個JSON對象並將其傳遞給查詢引擎）。嘗試在創建JPQL查詢時執行此操作，或者考慮使用某些條件進行復雜化的過程。老實說，在嘗試通過某些字段在運行時動態過濾查詢時使用Hibernate和Spring Data JPA是一件很痛苦的事情，而在Sequelize中這很容易（應該用任何框架/語言）。
Sequelize在Hibernate方面閃耀的另一個方面是，當你遇到一些困難的情況並且需要進行本機查詢時：它們都允許你執行本機查詢，但老實說，將結果轉換為模型更簡單Sequelize比Spring Data JPA / Hibernate。
而且我不是在談論啟動時間：介紹Hibernate會增加啟動時間，而Sequelize則非常直接。
作為最後的考慮，很明顯：
- Sequelize比Hibernate成熟得多，
- Hibernate能夠做任何事情，而Sequelize僅覆蓋90％的用例。
- Sequelize不那麼抽象，而且更容易使用。
- 這可能是一個很大的優勢，特別是當您擁有數據庫模式，不必適應遺留數據庫，並且您不打算有一天遷移數據庫引擎時（說實話，我只看到一個案例）數據庫遷移在我的生活中，當兩家銀行決定合併時，因此決定只保留一個IT系統並將廢棄的代碼重寫到另一個平臺。有數千個存儲過程需要重寫，所以代碼可移植性，在我看來，在談論ORM時，是一個無用的功能。）
最後的考慮因素
我目前正在使用描述的JavaScript堆棧，目前我對它非常滿意。 PricePaladin（一種價格跟蹤和監控工具） 是使用上面提到的堆棧構建的，由於其內存佔用少，目前已部署到廉價的服務器上。
使用JavaScript可以為您帶來更高級的簡單性。它是腳本和標準Web開發的理想選擇，但我不會將它用於複雜項目（小型專用和隔離的微服務除外），也不會將它用於數字應用程序或數字計數的應用程序（如Java和Java的加密交換）它的 BigDecimal類非常適合該範圍）。
最終，我在開發服務器端JavaScript時的一般感覺是，與基於Java的等效應用程序相比，一切都更簡單，更簡單，儘管我強烈認為缺乏穩定性和成熟度。用Java提供的庫（只有當特定項目需要某些庫時才缺乏實際，否則沒有區別）。
另一種看法是JavaScript開發週期快了約20％。通過這種方式，我的意思是，由於更復雜的代碼和過度設計的Java應用程序結構遵循經典指南和重建代碼所花費的時間，因此您在Java中開發相同功能的時間比在JavaScript中花費的時間多得多。
因此，在應用程序不提供計算或阻塞處理的情況下，並且關注經典的小型Web應用程序的開發，我幾乎肯定會選擇使用所描述的JavaScript堆棧進行開發，而在其他情況下，我會將應用程序基於從長遠來看，我認為Spring Boot堆棧提供了更強的可維護性。
閱讀更多 愛碼農 的文章
