言語とランタイムの世代交代 — 公式EOL告知で読む11のプロジェクト

はじめに — この層は日付が明確です
1. Python 2
2. AngularJS
3. Vue 2
4. Nashorn
5. Javaアプレットとウェブスタート
6. Mono
7. Xamarin
8. PhoneGap
9. Atom
10. io.js — 分かれて再び合流した例
11. jQuery Mobile
まとめ — 残したものが最も大きい層
あわせて読みたい
シリーズ

はじめに — この層は日付が明確です

言語とフレームワークは終了日が公式文書に明記される場合が多くあります。インフラやツールと違って状態の確認が容易だということであり、それゆえ知らなかったという言い訳が通らない層でもあります。

以下の11個はいずれも公式告知かリポジトリの状態で根拠を確認しました。項目ごとにそのプロジェクトが何を残したのかを書いています。この層では残したものが特に大きく、コードがまるごと別プロジェクトの土台になった事例がいくつもあります。

1. Python 2

何だったのか — 20年近くPythonの既定であったバージョン系列です。
なぜ当時は正しかったのか — ユニコード処理など3と互換しない決定はありましたが、その上に膨大なエコシステムが実際に動いていました。
何が変わったのか — 公式の案内が、2020年1月1日以降は新しいバグ報告も修正も変更も行われず、サポートが終了したと述べています。以後に見つかるセキュリティ脆弱性も処理されません。
何がその場所に来たのか — Python 3です。
何を残したのか — 大規模な言語移行にどれだけ時間がかかるかという業界全体の学習です。以後、言語設計者が互換性の破壊を扱う姿勢は目に見えて慎重になりました。
いまでも使うのが正しい場合 — ありません。隔離された環境で動くレガシーなら時間は稼げますが、ネットワークに露出しているなら危険資産です。

2. AngularJS

何だったのか — 双方向バインディングでフロントエンド開発のやり方を変えた第一世代のAngularです。
なぜ当時は正しかったのか — DOMを直接操作せずデータと画面を結ぶという発想は、当時のフロントエンドの生産性を実際に変えました。
何が変わったのか — 2022年1月11日の告知によれば、長期サポートは2021年12月31日に終了しました。リポジトリは2024年4月12日にアーカイブされ、READMEも2022年1月のサポート終了を明記しています。
何がその場所に来たのか — Angularです。告知も後継フレームワークへのアップグレードを勧めています。
何を残したのか — 宣言的なデータバインディングと依存性注入をフロントエンドに持ち込んだことです。今日ほぼすべてのフレームワークがこの二つを備えています。
いまでも使うのが正しい場合 — ありません。ただし大規模移行が難しい組織向けの商用延長サポートは存在します。

3. Vue 2

何だったのか — 段階的な導入が可能なフロントエンドフレームワークの第二世代です。
なぜ当時は正しかったのか — 既存ページにスクリプト一行で載せられる性質は、実際の移行現場で大きな利点でした。
何が変わったのか — Evan Youが2023年12月15日の告知で2023年12月31日の終了を知らせました。以後は新機能も更新も修正も提供されないが既存の配布チャネルでは引き続き入手でき、最後のリリースは2.7.16だと述べています。
何がその場所に来たのか — Vue 3です。
何を残したのか — 段階的採用という設計原則と、オプションベースのコンポーネントAPIを後続バージョンでも維持するという互換方針です。
いまでも使うのが正しい場合 — 同じ告知が、すぐに移行できない組織向けの商用延長サポートを案内しています。それ以外は移行対象です。

4. Nashorn

