Mojolicious (Perl), Spring Boot (Java / Kotlin) or plain Go. Depending on productivity, performance and hardware constrains.
If it's the typical CRUD site I'd use Django (Python) if I worried about finding developers, otherwise sticking to good old Catalyst (Perl) or perhaps giving Phoenix (Elixir) a try.
To be as concise as I can, I would say that Spring Boot is a framework which minimizes the amount of "code" you have to write at the cost of everything else.
And this means that it's hard to understand what is going on under the covers, hard to debug (partly due to metaprogramming bananza), slow to start, uses too much CPU, uses huge amounts of stack, has all bells and whistles turned on by default etc etc.
It gives you all errors at runtime. Encourages you to make your app too configurable (hard to test all configs). Reimplements a bunch of tools and libs badly (like one-jar). Its also intrusive like all frameworks. Requiring a custom test runner is not a feature, Spring! For these type of reasons you cannot easily integrate it with other frameworks.
> "all bells and whistles turned on by default etc"
Arguably a little unfair? Spring boot makes it pretty trivial to just pick and choose the components you need for a project, especially with the https://start.spring.io/ tool.
> Requiring a custom test runner is not a feature, Spring!
I'm guessing this is a reference to using Spring's test runner to support Spring's dependency injection mechanism? No one forces you to use this so it's a stretch to say its 'required', but for certain tests it will save time over manually mocking etc, and often only applies to integration tests anyway. You can absolutely unit test without it.
> "It gives you all errors at runtime."
I'm sure it does, if you have errors.
> "Encourages you to make your app too configurable"
Spring boot apps are only as configurable as you make them, much like any other application. At least Spring tries to provide a standardized methodology/pattern for externalizing configuration parameters. I fail to see the 'encouragement'.
> you cannot easily integrate it with other frameworks.
It's java at the end of the day - there's a ludicrous number of third party frameworks it will play nicely with.
> slow to start, uses too much CPU
Sure JVM applications rarely have 'instant' startup for various reasons, but is a handful of seconds really a problem? 'Uses too much CPU' - I don't really think this is fair either - Spring Boot applications can deliver very efficient solutions.
Not going to argue it's the perfect choice for every project, but no framework is.
Isn't spring boot "thread-per-request"? Some people care about that kind of performance-related stuff.
Also, I think "It gives you all errors at runtime.", should have been "It doesn't give you the errors other frameworks are able to give you at compile time." -and I kind of agree, if memory serves "Spring" is sort of synonymous with "reflection", which isn't exactly performant either.
EDIT: Wow, just read my comment and realized it comes across like I really hate Spring.
I don't, I think it's nice. It's great for web apps that have human users; for services that are consumed by other services, I would probably go for something else.
By default, Spring Boot uses an integrated Tomcat in standalone mode. That Tomcat is configured to use a worker threadpool with a default size of 200. In addition to that you can make Controller methods "asynchronous" (as in free the worker thread as soon as possible) by simply wrapping the methods content in a Callable<T>, which amounts to wrapping it in a lambda method. Calling methods asynchronously is trivial as well, you just need to annotate them with @Async and wrap your result in an AsyncResult<T>.
If you follow the reactive/async/callback/functional cargo cult you can use the brand-new, already usable Spring 5.x spring-webflux. As they describe it: "fully reactive and non-blocking. It is suitable for event-loop style processing with a small number of threads"
If you stick to the script its ok. But the script sucks right?
I prefer dropwizard + libs, always end up googling how to do X with spring boot, where X is a bit off the beaten path
How's Go with web applications that render HTML content? I've had a lot of fun building microservices with JSON REST APIs in Go lately, but I have not done anything that emits HTML. I'm afraid that as soon as you generate HTML, stuff gets messy and you need to include bajillion modules with all this CSS/JS crap.
If what you're trying to achieve is to pump out some
HTML, Go has built-in safe HTML templating. The template syntax isn't glamorous (in fact it can be very unpleasant at times), but with it you can catch type errors at parse time, and the ability to bind custom functions on your templates comes in handy.
Usefully, too, any type that implements the Stringer interface can be dropped into a template and will come out of it as a string without any additional fussing. If your app implements a number of custom types, it's actually possible to get Go templates to look relatively sane.
If it's the typical CRUD site I'd use Django (Python) if I worried about finding developers, otherwise sticking to good old Catalyst (Perl) or perhaps giving Phoenix (Elixir) a try.