如今每個使用servlets的開發者都知道JSP，一種由Sun公司發明並花費大量精力加以推行並建構在servlet技術之上的web技術。 JSP將servlet中的html程式碼脫離了出來，因此可以加速web應用開發和頁面維護。實際上，由Sun發布的官方"應用開發模型"文檔上說得更遠： "JSP技術應該被視為標準，而servlets在多數情況下可視為一種補充。" ( Section 1.9, 1999/12 /15聽取意見版)。
本文的目的在於聽取對該申明的合理性的評估-- 透過比較JSP和另一項基於servlets的技術： template engines（模板引擎）。
直接使用Servlets的問題
起初，servlets被發明，整個世界都看到了它的優越。基於servlet的動態網頁可以被快速執行，可以在多個伺服器之間輕易轉移， 並且可以和後台資料庫完美地整合。 Servlets被廣泛接受成為一種網頁伺服器端的首選平台。
但是，通常透過簡單方式即可實現的html程式碼現在卻要讓程式設計師透過out.println()呼叫每一行HTML行，這在實際的servlet應用程式中成為了一個嚴重問題。 HTML內容不得不透過程式碼來實現, 對於大的HTML頁來說不啻是一項繁重費時的工作。另外，負責網頁內容的人員不得不請開發人員來進行所有的更新。為此，人們尋求這一種更好的解決方式。
JSP到！
JSP 0.90出現了。在這種技術中你可以將Java程式碼嵌入到HTML文件，伺服器就會自動為頁面建立servlet。 JSP被認為是一種寫servlet的簡易方式。所有HTML可以直接取得而不必透過out.println()調用，而負責頁面內容的人員可以直接修改HTML而不必冒破壞Java程式碼的風險。
但是，讓頁面美術設計師和開發人員在同一文件上工作並不理想，讓Java嵌入HTML被證明是像將HTML 嵌入Java一樣令人尷尬。讀取一堆很亂的程式碼仍然是一件困難的事情。
於是，人們在使用jsp方面變得成熟，並且更多地使用了JavaBeans。 Beans包含了jsp所需的商業邏緝代碼。 JSP中的大多數程式碼都可以取出放到bean中去，而只留下極少的標記用來呼叫bean。
最近，人們開始認為這種方式下的JSP頁面真的很像是視圖（view）。它們成為一個用於顯示客戶端請求的結果的元件。於是人們會想，為什麼不直接對view發送請求呢？ 目標view如果對該請求不合適又將如何？ 說到底，很多的請求有多種可能來取得結果view視圖。例如，同一請求可能產生成功的頁面，資料庫例外出錯報告，或是缺少參數的出錯報告。同一請求可能產生一個英文頁面也可能是西班牙文頁面，這取決於客戶端的locale。為什麼客戶端必須直接將請求發送給view?為什麼客戶端不應該將請求發送給一些通用的伺服器元件並讓伺服器來決定JSP view的返回?
這使很多人接受了已被稱為"Model 2"的設計, 這是在JSP 0.92中定義的基於model-view-controller的模型。在這種設計中，請求被發送到一個servlet控制器，它執行了商業邏緝並產生一個相近的資料"model"來用於顯示。這資料接著透過內部送到一個JSP "view"來進行顯示，這樣看起來JSP頁就像是一個普通的嵌入的JavaBean。 可以根據負責控制的servlet的內部邏輯來選擇適當的JSP頁面進行顯示。這樣，JSP檔案就成為了一個漂亮的template view。這就是另一種發展，並被另外一些開發者所推崇至今.
進入Template Engines
使用template engine來代替通常目的的JSP, 接下去的設計將變得簡單，語法更簡單，出錯信息更易讀，工具也更用戶化。 有些公司已經做了這樣的引擎，最著名的可能是WebMacro ( http://webmacro.org , from Semiotek)，他們的引擎是免費的。
開發者應該明了，選定一個template engine來取代JSP提供了這麼一些技術優勢，這也正是jsp的一些不足之處：
問題#1: Java程式碼太模板化了
雖然被認為是不好的設計， JSP仍試圖將Java程式碼加入web頁面。這有些像是Java曾經做的，也就是對C++的簡化修改，template engines也透過將jsp中的較低層的源碼移去來使之簡化。 Template engines實行了更好的設計。
問題#2: 要求Java程式碼
在JSP頁中要求寫一些Java程式碼。例如，假設某頁要決定目前web應用程式中根的上下文從而導向其主頁，
在JSP中最好使用以下Java程式碼：
＜a href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞
你可以試著避免Java程式碼，而使用＜jsp:getProperty＞ 標記但這將給你六個難以閱讀的字串：
＜a href="＜jsp:getProperty name="request"
property="contextPath"/＞/index.html"＞HomePage＜/a＞
使用template engine則沒有Java代碼和難看的語法。這裡是同樣要求下在WebMacro中的寫法：
＜a href="$Request.ContextPath ;/index.html"＞Home page＜/a＞
在WebMacro中, ContextPath 作為$Request變數的一個屬性，使用類似Perl的語法。其它er template engines使用了其它的語法類型。
再來看另一個例子，假設一個高階的"view"需要設定一個cookie來記錄使用者缺省的顏色配置-- 這種任務看起來大概只能由view而不是servlet控制器來完成。在JSP中要有這樣的Java程式碼：
＜% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %＞
在WebMacro中則沒有Java程式碼：
#set $Cookie.colorscheme = "blue"
作為最後一個離子，要重新找回原來的cookie中的顏色配置。對於JSP，我們可以認為也有一個相應的工具類別來提供幫助，因為用getCookies()直接做這樣低層的會變得可笑而且困難。在JSP中：
＜% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %＞
在WebMacro中沒有對工具類別的需要，通常是：$Cookie.colorscheme.Value ．對寫jsp的圖形藝術師，又是哪一種文法比較容易學習呢？
JSP 1.1 引入了自訂標記（custom tags）允許任意的和HTML相似的標記在JSP頁面中在後台執行Java程式碼，這將具有一定的價值，但前提是要有一個廣泛知曉的，全功能的，可以免費得到的，標準化的標記庫。目前還沒有出現這樣的標記庫。
問題#3: 簡單工作仍然很累人
即使是很簡單的工作，例如包含header和footer，在JSP中仍然很困難。 假設有一個"header"和一個"footer"模板要包含到所有頁面，而每個模板要在content中包含當前的頁標題。
在JSP中最佳方法是：
＜% String title = "The Page Title"; %＞
＜%@ include file="/header.jsp" %＞
....你的頁面內容...
＜%@ include file="/footer.jsp" %＞
頁面設計者要記住不能遺漏第一行的分號並要將title定義為一個字串。此外， /header.jsp和/footer.jsp必須在根目錄下且必須是可存取的完整檔案。
在WebMacro包含headers和footers做起來比較簡單：
#set $title = "The Page Title"
#parse "header.wm"
Your content here
#parse "footer.wm"
這裡對設計者來說沒有要牢記的分號或對title的定義， .wm檔案可以放在可自訂的搜尋路徑下。
問題#4: 很粗的循環
在JSP中循環很困難。這裡是用JSP重複印出每一個ISP物件名字。
＜%
Enumeration e = list.elements();
while (e.hasMoreElements()) {
out.print("The next name is ");
out.println(((ISP)e.nextElement()).getName());
out.print("＜br＞");
}
%＞
也許什麼時候會有使用者自訂標記來做這些循環。對"if"也是如此。 JSP頁可能看起來成了很古怪的java程式碼。而同時，webmacro循環很漂亮：
#foreach $isp in $isps {
The next name is $isp.Name ＜br＞
}
如果必要的話，#foreach指令可被自訂的#foreach-backwards指令很容易地取代。
用jsp的話很可能變成這樣：（這裡有一個可能的＜foreach＞標記）
＜foreach item="isp" list="isps"＞
The next name is ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
＜/foreach＞
設計者當然地回選擇前者。
問題#5: 無用的出錯訊息
JSP常有一些令人驚訝的出錯訊息。這是因為頁面先被轉換成servlet然後才進行編譯。好的JSP 工具可以相對增加找到出錯位置的可能性，但即使是最好的工具也無法讓所有出錯資訊都能輕鬆被讀取。由於轉換的過程，一些錯誤對工具來說可能根本不可能被識別。
例如，假設JSP頁面需要建立一個對所有頁面通用的標題。以下程式碼並沒有錯：
＜% static String title = "Global title"; %＞
但Tomcat會提供以下出錯資訊：
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.
static int count = 0;
^
此資訊認為以上腳本被放入_jspService()方法而靜態變數不允許放入方法中。該語法應該是＜%! %＞。頁面設計者很難讀懂這些出錯訊息。即使最好的平台在這方面也做得很不夠。即使所有Java程式碼都從頁面中移出也無法解決問題。另外，以下表達式有什麼錯？
＜% count %＞
tomcat給出：
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Class count not found in
type declaration.
count
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Invalid declaration.
out.write("rn");
^
換句話說，只是遺失了一個標記而已。應該是＜%= count %＞。
由於template engine可以在template檔案中直接產生而沒有任何戲劇性的向程式碼轉化，所以可以非常容易地給出適當的出錯報告。 依序類推，當c語言的命令被打入Unix shell的命令行， 你並不希望shell 會產生一個C程式來運行這個命令，而只是需要shell簡單地解釋命令並加以執行，如有錯誤也直接給出。
問題#6: 需要一個編譯器
JSP需要一個置放在webserver中的編譯器。由於Sun拒絕放棄包含了他們的javac編譯器的tools.jar函式庫， 這其中就變得有問題了。 Web伺服器可以包含進一個第三方的編譯器如ibm的jikes。但這樣的編譯器並不能在所有平台上順利工作(用C++寫成的) 也不利於建立純Java 的web伺服器。 JSP有一個預編譯選項可以起到一定作用，儘管並不完美。
問題#7: 空間的浪費
JSP消耗了額外的記憶體和硬碟空間。對伺服器上每30K的JSP文件，必須要有相應的大於30K的類別文件產生。實際上使得硬碟空間加倍。考慮到JSP文件隨時可以輕易地透過＜%@ include＞包含一個大的資料文件，這樣的關注有著很現實的意義。同時，每一個JSP的類別檔案資料必須載入到伺服器的記憶體中，這意味著伺服器的記憶體必須永遠將整個JSP文檔樹保存下去。少數一些JVM有能力將類別檔案資料從記憶體中移去；但是，程式設計師通常無法控制這樣的規則來重新申明，而且對大的網站來說重新申明可能不是很有效。對template engines由於沒有產生第二個文件，所以節省了空間。 Template engines也為程式設計師提供對templates在記憶體中進行快取的完全控制。
使用template engine也有一些問題：
Template的問題#1: 沒有嚴格定義
template engine該如何運作並沒有嚴格定義。可是，但相對jsp來說，其實這並不很重要，和JSP不同的是，template engines對web伺服器沒有任何特殊要求-- 任何支援servlet的伺服器都可以支援template engines (包括API 2.0伺服器如Apache/ JServ，它們並不能完全支持JSP)! 如果為最好的template engine設計提供健康的競爭本可以引起一場耀眼的革新，特別是有開放源碼的促進，（可以讓思想相互推動和促進），那麼今天的WebMacro就會像Perl一樣，沒有嚴格定義但公開原始碼組織的推動就是它的標準。
Template的問題#2: 沒有獲得公認
Template engines並未被廣泛知曉。 JSP已經佔據了極大的商業市場，並且深入人心。而使用g template engines只能是一種未被了解的替代技術。
Template的問題#3: 尚未調配好
Template engines還沒被高度地調配好。沒有對template engine 和JSP兩者進行效能測試和比較。理論上說一個調配完好的template engine實現應該和一個調配好的JSP相匹配；但是，考慮到第三方為jsp已經作出了這麼深遠的推動，結果只有jsp被很好地調配好了。
JSP的角色
當然地，JSP在將來必然會有其地位。即使從名稱上也可以看出JSP和ASP的相似性，它們只有一個字母的差異。所以如果要讓使用asp的人們轉向java,非常相似的jsp環境將對此起到很大的推動作用，和asp保持這種對應關係所能起到的作用應該也是被推出jsp的設計者重點考慮到的。
然而這裡想要強調的一點是：有利於轉入新環境的工作者，以及實際上是否是使用該環境的最佳方式，這兩者是有很大不同的。
JSP日益顯示出它正成為最重要的java技術之一， 它讓人們離開ASP的世界-- 由此，Sun將支持這一強有力的商業case, Java相關技術支持者也將給予更大力的支持。
可是，這並非java平台的最佳解決方案。這將使java解決方案變得好像是沒有java的解決方案了。