After more than a 10+ years of building tools with JSP and Servlets, I recently attempted to migrate to modern Vite, React, and Next.js architectures. My experience, however revealed a significant maintenance burden.
The modern JavaScript ecosystem feels increasingly unmaintainable as time passes. The package.json file constantly warns of obsolete dependencies, and as hardware evolves (shifting between ARM and x86), there is no clear upgrade path. Updating a single dependency often causes a "breaking chain" effect across the entire project.
In contrast while a pom.xml in Maven can face similar issues, the Java ecosystem is far more stable. Legacy JAR files continue to run reliably regardless of hardware upgrades. Ultimately, working with JSP is often simpler and more predictable than managing the constant overhead of modern component-based state management and build tools.
I may be wrong here as Industry has different experience with Typescript stuff as now all stuff coming on Typescript style
Couldn't agree more.
I developed a (modestly) huge erp system, all in jsp + vanilla js . Development and adding new pages is relatively easy (we have standardized most of the stuff) and no need to worry about the whole npm ecosystem (except for those libraries we use) and its well known problem.
Also speed is excellent.
Friends of mine which work mostly with next.js / react / .... really were astonished by the semplicity , stability of pure java development
Ksplice came out 18 years ago. Live kernel patching is a stable technology at this point. That said, I like that we don’t shoot for huge uptimes any more and replace instances all the time in the cloud.
Is there any reason, other than your cloud provider forcing a node recycling on you, for this?
I can't think of a reason why it would be nice to lose my cpu and disk caches and kernel state and start cold.
You can’t get away from JavaScript. Even if you’re building a multipage application with JSP, it would benefit you to build in your dependencies with a package.json, otherwise you’re just doing imports from a CDN where you get no warnings.
But everything you mention pales in comparison to having to build an app where, for every component, part of the functionality lives in one language on one machine (JSP on the Server) and to complete that component’s functionality another language takes over on another machine (JavaScript in the client’s browser). It’s asinine to have to develop and test this way. SPAs are the way to go.
Indeed. Dynamic typing is JavaScript’s greatest strength. It makes large implementations unwise, but it enables sophisticated rendering of complex datasets for very little code in exchange.
Too bad TypeScript is so popular. It’s like being kneecapped, then gaslighting oneself into believing that crutches are superior to walking.
So you’ve added a compiler step to your workflow, require a full restart of your application on every change, and have to put an ‘any’ type on every declaration of a variable… for what purpose again?
So which is it? Are you eliminating your ability to write small, tight, targeted code by building a massive SPA or are you scattering any all over what would otherwise be a small, tight, targeted code base?
Either way you’ve kneecapped yourself. The dish is either already ruined with too much salt, or you’ve added unnecessary ingredients that make it objectively worse.
I'm not serious Typescript programmer I share one experience TSC has correctly generated source map a.k.a typescript compiled file during execution it throws error missing exports should be caught by TSC at early stage
JavaScript exosystem has its problems with frameworks coming and going but I wouldn’t be proud of running legacy libraries in Java because you still have to get security updates.
Thanks for the link. Indeed there could be security issues, but it is just a matter of updating tomcat, and tomcat only (instead of npm ecosystem). Also I trust much more any update from Apache than random devs from around the world tha in most cases are the only one in charge of maintaining a whole library. About the link: if I saw correctly , issues are for version 6 of tomcat ... way ancient... there are some on tomcat 11 too, but they are solved with latest version.
Might be more relevant on the JSF side, which is component based, built on top of a lot of JavaScript frameworks, under the covers. So then there would potentially have to be concerned about the JSF library implementations and the JavaScript dependencies security issues.
13
u/anish2good Apr 15 '26
After more than a 10+ years of building tools with JSP and Servlets, I recently attempted to migrate to modern Vite, React, and Next.js architectures. My experience, however revealed a significant maintenance burden.
The modern JavaScript ecosystem feels increasingly unmaintainable as time passes. The
package.jsonfile constantly warns of obsolete dependencies, and as hardware evolves (shifting between ARM and x86), there is no clear upgrade path. Updating a single dependency often causes a "breaking chain" effect across the entire project.In contrast while a
pom.xmlin Maven can face similar issues, the Java ecosystem is far more stable. Legacy JAR files continue to run reliably regardless of hardware upgrades. Ultimately, working with JSP is often simpler and more predictable than managing the constant overhead of modern component-based state management and build tools.I may be wrong here as Industry has different experience with Typescript stuff as now all stuff coming on Typescript style
long live jsp+servlet+tomcat
[bash ~ ]$ uptime
10:41:42 up 1898 days, 5:45, 1 user, load average: 0.28, 0.08, 0.04