The Generational Shift in Languages and Runtimes — Eleven Projects Read Through Their Official EOL Notices

• Introduction — in this layer the dates are explicit
• 1. Python 2
• 2. AngularJS
• 3. Vue 2
• 4. Nashorn
• 5. Java applets and Web Start
• 6. Mono
• 7. Xamarin
• 8. PhoneGap
• 9. Atom
• 10. io.js — the case that forked and merged back
• 11. jQuery Mobile
• Conclusion — the layer where the inheritance is largest
• Related reading
• Series

Introduction — in this layer the dates are explicit

Languages and frameworks usually state their end dates in official documentation. That makes checking status easy, which also makes this the layer where "we did not know" is not an excuse.

All eleven below were verified against official notices or repository state. Every entry records what the project left behind, and in this layer that inheritance is unusually large: in several cases the code itself became the foundation of another project.

1. Python 2

• What it was — the version line that was the default for Python for nearly twenty years.
• Why it was right at the time — there were decisions incompatible with 3, such as Unicode handling, but a vast ecosystem genuinely ran on top of them.
• What changed — the official notice states that as of 1 January 2020 no new bug reports, fixes or changes will be made and that Python 2 is no longer supported. Security vulnerabilities discovered afterwards are not addressed either.
• What took its place — Python 3.
• What it left behind — an industry-wide education in how long a large language transition takes. Language designers have handled compatibility breaks noticeably more carefully since.
• When it is still right — never. Legacy running in an isolated environment buys time, but anything network-exposed is a liability.

2. AngularJS

• What it was — the first-generation Angular, which changed frontend development through two-way binding.
• Why it was right at the time — binding data to the view instead of manipulating the DOM directly genuinely changed frontend productivity.
• What changed — per the notice of 11 January 2022, long-term support ended on 31 December 2021. The repository was archived on 12 April 2024 and its README also states that support ended in January 2022.
• What took its place — Angular. The notice recommends upgrading to the successor framework.
• What it left behind — bringing declarative data binding and dependency injection into the frontend. Nearly every framework today has both concepts.
• When it is still right — never, although commercial extended support exists for organisations that cannot migrate at scale.

3. Vue 2

• What it was — the second generation of a frontend framework designed for incremental adoption.
• Why it was right at the time — being droppable into an existing page with a single script tag was a major advantage in real migration work.
• What changed — Evan You announced end of life for 31 December 2023 in a notice on 15 December 2023. It states that no new features, updates or fixes will follow but that it stays available on existing distribution channels, and names 2.7.16 as the final release.
• What took its place — Vue 3.
• What it left behind — the design principle of incremental adoption, and a compatibility policy that keeps the options-based component API in later versions.
• When it is still right — the same notice points to commercial extended support for organisations that cannot migrate immediately. Otherwise it is a migration target.

4. Nashorn

• What it was — the JavaScript engine built into the JDK.
• Why it was right at the time — the demand for scripting on the JVM was real, and Nashorn faithfully implemented the ECMAScript standard of its day.
• What changed — per Oracle's JDK 17 migration document, the Nashorn engine, its APIs and the jjs tool were removed in JDK 15, following their marking as deprecated for removal in Java 11.
• What took its place — the JavaScript implementation in GraalVM, and separately distributed standalone engines.
• What it left behind — the standard scripting API itself remains, because it was designed so the interface stays while implementations are swapped.
• When it is still right — it is not an option on modern JDKs. Systems pinned to older JDKs continue to work.

5. Java applets and Web Start

• What it was — a deployment mechanism for running Java applications inside the browser.
• Why it was right at the time — the goal of delivering desktop-class applications without installation was ahead of its era. It is the same goal web applications serve today.
• What changed — the same Oracle document states that the Java plug-in, Applet Viewer, Web Start and the javaws tool were removed in JDK 11, and that the Applet API was deprecated for removal in JDK 17. It gives the reason as all browser vendors having removed, or announced plans to remove, support for Java browser plug-ins.
• What took its place — applications built on web standards, and WebAssembly for compute-heavy work.
• What it left behind — the goal of running heavy applications in the browser. Only the execution vehicle changed, from plug-in to standard runtime.
• When it is still right — never. There is no browser left to run it.

6. Mono

• What it was — the first .NET implementation to run on Linux, macOS and elsewhere.
• Why it was right at the time — when .NET was Windows-only, it was the sole option for cross-platform execution.
• What changed — per the official Mono site, the last major release was July 2019 and the final patch release February 2024, and the WineHQ organisation has taken over as stewards of the upstream project. The same notice recommends that active users and maintainers of Mono-based frameworks migrate to .NET.
• What took its place — modern, cross-platform .NET.
• What it left behind — much of the code itself was absorbed into the modern .NET runtime, and a separate lineage continues at WineHQ. It is a rare case of surviving along two branches while giving up its place.
• When it is still right — the official guidance recommends migrating. Since the WineHQ lineage is maintained, it is worth checking that state directly for those use cases.

