this post was submitted on 13 Nov 2024
794 points (96.2% liked)
Greentext
4383 readers
1383 users here now
This is a place to share greentexts and witness the confounding life of Anon. If you're new to the Greentext community, think of it as a sort of zoo with Anon as the main attraction.
Be warned:
- Anon is often crazy.
- Anon is often depressed.
- Anon frequently shares thoughts that are immature, offensive, or incomprehensible.
If you find yourself getting angry (or god forbid, agreeing) with something Anon has said, you might be doing it wrong.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
And much of the confusion and frustration at "Java" is actually because of Spring, or the "enterprise" nonsense making everything unnecessarily complex. You can just... write Java without any of that.
You shouldn't though, because Kotlin exists, which fixes everything that's wrong with Java while still being 100% compatible, so even in legacy projects you can mix and match and write new code in Kotlin without needing to rewrite any of the existing Java.
It’s not corporate world, it’s web. Spring de facto is the only modern way to build web services and integrations in Java and Spring comes with DI because it’s the way to build efficient extendable framework.
Micronaut and Vert.X also work, and with Kotlin you unlock that ecosystem as well, for example Ktor. One could argue whether Spring is still a modern framework. It works very well, but there is a lot of "magic" and hard to understand annotations with Spring that make it harder to learn and debug than it could be.
Of course the reality in enterprise environments is that change is often very difficult and such changes are a hard sell when you already have millions of lines of Spring code.
But if you are not locked to Spring, there are better options. DI being build in is another negative to me. Spring does everything, and any project using it becomes a "Spring project". Which robs you of any choice. If you use Ktor for example, it's only a library, not a framework, and only does the web component. You choose your own DI library that works for you, you choose your own serialization, you choose your own persistence/database solutions, and you can replace Ktor with something else 3 years down the line, if needed, without touching any of the other parts if the project.