Hacker News Reader

Comment by abraxas | Hacker News Reader

I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.

Can I tell you about live debugging of an app server and hot reloads? Pretty wonderful stuff really.

I can't believe how much knowledge, tooling and experience was thrown in the dumpster when Java was abandoned en masse by the younger generation of devs due to the rise of node.js. And if it weren't for Typescript the tooling would still likely suck.

View on HN

What always strikes me about posts like this is the lack of introspection: why did younger developers reject Java?

It’s easy to say “because they’re hipsters following trends” but I dipped my toe in the Java world years ago and found it immensely frustrating. Eclipse was awful compared to the lightweight editors I was using at the time. The language got in my way more often than it helped me.

I’m sure that’s not the case these days (indeed I’ve done a little Android-adjacent stuff and found it to be fine) but the idea that there were no downsides to Java at the time strikes me as unlikely.

The design of Java is focused on code maintenance. That's exactly what young developers lack experience in. They know how to write greenfield code, by themselves. They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"

Since Java was developed the world has shifted to accommodate a lot more rapid development and code you throw away rather than maintain. But experienced developers also know how often "prototypes" are still around decades later.

Java is also not perfect, and a lot of new languages are conscious of its faults. But the reason it's still around is that it's core principles are oriented to code that sticks around.

> But the reason it's still around is that it's core principles are oriented to code that sticks around.

You could equally say this of COBOL.

> They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"

Ironically, "what they hell were they thinking" is exactly the reaction I have to even Greenfield code written using Spring Boot or any of the other annotation driven nonsense.

The idea that programs written in Java are more maintainable than programs written in (say) Go, where you can read what the program does end-to-end instead of having to guess at what garbage has been generated by Lombok or overridden by some random JAR on the class path is bizarre. Let's not even talk about Gradle.

Yeah, I'll defend Java, but I won't defend Spring. I have no idea what they were thinking.

A lot of external Java framework is about inversion of control. It looks good on PowerPoint slides, but I think it's horrific to maintain (as well has hard to write). Inversion of control means you have no control, and the most common error case is "why didn't my code run?" But you can't use a debugger to tell you what didn't happen. Any breakpoints have to be set inside the framework code, which is open source but is not intended for your eyes.

Yeah, spring was and still is, an abomination. Spring boot also. But it's not a requirement even if many Java projects fell into that trap.

My opinion is that Spring usage should be minimised as much as possible but it is a matter of fact that Spring is not Java.

It is mainstream Java, though.

Yes, it (Spring) is. However its current scope creates more problems then it solves.

Spring may not be Java (The Language), but it absolutely is Java (The Ecosystem).

//go:generate

Yep no magic...

Have you ever read Kubernetes source code?

I have (in depth, often under the gun of a production outage).

Kubernetes is not a good example of idiomatic Go in any sense. Perhaps Spring Boot and friends are also not good examples of idiomatic Java, but they are absolutely the common case of what is found in the wild.

Just like Kubernetes, and its related ecosystem at CNCF are the main raison dêtre why many of us put up with Go.

The difference is prevalence.

Kubernetes is a single (bad) Go project. Every piece of Java I ever see is AbstractFactoryProxyBean nonsense with annotations all over the show.

I don’t know of a Go project where I can’t start at main (for a given program) and work out how it works without a bunch of ecosystem context. I can’t think of a single Java program where I can.

I have experience with code maintenance. The only upside of Java is that it's faster than JS or Python. It's otherwise a worse language and ecosystem, and it was even worse before it had lambdas.

Actually... if it's for a web backend, NodeJS might be faster in practice.

Java was so bad that Android took a hard pivot to Kotlin. If anyone understands the importance of code maintenance, it's Google. They built a language for it (Go). I think it's ok to look at historical Java for what it is and learn from it's mistakes. Modern Java is better. Unfortunately, it's developed a bad rap, and it looks like it's in a decline. Fortunately we have Kotlin, Go, Typescript, etc.

It's a very one-dimensional view.

My problems with Java are startup time and memory consumption (and NPEs).

If that's not your problem - fine. But writing web apps in the Java ecosystem has been terrible for many of the most important years (let's say 2005 to 2015) and that's where all the "young people" forsake it for... PHP, Rails, node.js.

(You can already guess that I'm not even counting myself as part of the younger generation here. I'd used used Java and the JVM intermittently between 2000 and 2020 but it has never been my favourite stack).