何だったのか — JDKに内蔵されていたJavaScriptエンジンです。
なぜ当時は正しかったのか — JVM上でスクリプティングを使いたいという需要は実在し、Nashornは当時のECMAScript標準を忠実に実装していました。
何が変わったのか — OracleのJDK 17移行文書によれば、NashornエンジンとAPI、jjsツールがJDK 15で削除されました。Java 11で削除予定の非推奨と表示された後の手順です。
何がその場所に来たのか — GraalVMのJavaScript実装と、別途配布される独立エンジンです。
何を残したのか — 標準のスクリプティングAPI自体はそのまま残りました。インターフェースは維持し実装だけ差し替えられるよう設計されていたおかげです。
いまでも使うのが正しい場合 — 最新のJDKでは選択肢になりません。旧JDKに固定されたシステムならそのまま動きます。

5. Javaアプレットとウェブスタート

何だったのか — ブラウザの中でJavaアプリケーションを実行する配布方式です。
なぜ当時は正しかったのか — インストールなしでデスクトップ級のアプリケーションを配布するという目標は時代を先取りしていました。今日のウェブアプリケーションと目標は同じです。
何が変わったのか — 同じOracleの文書によれば、JavaプラグインとApplet Viewer、ウェブスタートとjavawsツールがJDK 11で削除され、Applet APIはJDK 17で削除予定として非推奨になりました。文書は、すべてのブラウザベンダーがJavaブラウザプラグインのサポートをなくしたか、なくす予定を表明したためだと述べています。
何がその場所に来たのか — ウェブ標準ベースのアプリケーションと、計算集約的な作業にはWebAssemblyです。
何を残したのか — ブラウザで重いアプリケーションを動かすという目標そのものです。実行主体がプラグインから標準ランタイムに変わっただけです。
いまでも使うのが正しい場合 — ありません。実行するブラウザが残っていません。

6. Mono

何だったのか — LinuxやmacOSなどで動作した最初の.NET実装です。
なぜ当時は正しかったのか — .NETがWindows専用だった頃、クロスプラットフォーム実行を可能にした唯一の選択肢でした。
何が変わったのか — Mono公式サイトによれば、最後のメジャーリリースは2019年7月、最後のパッチリリースは2024年2月で、WineHQ組織が上流プロジェクトの管理主体を引き継ぎました。同じ案内は、活発な利用者とMonoベースのフレームワーク管理者に.NETへの移行を勧めています。
何がその場所に来たのか — クロスプラットフォームに対応した現代の.NETです。
何を残したのか — コード自体の相当部分が現代の.NETランタイムに吸収され、WineHQでも別系統として続いています。場所を譲りながら二系統で生き残った稀な事例です。
いまでも使うのが正しい場合 — 公式の案内は移行を勧めています。ただしWineHQ系統は維持されているので、その用途なら状態を直接確認する価値があります。

7. Xamarin

何だったのか — .NETでiOSとAndroidのアプリを作るフレームワークです。
なぜ当時は正しかったのか — ネイティブAPIにそのままアクセスしながらロジックを共有する手法は、クロスプラットフォームツールの中でも妥協が少ないほうでした。
何が変わったのか — Microsoftのサポートポリシー文書が、2024年5月1日にすべてのXamarin SDKのサポートが終了したと述べています。
何がその場所に来たのか — 同じ文書がXamarin.Formsは.NET MAUIへ、それ以外は.NETに統合されたAndroid・iOS・Mac向けSDKへ移るよう案内しています。
何を残したのか — コード自体が後続製品の土台になりました。名前が変わったほうに近い事例です。
いまでも使うのが正しい場合 — ありません。新しいプラットフォームAPIを受け取れません。

8. PhoneGap

何だったのか — ウェブ技術でモバイルアプリを作るハイブリッドアプリフレームワークです。
なぜ当時は正しかったのか — ウェブ開発者がアプリストアにアプリを出せるようにした最初の大衆的な経路でした。
何が変わったのか — Apache Cordovaが2020年8月14日の告知で、AdobeがPhoneGapの終了を発表したことを伝えつつ、Cordovaはいまも活発に維持されていると述べました。
何がその場所に来たのか — 上流のオープンソースプロジェクトであるApache Cordovaがそのまま残り、後の世代のハイブリッドフレームワークがその上や隣に位置づきました。
何を残したのか — Cordovaそのものです。商用ディストリビューションが閉じても、寄贈された上流プロジェクトは残るという構造を示した事例です。
いまでも使うのが正しい場合 — PhoneGapブランドの製品ではありません。Cordovaは別物で、告知の基準では維持されています。

