Re:Java 26 is here, and with it a solid foundation for the f...
by hackemmy on Tuesday March 17, 2026 @06:43PM
(#47419378)
I write TypeScript daily and honestly it is not about being scared of Java. The ecosystem just makes more sense if you are already building for the web. You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. That is a hard thing to replicate in Java even if the language itself is technically better in some areas. The barrier is not cultural fear, it is practical convenience.
[ Parent
| on HN ]
Re:Java 26 is here, and with it a solid foundation for the f...
by ivan_gammel on Tuesday March 17, 2026 @07:43PM
(#47419885)
With SSR/HTMX/HATEOAS amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.
Re:Java 26 is here, and with it a solid foundation for the f...
by winrid on Tuesday March 17, 2026 @11:15PM
(#47421231)
What if you have a mobile app? Rest APIs? The argument doesn't work. Every backend language has ways to generate specs/types/clients from the APIs code.
Re:Java 26 is here, and with it a solid foundation for the f...
by chii on Tuesday March 17, 2026 @11:24PM
(#47421301)
> You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server.
that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity.
I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).
Re:Java 26 is here, and with it a solid foundation for the f...
by rossjudson on Tuesday March 17, 2026 @11:36PM
(#47421362)
GWT was a huge success, and eventually became obsolete -- which is not the same as "failing horribly".
It took a long time for the web ecosystem to build up the capabilities that removed the need for GWT.
For a while, it was quite a good way to build and heavily optimize certain kinds of web client applications.
Re:Java 26 is here, and with it a solid foundation for the f...
by gf000 on Wednesday March 18, 2026 @03:45AM
(#47422780)
Yeah, I believe some ex-Googlers even claimed that writing Gmail was simply impossible at that time with ordinary JS, and the abstraction behind GWT was an absolute necessity (though maybe the frontend part was not all that important - closure compiler is still alive though)
Re:Java 26 is here, and with it a solid foundation for the f...
by chii on Wednesday March 18, 2026 @08:39AM
(#47425005)
On the other hand, gwt did not gain much traction, and the majority of frontend developers disliked it (granted, they do prefer javascript+css rather than coding the frontend via gwt widgets).
Re:Java 26 is here, and with it a solid foundation for the f...
by rossjudson on Tuesday March 17, 2026 @11:32PM
(#47421346)
Different tools for different purposes...which is good/right.
TypeScript is a superior programming environment for the browser, for sure. Using it on the server? Why not, if you're not trying to scale (in capacity, or functionality).
Language-agnostic serialization exists for a good reason. It's not always right, but it's almost always the right thing to do.
Re:Java 26 is here, and with it a solid foundation for the f...
by 9rx on Tuesday March 17, 2026 @11:56PM
(#47421452)
The biggest problem with Typescript in the modern era is that LLMs are pretty bad at it, at least as compared to some other languages that are more well suited to LLM generation. What you say may have been a boon in the olden days, but it is hard to justify now. It is difficult to avoid Typescript/Javascript in the browser, sure, but now it's just as fast to duplicate everything in another language for the backend and at least gain the advantages on that end.