But the comment you're replying to doesn't say Java doesn't have any downsides. It just says that Java has a great story for doing shared types between client and server, which is true. It's also true that Java as a language has gotten a lot better over time. This is I think thanks to pressure from other languages written for the jvm like kotlin, And also developer feedback for those who work in other languages like JavaScript. Java is old and boring. Just like go is new and boring. Rust has plenty of downsides this idea that it's easy to use. Seems wrong to me. The borrow checker is famously difficult to work with despite being a central feature of the language. The really big upside to JavaScript is that it's the native language of browsers and so in a weird way. If you want to get closest to the metal so to speak, JavaScript is a better option for most deployed applications. It's interesting to note that the op's article mostly points to build tools that are written in rust rather than applications and I think that's telling.

> But the comment you're replying to doesn't say Java doesn't have any downsides

Yet it blames "hipsters" for throwing "it all in the garbage," implying that there was no rational reason for people to switch away from Java. Naturally, people respond by sharing their reasons.

It had a steeper learning curve than other languages or environments but that was for a reason. You got a lot in return. And those lightweight editors and environments are like that because they don't do very much.

And talk not to me about lightweight. I'm currently on Day 4 of setting up a Python environment in VsCode that doesn't suck. I'm nearly there though it's still a bit inferior to a 20 year old JBuilder install for Java but I guess it needs a few more years to get there. Oh and as I said, I'm on a long quest here to pave the road for my devs but it looks like this hodgepodge of extensions still won't deliver the experience I had decades ago.

Isn't using VsCode for a non-Microsoft language going to be difficult, by (MS's) design? I'm not saying it can't/hasn't be/been done, but I doubt MS are making it easier to do so. It's been their m.o. for a long time now.

I'm also not saying there's a better option for you and your team, either, my friend.

As a python programmer using bare-bones vim (on purpose), having abandoned all fancy IDEs, I really wouldn't know where the state of the art is, anyway, but I doubt the MS leopard has changed its spots.

This feels true for other Microsoft products, but not VSCode. Besides, they embedded Python into Excel (for 365 users) over Typescript or C#.

Interesting.

Embrace & extend complete ;-)

This time it looks like 'integrate' will be the third step.

Thanks for the great info.

Isn't using VsCode for a non-Microsoft language going to be difficult

Python is pretty close to a 'Microsoft language' these days. They've hired several Python core developers to make sure windows is first class citizen for python and the developing python on windows and with VSCode is as good an experience as possible. They also develop the official VS Code Python extension and language server as well as many other python tools and extensions.

I'd say the current state-of-the-art is either VSCode with the Microsoft python extensions or Jetbrain's PyCharm. Personally I slightly prefer PyCharm Pro, but it's pretty much a toss up.

Thanks for excellent breakdown.

Java is verbose, is a resource hog, requires runtime management for basic app performance, the major frameworks (used to) require an awful lot of boiler plate, the developer tooling almost necessitates an IDE which 10-15 years ago meant eclipse which was slow, bloated, and unstable. There’s also always been licensing “fun” with oracle, sun, and the jdk.

What are you talking about, seriously. 10-15 years ago, eclipse was neither slow nor unstable. It worked perfectly well. IntelliJ was not slow or unstable. There were not real major licensing issues.

As a newcommer to javascript, I was able to learn faster and produce same quality faster then non-IDE developers. Not because I would be smarter or more talented, but because I had no emotional need to prove myself by not using ide.

> What are you talking about, seriously

It's probably unavoidable that people's memories will differ, but personally, as someone who worked with Java 10–15 years ago and then ran away as fast as he could, these are the things I remember most: the IDEs being awfully slow and unstable (though quite powerful for their time) and the language/ecosystem being painfully verbose and full of boilerplate and layers of indirection. I remember how, after switching away from Java, I felt elated by how easy and maintainable things could be when I was allowed to use simple, fast tools and write straightforward code that just did what it was supposed to do.

Eclipse was _the_ tool when I was working with Java at the time. Slow and unstable is definitely my lasting memory, compared to virtual studio 2008/2010 which was fast and powerful.

> there were not real licensing issues

Oh yes there were. Even in 2024 the “which JDK are you running on” debate still goes on. There are notable differences between corretto and openjdk, and openjdk and Oracle JDK. Here [0] is a stack overflow question that notes it was asked 10 years ago that talks about the various JDKs and the license change where oracle started charging for JDK access.

As for your point about IDE’s vs non-IDE’s that’s a straw man. I said that you were forced to used an IDE for Java (which is of course not technically true but compared to rails which took of at that time it is), but also that the IDE du jour (eclipse) was pretty monstrous.

