如今每一個使用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被廣泛接受成為一種web服務器端的首選平台。
但是，通常通過簡單方式即可實現的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=".ContextPath;/index.html"＞Home page＜/a＞
在WebMacro中, ContextPath 作為 template engines使用了其它的語法類型。
再看另 一個例子，假設一個高級的"view"需要設定一個cookie來記錄用戶缺省的顏色配置 -- 這種任務看起來大概只能由view而不是servlet控制器來完成。在JSP中要有這樣的Java代碼：
＜% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %＞
在WebMacro中則沒有Java代碼：
#set .colorscheme = "blue"
作為最後一個離子，假如又要重新找回原來的cookie中的顏色配置。對於JSP，我們可以認為也有一個相應的工具類來提供幫助，因為用getCookies()直接做這樣低層的會變得可笑而且困難。在JSP中：
＜% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %＞
在WebMacro中沒有對工具類的需要，通常是：.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 24 = "The Page Title"
#parse "header.wm"
Your content here
#parse "footer.wm"
這裡對設計者來說沒有要牢記的分號或對title的定義， .wm文件可以放在可自定義的搜索路徑下。
