為什么這樣說呢？原因有兩個：維護和開發速度。服務器端腳本語言其實就像是開發Internet的熔爐。在一個服務器頁面上，你可以很方便地混合各種不同的腳本方法和對象。這種頁面簡直就是建筑Web的混凝土。正是這種“材料”的混合給予了服務器端腳本強大的信息處理能力。它可以讓服務器端程序設計人員開發出動態的、靈活的Web頁面。但是，另一方面，腳本的自由混合卻很難得到維護，特別是隨著項目規模的不斷增長而顯得尤其嚴重。我們將不得不讓有經驗的程序員來建立和維護最終產品，結果讓這些程序員成為了一般的Web設計人員。服務器端應用程序在最終的圖形設計和實現這兩方面上就弱化了。更糟糕的是，因為這些頁面對代碼而言變得很復雜，開發速度也就相應降低了。最后，許多中等規模或者大型的服務器端Web應用程序很晚才得以推出而且成本也無法控制。此外，在實現了這些應用程序之后，許多銷售商還必須去尋找合格的程序員來維護這種亂得如同一盆意大利面條似的代碼。

我們誰都不愿意看到這樣的結果，所以，為了克服這個問題，ASP引進了COM對象技術，而JSP則提供了J2EE作為對策。這些解決方案都是建立在集中的、可重用代碼庫的機制之上。但是，他們使用起來可就太難了，耗費的時間也很多。還有，這些解決方案并沒有減少建立混亂代碼的誘惑，結果，我們只能組織起大型的、內部結構良好的開發團隊來使用這些技術。這就意味著，盡管我們目前都已經有了建立大型項目的以上方法，中等規模的項目卻沒有被這些技術所光顧。

可現實是，中等規模的項目才是Web應用程序中的主體部分。所以，許多項目不得不面對其開發和維護環境不能滿足其需要的局面。

幸好，JSP為我們提供了解決這一問題的最佳方案，標簽庫（Tag libraries）提供了建立可重用代碼塊的簡單方式。但是和COM和J2EE不同的是，你不需要掌握任何額外的技能就可以建立標簽庫：如果你會編寫JSP頁面，你就會建立標簽庫。最后，標簽庫還改進了Web應用程序的維護性。這種對維護性的改進表現在：輕易地在JSP頁面上就實現了基于XML的可定制接口。結果可想而知，Web設計人員可以建立JSP Web應用程序而無需知道JSP是怎么回事。這樣一來，Web開發就成為一項非常富有效率的團隊開發任務了。JSP程序員可以建立定制的標簽和后端代碼模塊，而Web設計人員則可以使用定制標簽并且全力關注于Web設計本身。標簽庫解決了代碼混亂的問題，而且做得干凈漂亮（事實上，XML才是解決這些問題的本質所在，但是標簽庫還是起到了相當關鍵的作用）。

<!-- end of storybody -->