I’ve said this on here before but the minute maven gets introduced into a project build times are measured in minutes. My current work project is c# and I can run my entire test suite faster than the jvm got itself up and running on my last kotlin project. Even IntelliJ and co suffer from these limitations - manually bumping the memory limits for IntelliJ and friends in 2024 is practically a requirement, and the startup times are very Java inspired.

[0] https://stackoverflow.com/questions/22358071/differences-bet...

If you mean visual studio for dotnet and it is comparably piece of crap. A lot of unexplained behavior and it generally feels like someone just wanted to check boxes. Dotnet and visual studio actually made me love love a lot more after I worked with them.

Java and Eclipse are waaay better then C# and visual studio. Kotlin is a pure pleasure against C#.

Also, I see people using different JDKa on the same project. That there is competition is a good thing, it is not like you was locked in one.

> Java and Eclipse are waaay better then C# and visual studio. Kotlin is a pure pleasure against C#.

Except, unlike Kotlin, C# has a rich selection of what to use for development across a variety of platforms and is not constrained to JVM's type system limitations, allowing the syntax differences to have meaningful impact on the code execution.

It also has excellent, comparable to Go and Rust, CLI tooling to further streamline the process of quickly managing, building, testing, running and deploying projects, something JVM ecosystem is yet to provide an alternative for.

> If you mean visual studio for dotnet and it is comparably piece of crap. A lot of unexplained behavior and it generally feels like someone just wanted to check boxes.

I disagree. dotnet has it's quirks, but so does every mature ecosystem. I wouldn't use "piece of crap" to describe it (or java) and I get that it's an opinion, but I think your opinion is more misguided than what yo're accusing other people of believing.

> Kotlin is a pure pleasure against C#.

My last project was a kotlin backend powering a C+ desktop app. The kotlin backend took longer to compile than the C++ did. Kotlin is the kitchen sink bolted onto Java. It's definitely a nice environment to work in, but it's certainly not a more streamlined java.

> That there is competition is a good thing, it is not like you was locked in one.

If by competition you mean OpenJDK forks with minor differences then yes there's competition. To me that's not competition, that's fragmentation.

Yes, 10-15 years ago, Eclipse and IntelliJ were unbearably slow, overly complex, and made developers very frustrated.

Yeah but that was when product managers broke it. The early days eclipse circa 2002 was amazing

15 years ago, it took a full 10 minutes to launch IDEA or Eclipse and have it finish opening a large (100kloc+) java project on a brand-new high-end MacBook Pro.

3-10 crashes per day were common.

Lots or coffee breaks, or at least switching back to emacs to just finish editing whatever classes you were touching.

In my experience, young people who hated java never worked in java and knew nothing about it except that it is evil.

The second thing however is that fronted is better off in non-java languages, you can afford to do small backend in typescript and what not. And larger enterprise projects were done in java the whole time.

Exactly! I got my first job in Java after a few years as hobbyist programmer in other languages (mostly PHP and JavaScript but a few others too) and what struck me was that the tooling was both mandatory and painful to use.

I wasn't fond of JavaScript (In particular, I never liked dynamic typing), but when I had the opportunity to work in node.js instead of Java I took it immediately, just to avoid the pain and suffering that the Java toolchain inflicted on me.

Java is a language of bondage and discpline. And architectures. And myriad pointless interface definitions. And overblown class hierarchies for problems ill-suited to the OO paradigm.

I started my career in Java, and worked in it for 20 years before I really started using Javascript in anger. I didn't (and don't) like Javascript, but the freedom for prototyping was a revelation. When Typescript appeared, I fell in love.

At least from an Android point of view, the JVM world still has its share of frustrations and lack of polish/QoL relative to other software development spheres. Gradle has me pulling my hair out multiple times each year for example, and yet for some reason nobody sees it fit to replace it with something less ridiculously complex and prone to error (user or otherwise).

Yeah, gradle/maven was a mistake that happened along with most "app store" style 3d party library slingers.

I'm of the opinion that the world was a better place with Ant and when we had third party dependencies manually, deliberately adn deliberatively managed by hand in /jars/thirdparty

As long as you don't get to debug such builds....

As someone that was writing Ant scripts when CruiseControl was modern, and there was no Ivy in sight, not sure if it was such a better place.

I hated Maven at the beggining, exactly because we got some hipster company pushing for it during Maven early days, it was still hot out of the oven.