7. Xamarin

• What it was — a framework for building iOS and Android apps with .NET.
• Why it was right at the time — sharing logic while retaining direct access to native APIs involved less compromise than most cross-platform tooling.
• What changed — Microsoft's support policy document states that support for all Xamarin SDKs ended on 1 May 2024.
• What took its place — the same document directs Xamarin.Forms projects to .NET MAUI and the rest to the Android, iOS and Mac SDKs integrated into .NET.
• What it left behind — the code itself became the foundation of the successor product. This is closer to a rename.
• When it is still right — never. You cannot receive new platform APIs.

8. PhoneGap

• What it was — the hybrid app framework for building mobile apps with web technology.
• Why it was right at the time — it was the first mainstream route for a web developer to publish to an app store.
• What changed — Apache Cordova reported in an announcement on 14 August 2020 that Adobe had announced PhoneGap was shutting down, while stating that Cordova is still active and maintained.
• What took its place — the upstream open source project, Apache Cordova, remained, and later generations of hybrid frameworks settled on or beside it.
• What it left behind — Cordova itself. It demonstrates the structure whereby a donated upstream project survives even when the commercial distribution closes.
• When it is still right — not the PhoneGap-branded product. Cordova is separate and, per the announcement, maintained.

9. Atom

• What it was — the hackable text editor built by GitHub.
• Why it was right at the time — it proved that building a desktop editor with web technology actually works.
• What changed — GitHub announced on 8 June 2022 that it would archive the repositories on 15 December 2022, citing the absence of significant feature development for several years.
• What took its place — as the same post notes, Visual Studio Code and cloud development environments.
• What it left behind — the most of any entry here. Electron, created in order to build Atom, is the foundation of countless desktop apps today, and the same notice records that Atom paved the way for thousands of applications. Its parser technology likewise continues to be used inside other tools.
• When it is still right — never, though community forks exist whose state you can check yourself.

10. io.js — the case that forked and merged back

• What it was — a Node.js fork that split off over disagreements about release cadence and governance.
• Why it was right at the time — forking is a legitimate way to resolve conflict. In the end the pressure this fork created changed the original.
• What changed — the Node.js v4.0.0 release announcement, dated 8 September 2015, states that the work of both projects is now combined in a single codebase. The same post introduces a structure of 44 collaborators and a 15-member technical steering committee.
• What took its place — Node.js itself. The fork returned to the original.
• What it left behind — open governance and a predictable release schedule. The way Node.js operates today was formed in this period. This is not a case of giving up a place but of achieving a purpose and dissolving.
• When it is still right — not applicable; it does not exist separately.

11. jQuery Mobile

• What it was — a mobile web UI component framework.
• Why it was right at the time — before responsive CSS and touch event standards settled, a layer that absorbed device differences was necessary.
• What changed — the jQuery team announced deprecation in a notice on 7 October 2021. It cites how much mobile development technology has changed since the 2010 launch, and the burden of extensive manual testing. The official site likewise states that it is no longer supported.
• What took its place — CSS media queries and flexbox, and touch events standardised in the browser. Here the replacement is not a particular library but the platform.
• What it left behind — a catalogue of the problems mobile web UI has to solve. A good share of that catalogue went into web standards afterwards.
• When it is still right — never. The standards do the same job better.

Conclusion — the layer where the inheritance is largest

What stands out on this list is the proportion of code that survived intact. Atom left Electron; Mono continues both in modern .NET and at WineHQ; Xamarin changed its name into a successor product; PhoneGap left the upstream project Cordova. io.js went back to the original entirely.

A project name disappearing and what that project built disappearing are entirely different events. Names are tied to trademarks and organisations; code and ideas are not.

And one practical point. Because end dates in this layer are published in official documentation, simply keeping a list of the support end dates for the languages and frameworks you use removes a substantial amount of risk.

Status information was verified directly on 2026-08-12. Projects sometimes become active again, so check the current state yourself.

Related reading

• The reality of the Airflow 2 EOL migration
• PostgreSQL version upgrade strategies
• Working with legacy code
• Dependency supply chain security
• Tools: Git Playground · SW Maintenance Checklist

Series

1. Build and frontend tooling
2. Infrastructure and containers
3. Data stores and queues
4. Languages, frameworks and runtimes (this post)
5. What replaces technology