Don't waste your time - they said.
Use Spring - the good ol' framework - they said
It's not slow - they said

me: ignores them, builds a custom jetty-based webserver with the same functionality Spring+tomcat can offer (mappings, routings, etc).

My app: boots up completely in <300ms, while Spring tutorials say a hello-world app takes 3+ seconds to spin-up http://websystique.com/spring-boot/...

me: already set for deployment in lambda. I bet I can tune it up even further with lazy-loading if I really have to...

Moral of the story: sometimes bare-bones solution is a better choice: more performant, more extendable, more testable, more lightweight.

That, dear folks, is the classic LESS IS MORE :)

Is it open-source? :D

Micronaut, for great justice.

@alexbrooklyn what? Spring? yes :)
My solution? Sorry, that's a nay. I've built it for my client. On the other hand, it took me what, 2-4 hours..?

@SortOfTested that's interesting. Will definitely take a peek there. Thanks.

Similar ish but way less advanced:

I find myself going through projects and digging out misc npm packages and seeing that I'm using like ... tiny amounts of the actual package. Then I just roll that bit my own.

Nothing like replacing Spring, but way more control over what is going on and etc.... and not loading a monstrosity of a package that isn't doing much for me.

Oohh, I can't agree on this one I'm afraid. Well, I agree with not using spring, but can't really agree with rolling your own framework - makes future maintenance a PITA.

The two "ready to go" frameworks for this are generally micronaut and Quarkus. Both offer stupidly fast startup, and out of the box integration with Graal - a Quarkus app I ran for a while with Graal fully started up from cold in around 8ms. Other advantage is they use compile time annotations rather than reflection for autowiring - so that's much, much snappier too.

@netikras
Micronaut tries to address the issue that java really isn't a good fit for modern microservices patterns, and as you mentioned, its spinup time is crap with the more robust frameworks.

@AlmondSauce I see what you mean. And I agree.

However, building a custom solution and avoiding a common [spring's] context gives me the freedom to build perfectly independent modules: from each other and from either of the frameworks. The beauty is that now I can spin my solution up on any framework I choose.

If I built it with Spring from the beginning I'd most likely be married with Spring. If I did it with micronaut - I'd be committed to use that from that point on.

I've been bit by framework-coupling too many times. Building solutions and incorporating them into frameworks afterwards has proven to work best for me.

You might have different xp. Idk. It's just what works best for me :)

yes, yes, you can build more or less isolated components with spring too. But will you? :) I surely won't. Using that comfy autowiring and spring context's ergonomics is just too tempting :) hence the marriage.

@netikras Yeah, I get it. Personally I just pick a framework and stick with it, but that's not everyone's cup of tea.

FWIW, Quarkus in particular can work with a whole variety of annotations (spring-like, or standard Java EE, or others) to mitigate this issue somewhat. Frameworks choosing their own autowiring / bean annotations is a bit of a pig when they're all doing the same thing though. No reason why they couldn't have all standardised around a common base set, adding others if necessary.

@AlmondSauce exactly. I used to try JSR330 @Inject and @Named [at least somewhat closer to the common standard], but, to my surprise, apparently they are not completely supported. Don't recall why/where, but at some point some particular Spring's beans only worked with @Autowired.

Another thing I've found useful - abstract 3rd parties with project-speciffic wrappers. Yes, there's some overhead while coding. But that also saves me from lib-speciffic magic. And I've found that building the wrapper beforehand is easier, than afterwards - that way the framework/lib becomes an extension of your entities, not the other way around. And the coupling is minimal. Which is what I can afford _now_.

As for now, while the project is fresh, a custom solution will do just fine :)

But if you're not including at least 1,100 3rd party dependencies are you even really a programmer?

@kwilliams I guess not.. Even my job title no longer says 'programmer' :/

oh, so thaaaat's why...