20 years later, I don't see a reason to use anything else other than Maven.

Jetbrains have a project to try and replace Gradle.

I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first.

Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.

We just keep using Maven, there must be valid reason on customer side why we should use Gradle instead of Maven on our Java consulting projects.

It’s both now.

https://gradle.github.io/declarative-gradle/

Fingers crossed.

I've long since given up on Gradle being able to get this stuff right. The syntax they're proposing is the THIRD similar-but-incompatible syntax they've adopted after Groovy and Kotlin. Good luck figuring out which is in use by looking at a code sample.

The biggest problem with Gradle is not Kotlin or even Groovy syntax. Kotlin isn't a bad language to use even for writing configuration. It's that the entire thing is designed in extremely confusing ways from back to front, and has a lot of awkward design choices and bugs that result in a hyper-complex user model.

What the JVM world needs is a totally new tool that has the same feature set as Gradle but with a drastically simpler mental model behind it. The only real contender right now is Bazel, I think.

Don't blame Java for the misteps of Google and Android team.

Android started being devleoped mostly by C++ refugees, that is why originally all framework code is full of m_ prefixes.

Then the whole standard library fragmentation that persists to this day.

Despite the whole excuse why Dalvik was created, Nokia and Sony-Ericson had quite good JVM implentations for Symbian.

When Kotlin was introduced they stiffled Java on purpose, left it on Java 8, using Java 8 examples to promote Kotlin, and have since Android 12, started to finally update ART to more modern versions, because as it turns out, even with Kotlin, loosing compatibility with the Maven Central ecossytem isn't that great.

Still, it is mostly Java 17, and all the ongoing improvement in Java land across all JVM vendors, will most likely never land on Android.

Android is not Java, even though it relies heavily on the ecosystem for its tooling.

Android is basically Google's .NET, and Kotlin plays the same role as C# in relation to Microsoft's J++, that lead to Sun's lawsuit.

Yup. As an older programmer I can say that there were indeed very good reasons back then to stop using Java. Mostly related to JVM but also the language lacked lots of features.

Java today looks like a fine platform, though.

Speaking as a younger developer at the time, Java just seemed weak compared to my favorites -- Common Lisp and Scheme. It lacked a proper procedural abstraction and forced you to do everything through classes and objects in a way that not even Smalltalk, having blocks, demanded. This was especially the case when it became an enterprise language and the standard development process involved lots of boilerplate. Also, a lot of kids came out of school knowing almost only Java, and it seems they were cut off from different worlds of development which could provide some insights. Even C++, which I loathed, had things to teach.

I've grown up a bit since then, and so has Java. These days I work in Java for my day job, and it's perfectly fine. I don't even mind all the boilerplate, I can look at a page of code and just see blonde, brunette, redhead.

But I still love Common Lisp and Scheme much more.

> The language got in my way more often than it helped me

Got in the way how? By insisting that things have types and one cannot blindly add an object to an array [] + {} and expect it to behave? Never mind that in Javascript adding an array to an object {} + [] gives a different result.

ETA: for bonus points, what does {} + {} return?

I won't apologize for rebelling against Eclipse, SOAP, XML and AbstractBeanFactories. Java the language is pretty cool and very powerful, it's the ecosystem that was turning people off.

I hear Java has gotten a lot better. But then again there is C#, which is pretty much just better Java. Still too enterprisy for the tastes of most HN types though

Java types are not nearly as expressive as typescripts. As someone who has worked with both, I would personally pick typescript everytime.

> I'm quite dismayed to say that this has been a feature of any Java developer setup for the past 25 years. Yet hipsters threw it all in the garbage when node.js took off and are only now starting to approach feature parity with a 2002 JBuilder or Eclipse of the same era.

Last I checked If I change a signature or something in Java, I am not guaranteed the whole thing "checks". If I add a new exception to a function, how do I know what else is effected?

Java checked exceptions are (were?) a wonderful feature that was wrongly dissed for the same reason Java types and IDEs were dissed. It forced people to handle exceptions or pass them up the call stack but they had to be dealt with. And IDEs were aware of them so not catching or rethrowing was immediately flagged by the IDE.

I give it five years until Typescript and peers adds checked exceptions.

TypeScript definitely won't add checked exceptions, because Anders Hejlsberg considers them a mistake[0].

[0] https://www.artima.com/articles/the-trouble-with-checked-exc...

If you add a checked exception to a function, your code will not compile and the compiler errors will tell you everything that is affected.

