[JTenerife]

Spring is a very powerful but complex framework. It's very easy to get started (Spring Boot). I especially love JPA as I just need the persistence to be getting done. The architecture is clean and standardized.

However, you have to be prepared for a serious learning curve when needing customizing (e.g. attribute based authorization with Spring Security and AOP). It's a jump in the cold water after the pain- and effortless start using Spring Boot.

I haven't mastered Spring yet (in depth understanding of DI, AOP and the configuration), but I feel that when mastered, Spring is the ultimate framework to build concise and clean applications.

[sverhagen]

It's always scary to have a lot of power hidden behind an annotation that you don't completely grasp. But I rather take that than having to reimplement all the logic, such as for security, that isn't core to my own business. I have come to trust Spring as a quality product, which will do a better job at those things than I would ever be able to do with the (not in an unhealthy way) resource-challenged teams that I tend to work on.

[lomnakkus]

Personally, I don't like annotations, and it's related to a very specific word you used: Hidden.

Annotations feel very action-at-a-distance-esque because the code that scans for them and processes them is completely separated from the annotation itself. There's no really universally applicable way of just going "show me all the code that processes annotation X" to your IDE... and that's often scary and can also lead to incredibly hard-to-debug problems which would be near-instantly solvable if you could just see the code which processes an annotation immediately.

I feel decorators/higher-order functions are generally to be preferred since it's actually about applying concrete transformations. (Of course they may not always have equal power, but a lot of the time annotations are basically just a HOF in disguise.). Unfortunately, without good type inference the syntax of HOF can get incredibly clunky.

[viach]

> However, you have to be prepared for a serious learning curve when needing customizing

Can be said about everything in this world, right?

[hardwaresofton]

Yes and no -- I often found the difference between a well architected and modularized (when possible) system and one that isn't is that the learning curve is more linear.

Frameworks that are large often have lots to learn in them, necessarily, but how that learning has to be done can differ. Good frameworks will be simple enough that you can almost ignore the ocean of complexity until you need to dive in, and when you dive in all of the pieces that you now must need to learn and know are almost obviously necessary.

For example, compare/contrast a system like express (nodejs) with a system spring in java. The func(req, res, next) paradigm gets you VERY far, but doesn't expose you to too much before you need to. Implementing middleware is much more delightful in nodejs (and other frameworks that adopted the func(req, resp, next) abstraction) than it is in Sprint.

[barrkel]

No. "Make the easy things easy, make the hard things possible." Frameworks are usually good at making their target use case easy; they're worthless if they fail at this. The risk is when you need something outside the box, do you need to find a nicely wrapped framework widget to plug in, or can you easily wrap it yourself? Or is the abstraction light enough that you can easily drill through to the implementation layer?

It's about optimizing for the easiest case vs the harder cases in design. This is the design space that answers the question as to how serious the curve is. Serious curves require a leap in complexity, whereas other approaches can have more incremental increases.

Authentication was a fine example. The canonical example in my mind though is Visual Basic vs Delphi. VB (version 3 era, for Windows 3.11) required that you write your components in C++. You could use the framework in Basic but to customize it you needed a leap up a cliff in complexity. Whereas Delphi's VCL was written in Pascal just like your own code, the source shipped with the product, you could step through it, and you could even make a copy of the source and modify it as a step on the way towards writing your own component.

[nikanj]

With PHP frameworks, I can monkey patch things by grabbing a text editor and just editing the functions I need fixed.

On the other end of the spectrum, looking at the Windows compile instructions for popular C++ products makes me reach for a bottle, of Advil or Absinthe.

Yes, I can customize any component assuming I have the source (and modification rights), but for some components, the customization comes naturally, with others, just getting a runnable binary is a whole-week ordeal.