JSP 是 Java 大分支、Web 方向小分支中一种基于 Servlet 的模板式页面输出技术；早期，Web 服务器对应的客户端一般只是浏览器，而用户则是真正的肉人，JSP 早期根本目的是把服务器端数据套在模板中生成 HTML 输出给浏览器、由浏览器排版成类似图表的界面，直接给肉人看。
下文的“JSP 页”指用 JSP 技术编写的、常规以 .jsp 为后缀名的、看起来由 Java 代码和 HTML 混合而成的服务器端模板文件。
根据浏览器请求的查询范围不同、或者服务器本身的数据的变化，同样的 JSP 页每次输出的 HTML 界面上展示的数据都有可能不同，根据查询状况动态变化的。
在某个蛮荒年代，这种动态生成 HTML 界面的特性被滥用了，大量不太合格的编码人员、被进度催逼的编码人员、或者更早期摸索前行的前辈把本地文件读写、数据库读写、网络接口通讯、业务流程控制等和界面显示无直接关系的重量级复杂操作也写在 JSP 页中；在这个情况下还要求网页美观好看，还要有弹框、动画等发生在浏览器端、由 JavaScript 控制的特效，导致美工人员、JavaScript 编程人员和 JSP 编程人员需要共同参与；Java 代码、JavaScript 代码和 HTML 混乱交织的情况导致开发进展缓慢、人员矛盾激化等问题。
后来有人推出了 el 表达式和 jstl 等技术，试图用类似 HTML 的标签取代 Java 代码，以从视觉上取悦美工人员；但但些技术不能包办一切、或者包办一切时过于繁琐，有时仍然需要出动 Java 代码，导致同一个 JSP 页上同时出现 HTML 、JavaScript 、Java 、el 和 jstl 等多种语法和作用范围各不相同的语言混合交织；不说增加了维护和开发难度，但至少没有从根本上降低维护和开发难度。
真正解决这种矛盾的是 MVC 概念，落实到 Java Web 上，一次典型的请求过程如下：
1 . 浏览器的请求发给一个控制器程序 (C/Controller) ；大多数情况下控制器由 Servlet 充当，懒狗作死的情况下可能用 JSP + 自定义 Java 程序充当；大多数情况下控制器只管干活，不管对浏览器的输出。
2 . 控制器固定地调用一组 Java 程序、或者根据某种配置按请求的不同而动态地调用不同的 Java 程序，根据用户请求做文件读写、数据库读写、网络接口通讯、数据组合加工等一系列处理，产生结果；在不进一步细分的情况下，这些被调用的程序可以笼统地被看作内部服务层 (S/Service) 。
3 . 控制器固定地、或者按用户请求、或者根据处理结果中的某些要素跳转到某单个 JSP 页、或者嵌套的 JSP 页组合，这个、或者这些 JSP 页拿到处理结果，直接将数据套在模板中生成 HTML ，或者做一些轻量级的判断和循环、将特定的数据合理地套在模板的特定部位、生成合理的 HTML ；在这种体系中，JSP 不再做重量级操最，一切工作只围绕生成 HTML 界面进行，所以归为视图层 (V/View) 。
时代在发展，网页要呈现的内容越来越复杂，页面本身的数据量也越来越大，但有时用户的某个操作真正需要变更的只是页面上某个很小的区域、很少的内容，每次请求都都由服务器生成完整的 HTML 界面变得越来越没必要，对于只需要更新页面上特定区域的请求，JSP 也可以只生成 XML 或 JSON 内容，由浏览器在更早的请求中加载的 JavaScript 解析和对页面做变更；而一些新场景下，客户端和用户也不再是浏览器和肉人，而是上游业务系统，它们只需要服务器返回 XML 或 JSON 数据，完全不需要 HTML 和基于 HTML 的用户界面。
进一步发展之下，在针对浏览器和肉人的场合已经有了比 JSP 更好的模板技术和框架，也有了更新的 MVVM 概念；在不需要用户界面的场合，也有了用控制器或服务层直接输出 XML 和 JSON 的技术；JSP 的用武之地已经被大大压缩了，目前大概就剩这三个用途了：
1 . 在不想为了一点点事情大费周章地搞前后端彻底分离、搞大前端、也无须华丽界面的旧风格小规模站点上作为视图层把控制器或服务层生成的结果数据变成 HTML 、XML 和 JSON 内容，响应给客户端。
2 . 作为报错页为前序处理过程遗漏的异常或错误兜底。
3 . 懒狗作死不想在 web.xml 里配 Servlet 时直接用 JSP 把控制器拉起来。
基于剩下的这点用途，基本上只要知道堆“<%……%>”就行了，学习成本很低，能搞定控制器和服务层的人学 JSP 基本上也是“分分钟”的事；至于 el 、jstl ，都没必要再花时间去学了，毕竟都已经用 JSP 了，也就不指望现代前端人员和美工人员会加入这个任务了。