It's pretty interesting that people think Java was abandoned because of other languages, and not because of the problems of Java itself - or indeed that features like hot reloading and live debugging are niche or unique to Java.

.NET has also had all these features for just as long, and is less prone (though definitely not immune) to AbstractFactoryProxyBean nonsense.

Java was abandoned en masse by the younger generation

We tried. Java was fine, JBuilder was fine. When they instead started pushing J2EE, EJB and all the other acronyms I've forgotten, this 'youngster' realised he'd never be smart enough to be a Java developer and bailed back to C, Perl and Python.

Had they focused on Java and making Java a great language in its own right, it no doubt would have gone a lot better. But all the 'hype' and marketing around Java was focused entirely on these huge frameworks and enterprise 'solution' architectures which most 'youngsters' just didn't understand and didn't see the need for.

If someone makes it clear their product isn't for you and that they don't care about solving your problems, is it strange they abandon you?

JavaScript is an awful language. Doesn’t mean Java is the answer. There are other languages—Go, Rust, Python, C# that offer better protection without sacrificing ergonomics.,

> feature of any Java developer setup for the past 25 years

do you mean rmi/javabeans or something else ?

beside that, I left java long ago, and believed in simpler REST stuff but now I realize that it's indeed rediscovering stuff people dealt with long ago

Java beans was just convention. Enterprise Java Beans was a mistake which probably contributed to Java's bad rap for a while. But you could use an app server without EJB just fine. I did for years and never had problems.

As for rmi, when Java was in its heyday the most popular protocol for remote api handling was SOAP. But when RESTful era arrived Java tooling adapted very quickly and it made little difference what you were using to call outside the app server.

and what kind of library / ide plugin is used to call rest api in a type safe manner without writing boilerplate ?

Most frameworks will do that? In Micronaut it's something like this on the client:

    @Validated
    public interface PetOperations {
        @Post
        @SingleResult
        Publisher<Pet> save(@NotBlank String name, @Min(1L) int age);
    }

then you inject

    @Client("https://example.com/pets") @Inject PetOperations pets;

and call its methods. It will use the annotations to validate the call client side before sending it, and you can implement the same interface on the server:

    @Controller("/pets")
    public class PetController implements PetOperations {
        @Override
        @SingleResult
        public Publisher<Pet> save(String name, int age) {
            Pet pet = new Pet();
            pet.setName(name);
            pet.setAge(age);
            // save to database or something
            return Mono.just(pet);
        }
    }

where the same validations will occur before the call is accepted.

thanks

Jesus Christ.

JavaBeans and EJB became things because Microsoft was eating everyone's lunch with their component paradigm, COM, on the client side and were making inroads into server-side enterprise computing as well. With COM, you could write components that just plugged right in to an application, in any language. Java, despite being ostensibly object-oriented all the way down, didn't have an answer for this until JavaBeans emerged and then EJB for the server side. You have to remember that Microsoft had a relentless focus on developers building stuff on top of their platform. That image of Steve Ballmer sweating like a mule and chanting "Developers! Developers! Developers!" wasn't just a meme, it was an indicator of the entire company's direction. Nobody could match them at the time. From Internet Explorer to Visual Studio, 70%-80% of Microsoft's monopoly was built in simply outcompeting everyone else. If people were locked into Windows, it was because it just made sense from a business standpoint.

But yeah, I built business apps with just Tomcat and no J2EE components and it was fine.

It never occured to me to link COM and J2EE RMI/EJB.

Both of them are at their core a set of conventions to make a component usable at runtime without having to know its API aforetime.

Don't worry, the Typescript ecosystem is fast becoming Java.

And that's the exact reason I'm done with it.

You mean capable of stable firehose throughput, similar to Go? State of the art GC research on state of the art VM? I wouldn't be surprised if Java had more money behind it than JS on the R&D & corporate backing side.

> Don't worry, the Typescript ecosystem is fast becoming Java.

Typescript is somehow becoming a laguage that supports writing extremely performant high throughput and very scalable server code? That seems unlikely. So no worries, it can't become Java.

I said the Typescript ecosystem.

Java, as a language is fine I guess, but the culture around it sucks.

> Java, as a language is fine I guess, but the culture around it sucks.

Culture is what you want it to be.

There are indeed some ridiculous subcultures within the world of developers who use Java. Like J2EE-anything or any of the baroque frameworks.

It is important to realize none of that is part of Java and none of that is required unless you really want to.

