為什麼node出現之後，各種前端構建工具和手段才如雨後春筍般層出不窮？
在java web的時代，為什麼就沒有人寫這些工具？
最簡單的比如合併多個js文件，壓縮混淆。用maven插件一樣可以實現啊。為什麼以前要麼是前端寫靜態html，後端套模板。要麼是前端自己寫模板。感覺node出來之後，有了grunt/gulp，大家都腦洞大開啊，出來好多耳目一新的東西。---以前都多個html 用後端模板 在伺服器合併的現在是構建的時候就合併，部署的時候已經是一個了在以前 一樣能實現這點是沒人想到嗎。。
可看我去年的演講：前端構建的過去、現在和未來 [錄像 1:29開始（但1:36之前沒有錄到聲音）]
簡言之，在node出現以前也有類似的工具——我演講的「過去」部分里列了許多有名的工具，但是它們都有共同的缺點：前端工具缺乏統一平台。而node的出現解決了這個問題，加上一些其他因素，使得我們迎來了前端構建工具的爆發。
前端項目的構建工具在node(還有rhino)出現之前是不足的，主要原因是跑在普通瀏覽器里的JS運行時跳不出瀏覽器這個沙盒，無法直接操作文件，而這是構建工具必須具備的底層功能。那時候JS不是一種系統編程語言，web開發社區沒有足夠的動力去用一種非JS的系統編程語言去開發各類構建工具。Node讓JS跳出了瀏覽器的沙盒，可以進行系統調用，把它變成了一種系統編程語言，這樣web開發人員就有動力去用同樣的語言去實現各種工具了，因為這種語言他們已經很熟悉。另一個不能忽略的影響是Ruby社區，特別是ROR以及Rake構建工具的啟發。
前端：幫我寫個腳本，把 js 文件合併成一個文件
後端：沒空。你自己用 bash 寫一個吧，遍歷然後 cat 一下就行了，用 makefile 也行啊前端心想，媽的聽不懂，我只會 JS。Node.js 一出，前端終於可以用 JS 合併文件了。
看出來了嗎？一部分前端除了 JS 啥都不會，不用 Node.js 用啥？（少部分前端早就用 PHP、ruby、Java 做工程化了）
工程化需求一直存在，只是 Node.js 之前前端寫不出工具而已。
JS 所謂的工程化，在初期基本就是拼字元串、算個MD5、lint 一下，後來有了 AST 分析，直到 TypeScript 出來，才像那麼回事。所以說還是微軟的工程師牛逼。
這些工程化，跟Java、C++的工程化比起來，弱爆了好嗎？別整得好像很高大上似的，工程化是軟體工程的必備項好嗎？
以前沒條件寫，現在有條件了就補上。別老玩概念。
你覺得為什麼 gruntfule gulpfile 要叫做 xxxfile，明顯就是從 makefile 抄過來的好嗎，當然 makefile 抄誰我就不知道了，我水平太差。
你覺得為什麼後來前端又說工程化應該用 npm scripts 作為啟動腳本。因為終於搞清楚命令行的工作原理了。
你說現在的前端為什麼言必稱函數式？幾年前的面向對象怎麼不提了？還不是因為終於多看了兩本書了，知道面向對象只是面向對象而已，不是聖經。函數式才是聖經嘛。
你覺得前端新技術出現得那麼快是為什麼？因為舊的沒寫好就發布了，用一用發現還是不好用，得再寫一個新的唄。
再者說，那些前端東西真的「新」嗎？不就是抄 WPF、coffeescript、Python、C# 和 Rails 嗎？當然抄並沒有什麼錯，現在新出來的語言都是集大家之所長，但是你因此覺得「壯哉我JS」那就是你中二了。
前端預編譯之風居然是從 Ruby 社區刮起來的，知道前端社區有多弱了嗎？Node.js 半邊天 TJ 也是從 Ruby 社區過來的，知道前端有多尷尬了嗎？人家一個人抵得上整個前端社區，科科，前端好意思嗎？TJ 在前端瀟洒了一圈覺得高處不勝寒跑去跟 golang 社區交流，前端社區依然沒有發現自己的窘境。
還有去年前年炒的同構JS。想得很美，做起來知道不容易了嗎？
外國的前端社區我不是很熟我可能說錯了，但是國內的前端社區我可熟了。大家比著造輪子打知名度，今天這個會議明天那個會議，一片繁華。
但我作為一個前端從業者咋這麼心虛呢？我們國內前端社區有那麼成果嗎？需要開這麼多會來歌頌？
後端語言的社區為什麼說前端浮躁啊，你說呢？還有比前端社區更浮躁的社區嗎？
這麼多年了，前端的組件化才搞出點眉目，好意思說工程化？哪個語言像 JS 一樣搞個組件化這麼難的？（可能有，但是不要在意這些細節，重要的是氣勢）。為什麼難？很大因素就是 JS 沒設計好。但是沒設計好你就等設計好了再用好嘛，非要整 commonJS、AMD，還來了個 CMD，搞得最終不得不搞一個 UMD。而且明明知道是臨時方案，還把自己整得跟標準似的。最後還是得搬標準出來救命。怎麼前端還是沒從二十年前的瀏覽器大戰中吸取教訓似的？幸好有 es modules啊，沒有 es modules的話我真的不好意思承認 JS 是現代語言。
有人肯定會說我們不搞這些事，標準怎麼會引入 es modules 呢，這些都是必要的。我並不否定這些東西作為臨時方案的意義，但是你們該消停了好嗎？能把一個東西玩好了再去玩下一個嗎？別見一個愛一個。那不叫博愛，那叫沒見識。
不是現在的前端太難，而是以前的前端太沒技術含量。
你一定發現我跑題了，我也發現了，但是一跑就剎不住了。
利益相關：我是一名前端程序員。
本科學的是軟體工程。
因為會ruby的前端太少，大部分只會js
我覺得其他答案都沒答到點子上，故怒答一波。其實真實原因是前端在這幾年裡發展迅猛，積累了大量人才和項目，而js又先天各種設計缺陷，工具鏈更不完善。所以有了node 這個通用輪子一出來，可以用輪子造輪子，甚至可以跨平台造輪子，所以大量人才一下找到突破口，各使神通，各種造輪子，才出現目前百花齊放，前端工具大爆發的場面。簡而言之，長期前端項目的快速增長和js的先天缺陷，以及node一個恰好的時機出現填補了空白，這幾原因導致今天的局面。
在每一個時代，程序都是為了：
完成業務需求。完成業務需求。完成業務需求。
以前一樣，現在一樣，未來也還是一樣。
以前的業務需求就是完成web功能，不需要你做多花哨的頁面，我這麼說，以前專職的前端是比較少的，少到什麼程度？以前很大一部分程序員都是「全棧工程師」就是說，後端的人員，順手就把前端的代碼寫了，那會兒對前端的顯示效果並不注重。
然後越往後，大家開始注重前端炫酷的顯示效果，然後越來越多的專職前端出現了，為了實現更多炫酷和精彩的前端，也為了更加方便高效的顯示更多炫酷和精彩的前端頁面，越來越多的前端框架如雨後春筍般出來咯。
所以，不是說在node出來之後，前端構建工具才出來。這兩者根本沒有必然聯繫。
只是隨著技術的發展，更好更優秀的工具會被發掘出來，僅此而已。
前端構建工具的功能主要是將DSL或者syntax sugar轉換為瀏覽器能夠識別的css/ES5/html。
我從開發成本、AST轉換和語言類型的角度來回答題主的問題。
Node.js開發的成本是大大低於Java的。
1、開發難度上: 用動態語言JS開發的難度低於靜態語言Java。
2、安裝上: npm i -g即可全局安裝命令，package.json提供bin欄位即可適配命令行開發。
3、流程上: JS跑在V8上，由Node來bootstrap; java代碼則需要手動指定jar包。
Node更擅長做前端AST的IO，靜態語言不擅長轉換動態語言
對於開發者來說，構建工具的IO只是一個簡單的函數：輸出 = IO(輸入)。
使用構建工具的目的之一就是轉換AST，將syntax降級為瀏覽器能夠識別的語言。
在Node裡面做AST相對更簡單，因為整個過程是用JS來處理JS。
前端層面的tokenizer從handleBars到angular，從babel到acorn,已經有很好的技術生態。
讓Java來處理前端語言的話，需要添加Java的presenter轉換，JS=&>Java =&>JS。將動態語言轉換為靜態語言，這顯然不合適，所以Java並不適合做前端的構建工具。
Node和前端的技術生態更容易打通，做到ismorphic。
前端的一份代碼如果去除BOM和DOM,很容易遷移到Node。從這個角度看，用Node來開發構建工具，收益當然更大。
靜態語言不擅長轉換動態語言
Node由於內置V8來處理JS，所以AST的轉換層面在JS，具體代碼執行在V8。
如果用Java來處理這個事情，則存在靜態語言和動態語言兼容性上的huge gap，不僅容易出錯，開發成本也很大。
綜上所述，Node比Java更適合做前端的構建工具。
題外話，AST在語言間的transform已經提上日程。比如webAssembly就是AST的集大成者，V8也將在下一個版本原生支持webAssembly，做到write once，run any platform。
我認為並不是node出現了，才導致了前端構建工具的爆發。
而是前端專業化了。
一個比較好的例子，extjs。
這貨出來的時候我可能還在玩泥巴，但是他們已經推出了一個js文檔生成工具——jsduck。
python寫的，與node一毛錢關係都沒有。
再說句難聽點的話：90%的前端都沒有寫工具的能力，目前前端的工具大都是這10%中的人寫出來的，而且可以保證的是，這10%的人絕對不是僅會js。
隨著前端越來越專業化，大小公司都出現了專業的前端團隊，為了推動生產力，必然會有人去寫這些工具，這是一個需求推動的過程，與語言無關。
難道C/C++、Python、Ruby就不能寫構建工具了？
開玩笑，幾年前我剛開始搞前端的時候，什麼資源壓縮合併什麼工程化都是探索再三的。
那時候我懂點最好的編程語言，本地起個wamp就這麼跑http服務（真是浪費資源。。。）。
那時候網速慢，我們很注重資源壓縮，寫了個zip.php專門用來合併靜態資源，大概長這樣：
&
&