【2025年】JSP(Java Server Pages)が令和時代のWebサービス開発に向いていない話

はじめに

この記事は継続的にQiitaでいいねいただくのでメンテナンスします
元祖はこちら

お断り

この記事はJSPが最早Webサービスの現場にフィット¹しない部分が多いという、実務の話です。JSP自体のアーキテクチャを否定する意向がないことを踏まえてお読みください。
この記事ではJenkins自体も否定はしていません。個人的には安定性や互換性もしっかりしており評価はできますが、Webサービス開発ではGitHub ActionなどのCI/CDツールが使いやすいと考えています。

JSPの代替案の説明をしていますが、モダンフロントエンド開発の詳細には触れません。
Webセキュリティに関わる部分は実装依存で発生することもあるので触れません。
サーバレスは作者が利用していないので触れませんが、JSPは使えない、はず。
キャッシュとCDNの話も割愛します。²

この話で想定している現場の状況

• WebサービスをJavaエンジニアとUI/UXデザイナーで作っています
• バックエンドはJava 8以上で、フレームワークはSpringです
• 開発時期の問題で、管理画面と一般ユーザ向けフロントのUIは全般的にJSPです
• フロントエンドのコーディングはデザイナーがします。デザイナーは仮説検証や他社との協業を多数こなすため、エンジニアとは開発ライフサイクルが独立しており、UIの開発とデプロイをエンジニアに依存せず行う必要があります
• デザイナーはサーバサイドのテンプレートエンジンとモダンフロントエンド技術に詳しいです。CSSはモジュール化して管理する習慣があり、プログラミングもできます
• JavaのアプリケーションサーバはTomcatで、デプロイはエンジニアもデザイナーもJenkinsでデプロイできるようにしてあります
• ソースコードはGitHubで管理され、Pull Requestベースで開発しています³
• エンジニア、デザイナーともに新卒入社も多く、JSPやJavaに詳しい人はエンジニア以外あまりいません
• JavaエンジニアもモダンOSSやJavaの仕様にはあまり詳しくないです

不便な理由

taglibの仕様書の場所がわかりにくい

• 今使っているのがJakarta EEなのかJava EEなのか
• 今利用しているアプリケーションサーバは何

etc踏まえてエンジニアが公式ドキュメントを探すところから必要かもしれません。英語で技術文書が読める方にはSpecへのリンクを紹介しても良いかもしれませんが、エンジニアでさえも公式ドキュメント探しが大変かもしれません。

コーディング方法と規約の整備が必要

デザイナーさんにJSPのコーディング方法を説明するため、最終的にはtaglibの使い方をWikiなどに独自にまとめておく必要がありました。

カスタムtaglibの仕様書がわかりにくい

よく使うコンポーネントをカスタムtaglibとして実装し、デザイナーさんがエンジニアに依存せず自力でコーディングできるようにすることがあります。その場合、デザイナーさん達と仕様書を共有するのにjavadocだと不便です。

• データ呼び出しに必要なパラメータは何？型は？
• 画面表示に使えるパラメータは何？
• コーディング後の画面表示はどうなるの？

といった関心がJavaエンジニア以外に伝えにくいからです。javadocでMarkdownを使えなくはないですが、結局はJavaエンジニア以外にtaglib仕様の共有はとにかく不便です。

コーディングした結果を確認するまでに時間がかかる

JSPにコーディング後、デザインを確認するためにはアプリケーションサーバの起動やソースコードのデプロイが必要です。
組み込みTomcatであればmainメソッドを呼び出せば起動でき手間は少ないかもしれません。
一方、組み込みではないTomcatを利用している場合起動までの手順は煩雑で、エディタにも制約が出てきます。

メンバーの習熟が課題

ローカル開発環境でeclipse WTPを使うことになり、エディタがPleiades All in One Eclipse一択になるかもしれません。2023年の新卒はeclipseを知らないこともあります。本質でない教育と開発環境構築の手順化がコストです。環境のセットアップまでに時間がかかります。

ゲーム業界経験者でなければJenkinsを知らないこともあり、新しく参加したメンバーには、そもそもJenkinsは何か、から説明をはじめてJenkinsデプロイを教えることにもなりかねません。

SEOアンフレンドリーなHTMLになりがち

実装次第ですが、JSPのコーディングで可読性を考慮すると、階層が崩れたSEOアンフレンドリーなHTMLになりがちです。

社内の管理画面などSEOの考慮が不要な場合は問題ありませんが、SEOが大事なサービスでは一大事です。

モジュール化されたJavaScriptが使いにくい

JSファイルは、フッタ下部に書くか、ヘッダに書くか悩みがちです。
scriptタグの記載順の問題でエラーが発生した場合、どの部分で発生しているかトラブルシューティングも手間です。

CSS管理が静的ファイル一本になりがち

サーバのresourceディレクトリにCSSファイルを配置し、JSP内ではHTMLで参照しがちです。

	<link rel="stylesheet" type="text/css" th:href="@{/css/example.css}" href="../../../css/example.css"/>

慣れないメンバーにはCSSの配置先がわかりにくく、リンク切れしないためにhttps:// からフルパス指定して本番でリンク切れを起こしたりしがちです。

CSSやJavaScriptがモジュール化しにくい

Sassのインストールが煩雑ですし、モジュールかも

デプロイが遅くなりがち＋デプロイ時短のためインフラが限定されがち

誤字脱字を修正したいなど、JSPだけを即座にデプロイしたい場合があります。この場合にwarをビルドしてデプロイし、アプリケーションの再起動をかけるとダウンタイムも一瞬発生しますし、デプロイ時間もかかります。
そこでrsyncしてJSPだけコピーし再起動を不要にする運用を取ることがあるのですが、コンテナが使いにくくどうしてもインフラがVMに限られがちです。

テストフレームワークが使いにくい

JSPのテストはアプリケーションサーバを起動し、マニュアルで動作確認するのみになりがちです。JSPのユニットテストはしなくなります。一時期JSPのテストフレームワークのようなものがあった記憶もありますが、浸透しないので忘れました。

ではどうするか

JSPではなくフロントエンドフレームワークを使いましょう

お好みでどうぞ。Reactもいろいろ話題になっています

1. TypeScriptで型がつけられます
2. JavaScriptはモジュール化されています
3. eslintやprettierなどが整備されており、CI/CDに組み込んで規約を理解し守れます
4. 仕様書はStorybookで管理すると、コンポーネントの仕様、画面表示の状態の確認やテストもできます
5. CSS管理にTailwindやstyled-componentsなど選択肢があります
6. SSRすればSEOも対策しやすいですし、SEO対策のためインデントに悩むことはありません
7. テストフレームワークがあります
8. ローカル開発環境にeclipseが不要です
9. 動作環境をVM以外から選択できます
10. CI/CDの選択肢が広がります
11. デプロイにJenkinsは不要です
12. インフラもVMに限らず利用できます
13. rsyncは不要です

どうしてもJavaの技術スタックを使いたい場合

Thymeleaf

サポートが下火なのでよく考えましょう

他にもテンプレートエンジンがある

お好みでどうぞ。
最近htmxをよく見かけます。

Vaadinというものもある

https://vaadin.com/docs/latest
https://github.com/vaadin/platform/releases

2025/12時点でももリリースされています。

脆弱性とサポートを意識すればまだ使えるかもしれません。

1. リスペクト元はjfluteさんの現場フィット https://jflute.hatenadiary.jp/entry/20161214/genbafitlayer ↩

2. 正直、考慮するとデプロイとCDNとキャッシングの話が手間 ↩

3. GitLabなど他サービスでも可能 ↩