You can use Java simply as a memory safe language with reasonably good type safety that can create wicked fast code and has huge library and tooling support. On all those checkboxes, there are few-to-none options that are so good across all those aspects at once.

Unfortunately so many people just complain about writing TaskStubConsumerWatcherVisitorServiceContainerListIdentifier classes, without realizing nobody is forcing you to do that. So don't.

GWT was an attempt to let you live in java land and also still get the (tremendous) benefits of deploying to the browser Javascript VM. We used it on a java backed project, but we were not building an SPA so didn't see all the benefits.

I haven't used it for a long time, but it's still alive: https://www.gwtproject.org/

That's cool but I get a chuckle when I see server side html rendering being all the rage now and thinking to myself, should I tell the juniors about servlets, JSP and Struts?

It still blows me away that we settled on JavaScript as a VM. It wasn't designed for that, and it took a superhuman effort to make it work well enough.

I feel like there's an adjacent universe where the JVM lives in every browser and JS was a weird failed experiment. But it turned out that the browser was the universal UI everyone had waited for, and Java didn't connect to it while JS entrenched itself there.

GWT was a glimpse of trying to send us to that universe, via a twisty back door. But it was never gonna happen.

the client side java didn't last long, flash and js were more mechanically sympathetic on too many aspects (dev culture, user expectation about load time, cute visuals)

but yeah js is a strange creature

You can thank Sun Microsystems for this. They had the world in the palm of their hand with HotJava, but decided to abandon it. If they had continued, Java would been the language of choice for the web and they likely wouldn't have been acquired by Oracle.

HotJava, IIRC, was more focused on Swing apps. Swing just wasn't the right thing for users; the HTML DOM turns out to be more comfortable. Even though it means sometimes failing out to the Canvas, which gives you nothing.

NB: I was very distantly part of the Swing team. I did early reviews of its design documents.

Considering we have full replacement frameworks like React, Flutter, etc built as DOM replacements, I would say Swing was definitely the right thing for users. Probably could have offered an "easy markup enhancement" library for plain documents, but anything extensively dynamic should be written with a proper UI framework.

It's a hard sell for the majority of users and the mainstream market at the time. Flash apps had cute, lazy loaded, ~lightweight, animated mini apps. Anything java at the time was heavy, enterprisey, requiring more setup to get blocky GUIs that didn't do much.

I wish to live in that universe, and hope that WASM will bring it closer to us. Clearly, Javascript gets compiled to some intermediate representation, that then gets JITed/interpreted and then interacts with the native browser API.

I wish us devs would have access to that intermediate representation.

Most of the abandoning of Java was due to Ruby on Rails not JavaScript.

Not where I am. Maybe a peculiarity of the community I'm in but here it was all Node all the time after Java was declared uncool.

Java took a ton of heat in 2005-2009 (before Node existed) because Rails came through and was eating it's lunch. It's the reason that a huge percentage of the successful Web 2.0 companies were built using Rails, not Java or .NET.

No chance, relatively few software companies ever adopted Rails but a huge number went from Java or .NET -> JS/TS. The draw of cross project code reuse and having teams only needing to know a single language remains compelling.

Java was largely already being abandoned before NodeJS existed. A huge percentage of the web 2.0 companies were built on Rails. Twitter, Github, Shopify, AirBnB, Groupon, SoundCloud, Instacart were all built on Rails. It maybe flew beneath your radar but it was a phenomenon at the time, way before Node.js even existed.

Those examples aren't representative of the broader industry though. There are far more devs working at former Java and .NET shops that have never written a single line of Ruby and are all in on JS/TS now

What you are saying is hyperbole. They are "All" in JS/TS now? I never said JS wasn't bigger than Rails, but Rails was the first and biggest axe to fall against Java. JS just took the baton from them

I said they've gone "all in", not that they're all using JS/TS now

When java shut it's door to me. When c++ gave me the cold shoulder. When mvn was very confusing for me. This little language became a cozy home for me

As someone who did Java WebApps for 10 years - they sucked if you cared about making a good user interface.

I thought JS was bad at the time, but node.js was a breath of fresh air for API development, and client side JS has been fine for like 10 years (assuming you care about UI development).

I'd never go back to Java except for maybe some backend service away from the UI.

Hot reloads?

https://tapestry.apache.org/development-dashboard.html

https://tapestry.apache.org/service-implementation-reloading...

Java was not abandoned en masse. Small projects were done in node.js. Large projects were and still are done in java or other non-js languages.

Reply on news.ycombinator.com