4 ms·

> Your mileage may vary. Idk, I have written Java EE (and Jakarta EE) projects, and I found everything to be so much worse than e.g. Next.js + TypeScript. It f

> Your mileage may vary. Idk, I have written Java EE (and Jakarta EE) projects, and I found everything to be so much worse than e.g. Next.js + TypeScript. It feels like everything is broken in the Java web-dev ecosystem, except spring. I had plenty of struggles with the JPA, where some SQLite JDBC wasn't straight up working or MySQL8 was not supported. This was just to get the project running. Then, JSPs have like 300 different ways and 300 different opinions on how to do stuff. Should you do routing via XML? Should you put your routes in annotations? Or do implicit navigation in the JSPs? Managing sessions is a pain too. Setting up and deploying Java application servers in prod is way too complicated compared to Node, Deno, Python, Ruby, Whatever. > Starting with motools and IE6, jQuery, into React + Redux Anyway, I hope you didn't have to write pure react without any framework on top of it. I mean, the library is fine, and the React patterns mostly stay the same, but React.js is missing a lot. Personally, I wouldn't touch pure react, unless I have to write my own framework on top of it, but that hasn't been the case yet. P.S. I also had to work on JavaFX applications in the past. I used IntelliJ too, and the tooling of JavaFX is broken to the point, where you can't even use place controls in your great FXML. Which just made me think about another thing I dislike: Java's XML fetish. I don't hate the format, but knowing what XML namespace is the correct one is often beyond me. Writing new Java is probably fine, but older Java codebases are the often PITA. :(

whywhywhydude 4y ago
XMLs, JSPs, Java EE are relics of the old age. They were built during late 90s and early 2000s. No new projects use them. You can’t say Java is bad because of how things were 20 years ago.
- stcroixx 4y ago
  Java EE is an evolving spec and includes basic things like JSON processing, REST, JMS, JPA, even the servlet API itself - these things are very popular in greenfield projects. If you're writing a web app, you're using Java EE unless you're writing your own server.
yCombLinks 4y ago
All of the things you complained about were out of fashion before the thing you endorsed was even invented. Hardly a fair comparison.
skwirl 4y ago
>It feels like everything is broken in the Java web-dev ecosystem, except spring. "Except Spring?" Spring IS the modern Java web-dev ecosystem. You can't write it off as a small exception. With Spring Boot it is very easy to get something working quickly. It sounds like you may be suffering from the Paradox of Choice when it comes to the broad Java ecosystem(s). For new projects, just pretend nothing exists except Spring Boot and use annotation/java config for dependency management. There's obviously a lot of legacy Java out there, but it's so massively popular that there's an immense amount of greenfield development going on as well. Don't take jobs working on Java EE stuff unless nowhere else will hire you and/or they are paying you a massive amount of money to do it.
- KronisLV 4y ago
  > It sounds like you may be suffering from the Paradox of Choice when it comes to the broad Java ecosystem(s). For new projects, just pretend nothing exists except Spring Boot and use annotation/java config for dependency management. Spring Boot is passable, as long as what you are trying to do fits within what you're allowed to do and you don't have to dig into the internals too much. Regular Spring is painful, attempting to migrate a project that's been around for close to a decade from Spring to Spring Boot without a rewrite is even worse, especially if it is stuck on an older version of Spring, even worse if you need to go from JDK 8 to JDK 11+. The complexity of Spring and Spring Boot itself is pretty considerable. I wouldn't scoff at anyone using something like Dropwizard for comparatively smaller projects, as I did recently: https://blog.kronis.dev/tutorials/2-4-pidgeot-a-system-for-millions-of-documents-the-application https://blog.kronis.dev/tutorials/2-4-pidgeot-a-system-for-m... In a limited set of circumstances it can be useful to opt for something simpler, that's built on a bunch of other boring, mostly "standard" or at least idiomatic packages. Some might advocate for Quarkus, others for the likes of Vert.X - both are interesting and pretty usable, but perhaps it's a bit too early for either of those. For those interested, ktor might also be worth an exploratory look in non-prod projects (if you like Kotlin too). There is something to also be said about the likes of Ruby and Ruby on Rails, or PHP and Laravel, or .NET and ASP.NET, or maybe Python and Django - sometimes having fewer options can also make you more productive, especially if a lot of ecosystem is grown around those "main" solutions. Perhaps that's an argument in the favor of Spring Boot.

whywhywhydude 4y ago

XMLs, JSPs, Java EE are relics of the old age. They were built during late 90s and early 2000s. No new projects use them. You can’t say Java is bad because of how things were 20 years ago.

stcroixx 4y ago
Java EE is an evolving spec and includes basic things like JSON processing, REST, JMS, JPA, even the servlet API itself - these things are very popular in greenfield projects. If you're writing a web app, you're using Java EE unless you're writing your own server.

yCombLinks 4y ago

All of the things you complained about were out of fashion before the thing you endorsed was even invented. Hardly a fair comparison.

skwirl 4y ago

>It feels like everything is broken in the Java web-dev ecosystem, except spring. "Except Spring?" Spring IS the modern Java web-dev ecosystem. You can't write it off as a small exception. With Spring Boot it is very easy to get something working quickly. It sounds like you may be suffering from the Paradox of Choice when it comes to the broad Java ecosystem(s). For new projects, just pretend nothing exists except Spring Boot and use annotation/java config for dependency management. There's obviously a lot of legacy Java out there, but it's so massively popular that there's an immense amount of greenfield development going on as well. Don't take jobs working on Java EE stuff unless nowhere else will hire you and/or they are paying you a massive amount of money to do it.

KronisLV 4y ago
> It sounds like you may be suffering from the Paradox of Choice when it comes to the broad Java ecosystem(s). For new projects, just pretend nothing exists except Spring Boot and use annotation/java config for dependency management. Spring Boot is passable, as long as what you are trying to do fits within what you're allowed to do and you don't have to dig into the internals too much. Regular Spring is painful, attempting to migrate a project that's been around for close to a decade from Spring to Spring Boot without a rewrite is even worse, especially if it is stuck on an older version of Spring, even worse if you need to go from JDK 8 to JDK 11+. The complexity of Spring and Spring Boot itself is pretty considerable. I wouldn't scoff at anyone using something like Dropwizard for comparatively smaller projects, as I did recently: https://blog.kronis.dev/tutorials/2-4-pidgeot-a-system-for-millions-of-documents-the-application https://blog.kronis.dev/tutorials/2-4-pidgeot-a-system-for-m... In a limited set of circumstances it can be useful to opt for something simpler, that's built on a bunch of other boring, mostly "standard" or at least idiomatic packages. Some might advocate for Quarkus, others for the likes of Vert.X - both are interesting and pretty usable, but perhaps it's a bit too early for either of those. For those interested, ktor might also be worth an exploratory look in non-prod projects (if you like Kotlin too). There is something to also be said about the likes of Ruby and Ruby on Rails, or PHP and Laravel, or .NET and ASP.NET, or maybe Python and Django - sometimes having fewer options can also make you more productive, especially if a lot of ecosystem is grown around those "main" solutions. Perhaps that's an argument in the favor of Spring Boot.