9. Atom

何だったのか — GitHubが作ったハック可能なテキストエディタです。
なぜ当時は正しかったのか — ウェブ技術でデスクトップエディタを作るという実験が実際に通用することを証明しました。
何が変わったのか — GitHubが2022年6月8日の告知で、2022年12月15日にリポジトリをアーカイブすると述べました。数年にわたり意味のある機能開発がなかったことを理由に挙げています。
何がその場所に来たのか — 同じ記事が言及するVisual Studio Codeとクラウド開発環境です。
何を残したのか — 最も大きい事例です。Atomを作るために生まれたElectronは今日多数のデスクトップアプリの土台であり、同じ告知もAtomが数千のアプリへの道を開いたと記しています。パーサー技術もほかのツールの中で使われ続けています。
いまでも使うのが正しい場合 — ありません。ただしコミュニティのフォークが存在するので状態は自分で確認できます。

10. io.js — 分かれて再び合流した例

何だったのか — リリース速度とガバナンスへの意見の相違から分岐したNode.jsのフォークです。
なぜ当時は正しかったのか — フォークは対立を解決する正当な手段です。結果としてこのフォークが生んだ圧力が本体を変えました。
何が変わったのか — Node.js v4.0.0のリリース告知が2015年9月8日付で、二つのプロジェクトの成果が一つのコードベースに統合されたと述べています。同じ記事は44名の協力者と15名の技術運営委員会という体制も併せて紹介しています。
何がその場所に来たのか — Node.js本体です。フォークは原点に戻りました。
何を残したのか — 開かれたガバナンスと予測可能なリリース日程です。今日のNode.jsの運営方式はこの時期に形づくられました。これは場所を譲ったのではなく、目的を達して解消した事例です。
いまでも使うのが正しい場合 — 該当なし。そもそも別途存在しません。

11. jQuery Mobile

何だったのか — モバイルウェブのUIコンポーネントフレームワークです。
なぜ当時は正しかったのか — レスポンシブCSSとタッチイベントの標準が定着する前は、端末ごとの差を吸収する層が必要でした。
何が変わったのか — jQueryチームが2021年10月7日の告知で廃止を発表しました。告知は2010年の登場以降モバイル開発の技術が変わったこと、広範な手動テストの負担を理由に挙げています。公式サイトももはやサポートされていないと明記しています。
何がその場所に来たのか — CSSのメディアクエリとフレックスボックス、そしてブラウザに標準化されたタッチイベントです。この場合の代替は特定のライブラリではなくプラットフォームです。
何を残したのか — モバイルウェブUIがどの問題を解くべきかを一覧として整理したことです。その多くがのちにウェブ標準へ入りました。
いまでも使うのが正しい場合 — ありません。標準が同じ仕事をより上手にこなします。

まとめ — 残したものが最も大きい層

この一覧で目を引くのはコードがまるごと生き残った割合です。AtomはElectronを残し、Monoは現代の.NETとWineHQの両方へ続き、Xamarinは名前を変えて後続製品になり、PhoneGapは上流プロジェクトのCordovaを残しました。io.jsはそもそも原点へ戻りました。

プロジェクトの名前が消えることと、そのプロジェクトが作ったものが消えることはまったく別の出来事です。名前は商標と組織に結び付いており、コードとアイデアはそうではありません。

そして実務上重要な点が一つ。この層は終了日が公開文書に明記されるので、いま使っている言語とフレームワークのサポート終了日を一覧で管理するだけでも相当のリスクを取り除けます。

状態情報は2026-08-12に直接確認しました。プロジェクトは再び活発になることもあるので、最新の状態はご自身で確認してください。