Hacker News Reader

Comment by arez | Hacker News Reader

which ones specifically? I like Spring Boot tbh

Hibernate mostly. Spring too, but it has been a while. Mostly I just find the abstraction isn't worth it .

The way you write this makes be think you rawdog'd Hibernate and Spring Framework. Don't do that... you will hate yourself.

Boot is something entirely different. You write very little code and get a ton done. The trade off is you are firmly now a "Boot" codebase, but once you learn how Boot works it's not a big deal.

I've had to maintain a couple Spring Boot apps and I absolutely cannot stand them: they pull in a whole pile of random dependencies and do weird things to your build with little explanation. Then, all the functionality involves a ton of classpath scanning and annotation-based DI that makes it hard to figure out how all the things fit together.

I mean, have you learnt the framework before attempting to do that?

Frameworks are frameworks, not libraries. You can't just start writing/understanding them - frameworks are different from libraries precisely because they call your code, not the reverse.

That's a great explanation. Thanks for that.

Yes, the problem is exactly that the framework calls your code instead of being called by you code.

That's how all frameworks work though. This is not a criticism of Spring Boot. You are criticizing the use of a framework at all.

Some people hate to write the same basic things over and over. That's where a framework excels. Write only the glue/logic you need to make your app work.

The way you have described your experience with Spring Boot seems to imply you did not take the time to learn it at all, and therefore its' unsurprising to us you had a hard time of it.

Not writing the same thing over and over again is a feature of abstraction. A framework is a user-hostile way to abstract because it makes the source code opaque to developers. There's no reason why a library-based approach has to be more repetitive than frameworks.

CRUD backends have well-understood requirements, in a way, a significant part of the work is done for you. You are there to customize certain parts only.

How else would you architect with this in mind? Given that literally every other framework is quite similar (RoR, PHP's solutions, etc).

There is another niche, the HTTP server libraries, but they are much more low level.

Right, so you cobble together 48 different libraries, wrangle all of their configurations and stitch them all together yourself.

You do this 18 times because you have 18 different apps with similar requirements but deal with different data/endpoints/whatever.

On your 19th app you decide to standardize how you cobble together all of these libraries so that you don't have to start at ground zero every single time.

Now you've invented a framework.

I was working with legacy code bases where the original Devs loved frameworks. Massive performance problems and nobody could understand how it all fit together at runtime.

Hibernate eventually got entirely nuked, Spring we couldn't entirely unwind easily; it had caused a whole bunch of crappy architectural issues and was too much effort to rewrite from scratch.

Although the code looked simpler using the frameworks and annotations, it was actually a huge rotten mess that didn't work well at all, with workarounds for all kinds of weird things in it.

I find pretty much every ORM in any language is problematic. The best you can hope for is a certain amount of internal design consistency, so that even if you can't do what you want it's at least clear what you are doing.

Since I had the "joy" to use TypeORM (node.js stuff), I really value Hibernate, although there are some little corner cases I'd like to be better. But ORMs solve a really hard problem and I haven't seen anything better than Hibernate so far (and don't come up with JOOQ or MyBatis!).

Reply on news.ycombinator.com