原文
jsp可以令菜鳥直接寫簡單的網頁程序（網友言），而servlet卻有jsp所不及的集成程度和易維護性。兩者在JAVA/BS系統中無法簡單取代，但同時並存卻令開發者陷入近兩年來最常見的陷阱中：必須在一個即使是相對簡單的項目中維持多套程序模式的方案，顯然，這是高成本的。本文考慮並初步實驗了使用標簽組件連續完成類似servlet的處理效果，從而達到魚和熊掌兼得的目的，看來有一定的效果。
在完全使用servlet的環境中，可以使用servlet的繼承獲得上級servlet的設定屬性；還可以使用servlet-chains達到分類處理的目的，整個WEB程序與實際應用系統非常相似，高效而簡潔；在servlet-jsp的環境中servlet起到集中處理請求的作用，而jsp負責顯示各種形式采摘的數據。後者最麻煩的就是在servlet/jsp中的數徑和變量處理方式不一致，平添大量的原始的工作量。strutsr actionmapping一定程度上解決這個問題，不過解決得不算太徹底。因此在大型的java BS應用中采用servlet/jsp形式所帶來的方便，一定程度上將會被這種變量的不一致性所抵消，畢竟，維持兩種處理方案本身就是高成本的。
因為這個原因，過去本人干脆完全采用servlet形式，而通過另外寫程序解釋由網頁人員編寫的嵌套式的html來達到與JSP類似的目的。這套方案在三四年前是有效的，但在今天由於SUN選擇了JSP作為發展的主體，包括JTL，TAG技術，甚至於jsdk1。5中的cacheResutlSet都是為了這種（我認為是落後的）JSP隨機編碼而開發，因此，獨自堅持走servlet道路是不明智的,(參看本人《選擇JSP作為BS發展方向很可能是致命的戰略失誤》一文)；但是，同樣的疑問並不會因為SUN選擇了JSP而消失：如果完全采用JSP，那麼在數據提交處理上還是必須使用SERVLET以簡化處理邏輯，但同時也必須承受上述的負面作用。
作為SUN贊助支持的JAVA/BS主體項目方案之一的struts框架充分體現了這一矛盾帶來的困惑和折衷：struts- action/actionmapping本身就是為了達到克服上述的JSP不足，希望魚和熊掌兼得，通過ActionServlet令使用者減少 servelt程序的編寫量；不過，在不能完全解決問題的同時，也令開發者為了這不是主體需求的需求，而必須多采用一個框架；一定程度上實際上是得不嘗失。
如果上述邏輯成立，那麼如同幾年前本人完全選擇servlet一樣，既然選擇了jsp作為主體方案，那麼就應該考慮完全拋棄servelt，以便以一套方案處理項目，避免維護兩套系統帶來的附加性成本。但是如同所有人在若干年前指出的一樣，JSP缺乏有效的代碼管理手段；也不便於形成象servlet那樣的基本框架體系，這樣它與簡單的網頁程序如ASP/PHP沒有什麼不一樣。引入javabean(組件，不是簡單的數據對象化載體），可以一定程度上改善這種處境，但javabean缺乏統一的調用規范，卻令這樣的JSP比純粹的servelt開發顯得更為麻煩。
