[cduzz]

I'm not sure that's contradicting the parent post.

A framework is an added friction to picking up a development environment but potentially a huge asset to velocity once people are up to speed. You haven't gotten properly up to speed in that framework and that site's use of the framework. Perhaps you never spend enough time in that domain to really need to pick it up, in which case you'll always pay the "WTF is this?" tax.

But it's equally likely that once a person's up to speed in the framework they're efficiency is greatly enhanced.

A programming language isn't just the syntax of the language; there's also knowing the common idioms of the language, understanding the runtime / build environment, knowing when and how to leverage the standard and extended libraries/package ecosystem, etc. Frameworks fall into the "extended package ecosystem" which is vastly different from language to language, and sometimes _within_ a language if the language is sufficiently mature.

Some of it is "just math" and some of it is understanding the culture.

[Tainnor]

Some of the pains with Spring Boot don't go away even when you understand it better. The fact that the framework relies so heavily on reflection makes debugging a pain, turns what should be compile-time errors into runtime errors (which, among other things, makes updating libraries annoying), and also leads to very slow integration tests. I also haven't yet met a developer who fully understands what @Transactional does, exactly.

I agree Spring Boot brings a lot to the table (Spring Security alone, for example), but at the cost of significant downsides.

I see the benefit for larger and more diverse teams, but personally I would choose lighter-weight frameworks and libraries, even if at the cost of having to do more plumbing myself.

[_ea1k]

> I also haven't yet met a developer who fully understands what @Transactional does, exactly.

I have found Spring Boot to be a step forwards from the old Java EE world in basically every way except for this. Transactional boundaries are somehow more difficult to analyze.

[arwineap]

> The fact that the framework relies so heavily on reflection makes debugging a pain, turns what should be compile-time errors into runtime errors

This perfectly explains my problem with the fx library, and why so many java devs seem to gravitate to it

[jimbokun]

> You haven't gotten properly up to speed in that framework and that site's use of the framework.

I've been working in Spring framework for years, and don't understand it. I suspect most of the people who develop it don't understand it either, as it's so enormous it's probably impossible for any one human being to really understand it.

[cduzz]

I'm not trying to defend this or that development environment or framework, just pointing out that there are trade-offs everywhere.

I don't understand speculative execution or any of the other deep voodoo that happens in modern CPUs that spend enormous amounts of energy presenting the "I'm a PDP-11/70 with way more memory and bigger registers" lie to programmers.

These days I'm not even sure which part of my computer is running the networking stack, or where my computer is located.

We stand on towers of abstractions, and complain about the ones we're forced to notice. I don't think many people understand "it" these days.