10 ms·

I keep reading negativity about spring. I got curious, am building the backend for a new startup with spring boot 3. It’s been a breeze. Everything works, great

I keep reading negativity about spring. I got curious, am building the backend for a new startup with spring boot 3. It’s been a breeze. Everything works, great tooling, very mature software. Am I missing something? Will I regret this in six months?

matwood 3y ago
No. Lots of spring hate is from a decade+ ago. Spring boot plus jOOQ is a very productive backend.
- thegaulofthem 3y ago
  Spring of a decade plus ago was fine, it just required a day or two of upstart to configure the whole deal if you weren’t already familiar and had a good project to reference as a basis for bootstrapping. The tradeoff of today with Spring Boot is you might get bitten down the line with a little configuration mystery, although it’s such a well-blazed path you’re probably in good company and will find your error solved and documented. In addition, it’s Java so virtually any serious task is done in a well-blazed fashion with numerous open-source options available. In contrast my Node library I used to generate and validate an XML document at work last month cannot read in its own XML output. It’s a boon for efficiency. The only downside Java really has is that it’s a bit harder to “hack on” a dynamic, evolving JSON structure so it may be a bad fit for organizational reasons if your company lacks a cohesive, mature Engineering staff.
  - chasd00 3y ago
    my biggest gripe with old Spring was how far you had to go to get "hello world" on the browser when starting from zero. I never would have thought embedding the whole application server would be a good idea but SpringBoot proved me wrong. That plus the annotation based config vs xml files is what made fast development with Spring possible (in my mind). Also, Spring would be a miserable experience if it were not for Maven/Gradle. Have you ever counted the jar files included in a typical SpringBoot+Spring-Security+Spring-Data app?
    - lmm 3y ago
      > my biggest gripe with old Spring was how far you had to go to get "hello world" on the browser when starting from zero. I never would have thought embedding the whole application server would be a good idea but SpringBoot proved me wrong. That plus the annotation based config vs xml files is what made fast development with Spring possible (in my mind). All of this is long before Spring Boot. Embedding the web server so that your system is just a plain Java application is a great idea; annotation based config is a great idea; both of those are things you could do (and I did do) back in 2010 on Spring 3.3. The stuff that Spring Boot adds - the spooky-action-at-a-distance classpath scanning, the we-can-use-them-but-you-can't annotations, the way you can't override part of an autoconfig but have to either accept what the library gives you or write a full config from scratch - is a big mistake. Those who forget Java EE are doomed to repeat it I guess. > Also, Spring would be a miserable experience if it were not for Maven/Gradle. Sure. "Have dependency management that doesn't suck" is good advice for any software ecosystem.
  - matwood 3y ago
    I think older spring was fine, but many people complain about xml configuration as a big one. And, like you said, it took time to setup. Spring Boot today with modern Java is a really nice backend environment to work in.
oweiler 3y ago
You won't regret it. Huge community, great docs, good enough performance, great testability. Integrations for everything. It's boring tech, which is a good thing IMHO.
_2z1p 3y ago
I think that’s the source of negativity for the HN crowd. It’s boring, predictable, mature enterprise grade software that quietly gets the job done. It’s too similar to what they are forced to work with in $DAYJOB, instead of the exotic, fun frameworks they’d rather be playing with that you always read about here.
- hdjjhhvvhga 3y ago
  Well, not exactly. HTMX, for example, is plain, simple, boring - everything but exciting. But people here love it. Why? Because they don't have to deal with overcomplicated crap for no reason.
  - syspec 3y ago
    It's new
    - hdjjhhvvhga 3y ago
      Not that much - it's previous incarnation (intercooler) is almost 10 years old.
ojhughes 3y ago
Spring Boot is very productive but things can get very hairy when debugging auto configuration or understanding why a bean is missing from the context. Running Boot in a container is also not great due to the memory requirements needed for bootstrap (min 0.5 Gi). I know GraalVm makes this better but compile times are still too painful. I also think the push to make Reactor the default choice was a mistake (deprecating RestTemplate). The reactive model in Java feels unnatural and it can be very hard to debug. I am working with Go now and don’t miss Spring Boot that much but it still has a place in my heart for the amazing community and docs.
- gabereiser 3y ago
  Spring and the JVM (even modularized) is a huge sore for cloud ops due to container size. Great that you pointed that out. Go's chi router or Fiber along with gorm gets us not so far away if you're doing crud. I also love go's ability to bundle assets into the binary and serve them (front-end code). It's so good that if I want to run the entire web application on another machine, I just copy the binary and run. Docker memory requirements are in the 64m range and even that is probably a bit of overkill. I can run thousands of these on a raspberry pi 4. I can only run like 4 spring boot apps on it.
- haarolean 3y ago
  Which stack/frameworks in Go would you recommend to achieve a somewhat close developing experience? AFAIK the default library doesn't have much and there are no huge frameworks like Spring.
pjmlp 3y ago
Usually HN culture with their Python and Ruby stuff. I wouldn't change Jakarta EE, Spring, ASP.NET for framework of the day, with a subset of functionality and molass performance, unless told otherwise by customer architect.
ninjazee124 3y ago
I have been building with Spring for over a decade. You won't regret it. It's just stable, and works and something you use to build things that last.
cogman10 3y ago
You will not, it's a fine choice for a software stack. There have been startup time problems, which Spring has been doing an excellent job of addressing. There's also been some silly performance problems which afaik have been addressed. We personally use Quarkus and it's also pretty good. I think the Quarkus story has driven spring towards having a better story and both are pretty excellent stacks to go with.
gloryjulio 3y ago
Spring is old. The negativity comes from the the time where ppl would jump to Rails or Django instead of dealing with the config explosion/unnecessary complexities for startups/verbosity of the java at the time. Now, we have modern java + simpflified saner default named spring boot, that's a different story
- cogman10 3y ago
  Spring boot has driven spring to be a lot simpler as well. Further other frameworks like Micronaut and Quarkus have driven spring boot to be better. There's been some real symbiosis among the backend frameworks that has caused them all to lift in quality.
- Alupis 3y ago
  Kotlin + Spring/Boot is an amazing combination for backend work. The Spring/Boot Team have poured a lot of energy into making it very graceful to use.
topspin 3y ago
> Will I regret this in six months? Only if you plan to collect kudos with it on HN. Otherwise you'll be fine.
vbezhenar 3y ago
Spring is too automagical, often breaks with new releases, eats incredible amounts of memory, requires too much time to deal with its problems, produces stacktraces longer than my program. It's terrible, honestly.
mdaniel 3y ago
To add to the sibling comments, you'll also enjoy the monster amount of introspection made available in the combination of the JVM and JMX exposed via the Spring actuator endpoints. We regularly adjust logging levels of running pods in order to sniff out errant behavior versus bouncing them to fiddle with some log level. I have yet to play with a software stack that is designed for as much in-flight tuning as Spring on the JVM Don't overlook @ConfigurationProperties <https://docs.spring.io/spring-boot/docs/3.1.1/reference/html/features.html#features.external-config.typesafe-configuration-properties https://docs.spring.io/spring-boot/docs/3.1.1/reference/html...> as a way of strongly typing any configuration knobs that your application may require. That not only allows static typing to avoid the hazardous @Value("some.vaule.oops") but it also means that IJ will tab complete (with typechecks) in your application.{properties,json,yaml,whatever}
switchbak 3y ago
Despite the all-in opinion in this particular thread, my take is a little more nuanced. The modern versions of Spring are a breath of fresh air (no pun) compared to the older ones. It still does have a bit of a kitchen sink feel when you build something non-trivial, and some of the magic of the boot approach can become hard to reason about. You may prefer a simpler worldview of an alternative runtime, and you can also benefit from shorter compiles/quicker startup, etc. That said, the downsides aren't really that bad. It's got a strong community, will obviously still be around in 5 years, and the JVM is seeing strong investment and modernization. All in all, it'd be a strong contender if I was putting my money on the line. I'm still a fan of the simplest-thing-that-can-work approach (in the old days it was Jetty + Guice + whatever else you wanted), but modern Spring isn't all that far off from the experience anymore.
chasd00 3y ago
one nit pick, Spring is more than Spring Boot although when people say "Spring" they're likely talking about Spring Boot. You won't regret using it in 6 months except maybe for the fact that your backend will be just working and doing its thing and there's not really much else to do except watch it work.
nick__m 3y ago
Spring before spring-boot was an unreadable sea of unique xml. Spring-boot is a guardrail that steers you into the correct usage of the spring framework. spring => configuration over conventions spring-boot => conventions over configuration
- gabereiser 3y ago
  Mostly agree with this, the issue was that Spring Framework 3 introduced a new way of doing configuration with the @Configuration annotation. Up until then it was all xml driven (some minor packages like spring-integration still required it) bean soup. The advent of the annotation driven configuration paved way for spring-boot to provide sane defaults to the framework (previously reserved for certified spring framework engineers like myself to define in xml that we copied time and time again). You nailed it though with Spring being configuration over convention and Spring Boot being the opposite. At the time, there was a competing web framework that was really simple to build with called Rails that made the mindset shift to ease-of-use from a dev standpoint away from ease-of-use from an ops standpoint.
- jonhohle 3y ago
  I disagree but know I’m in the minority. I would take Spring config XML over the tightly coupled mess of Spring config annotations and code. Circa 2006, Spring config was about binding decoupled POJOs together and code didn’t require any build time dependency on Spring. Now Spring is required at build time and objects expect to be instantiated as beans, and unit tests either require a minimal spring context or some other method of injecting dependencies that would have otherwise existed as a constructor arg or mutator anyway. Now “config” is fully Turing complete as opposed to declarative. Yuck! I’m no fan of XML, but config as code is no longer config, imho.
  - vbezhenar 3y ago
    I liked original Spring idea of being actually non-invasive framework as well and I never had any issues with Spring XML config. It worked for me and Idea has decent autocomplete for it. There was time when Spring was considered lightweight. Oh, well. Spring Boot is when it all went downhill.
reactordev 3y ago
No, you won't. People who gripe about spring didn't bother to do things the spring way. If you wrote your own DAL, you did it wrong. JpaRepositories and the like are the way. If you wrote your own JSON serializer/deserializer you did it wrong, Spring includes Jackson and will do it for you (YMMV). If you rolled your own authentication, you did it wrong. Spring Security can magically lock down your app with as little as a single configuration method, providing jwt/oauth/openid-connect enterprise security out of the box. The issue with spring boot is not it's feature-set or it's robustness. It's with it's heavy handedness to force you down the "spring way". Annotation driven. Extending provided interfaces. Making it "sticky" and impossible to remove. Want to introduce gRPC? yeah, you're going to have to find a way to weave that into Netty or use a different port. It's robust enough just up unto a point where you hit a roadblock and have to dig deep deep into Spring land to understand whats going on. It's still the best framework for standard crud web api's and such with Java. Though micronauts is quickly approaching. You can't go wrong choosing spring boot in 2023 if your intention is to ship in 2024. Whether or not that codebase is solid in 2027 is another matter.
- yAak 3y ago
  Sorta random, but I really appreciate this kind of post on HN. People have tons of domain expertise and hard-earned lessons that get shared like this, and it broadens my awareness without requiring any time investment on my part. Thank you, thank you (and others like you) for taking the time to type this up!
  - gabereiser 3y ago
    I’m shocked actually that you don’t get this kind of mentorship where you work. What’s your Director doing? Not that we’ll be building spring apps but knowing where we, as an industry, have came from and tried things, we’ll avoid them in the future. My heart sinks when a good idea on paper, but bad IRL, get reimplemented 10 years later because someone didn’t bother to read history. That said, sometimes time is all you need for tech to catch up. Rarely that’s the case though. So yeah, you’re welcome, thanks for coming to my grey beard tech talk. Ask your managers for more brown bag/lunch & learns from the older folks at your company - they have stories.
paulddraper 3y ago
> Am I missing something? There's a huge difference between "Spring pre-Boot" and "Spring post-Boot." Not quite as significant as Angular 1 vs Angular 2, but close.
lfmunoz4 3y ago
In six months no but in 1-2 years yes. Spring has large tentacles so that when you start using it all code is coupled to Spring Boot and it's dependencies. I.e, the code you write is useless without Spring Boot, it is difficult to separate your code from Spring Boot. Now when technology changes you will have major refactor work i.e, like when Spring Boot moved from Dropwizard to Micrometer. It is possible to mitigate but takes advanced skills.
time4tea 3y ago
If you drink the kool-aid, you'll love it. It's a tricky question to get a real answer, due to all the vested interests, lack of real research, and differing views of "what is good" Which is better, Amiga or ST (Amiga!)
- snvzz 3y ago
  Yep, Amiga.
AtlasBarfed 3y ago
Spring is very good software, and basically and object oriented language will need to use stuff like it after enterprises throw their stack of requirements at it for 20+ years and following 20 years of technology evolution. Yes its been tied to many java architectural fashion boondoggles of the past (XML config madness, XML namespace magic, overly heavyweight serverside HTML rendering, JSP tag madness, software patterns) but I still turn to it for basic code structuring in any JVM app. Boot is pretty good ... until its not. If you are doing garden variety web services it gets you up and running fairly well. If you need to do anything fancy with routing or raw data in the html request/response, then it is not. And Spring is now so synonymous with Spring Boot that it kind of isn't a good thing. Spring also isn't a pure open source project, it has a company trying to constantly steer it to revenue production, but as those types of entities go, stewardship has been decent. Normally things like that have about four or five years of trying to use open source for market expansion before impatience/greed/frustration sits in and they go for the closed source grab (see: Hashicorp recently). 20 years is a remarkable run for something like that.
mongol 3y ago
A stacktrace in a Spring app can be painful to see. Tons of Spring code inbetween layers of your own app. Sometimes it has made me wonder, what happened with just plain old method invocations? Granted, it can probable be helpful in many ways, but it comes at a price. But I think improvements in developer tooling will make annotation-driven programming unmodern. I see a renaissance coming for plain old programming.
- DonHopkins 3y ago
  "Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back https://twitter.com/9600/status/90729345307521024 https://twitter.com/9600/status/90729345307521024
  - mongol 3y ago
    Yeah, I think that is actually pretty insightful. But although that is what it has been it may not neccessarily be what comes next. I imagine developer copilots to take care of the mundande coding you would need to do without frameworks like Spring and basically make them unneccessary to a large extent. Instead you will have leaner apps, but with a larger proportion custom code, and less use of dependencies.
- yCombLinks 3y ago
  Spring does generate some giant stacktraces, but if you have all of your code in a unique package structure (like com.mongol) just jump through your own code by searching that name.
ecshafer 3y ago
You probably won't regret it, Spring is a solid framework. But the issue with Spring in my experience is that it has constant breaking upgrades with various dependencies But this is more of an enterprise issue. Upgrade breaks a dependency, fixing that dependency will break another dependency, etc. While some people say Spring Boot is convention over configuration, I don't really buy that, the configuration is done via annotations which is still configuration. My other gripe with Spring is that despite it all being annotations, when it breaks it can be opaque about why it broke, or why it didn't bind something.
- derefr 3y ago
  > Upgrade breaks a dependency, fixing that dependency will break another dependency, etc. If you just upgrade all your spring-related dependencies to latest-of-same-major-version every time you upgrade, on average how much does your own code end up breaking?
  - ecshafer 3y ago
    In that light pretty rarely. Which I suppose is a point in favor of Spring. When spring's dependencies break you usually can't even run the server.
eweef3334 3y ago
I thought the same thing 20 years ago. Still using spring. It's not a panacea, but compared to other technologies which came and went, it's been a great investment. The same could be said for Java, linux, python, bash, vi.
willsmith72 3y ago
For a new full stack project I'd use a full stack JavaScript framework, but spring boot is still awesome. Especially so when slow starts and higher resource consumption aren't as important as developer productivity, testability, reliability (which is pretty often).
- nprateem 3y ago
  But which one? Next.js, sveltekit, etc. are tied to frontend frameworks. Nest.js seems good, but basically Spring Boot in JS. A lot of JS devs seem to want more FRP based patterns (unless they like Angular), and the rest are just small frameworks that'll be difficult to hire for. Have I missed any? I want something fullstack and so more structured than just Express.
misja111 3y ago
It's like you say, Spring Boot can get you from nothing to a production ready application in no time, it is reliable and the community support and documentation is great. It is also pretty flexible, up to a certain limit. If your product happens to be something serving a zillion requests per second, using some exotic protocol, or doing some wildly complex calculations, then Spring might not be be the best choice. And it just so happens that the HN community's primary interest goes out to these rare exceptions and not to the 99% other projects in the real world.
yallpendantools 3y ago
Let me throw-in my 2c worth. I started my career in consulting with an in-house but Spring-inspired framework. I hated it, turned to other jobs that used other tech stacks; nowadays I largely consider myself a Pythonista. Lately, after about a decade from that first gig, I've finally decided to learn Spring properly and I've made good progress with it. Mind you, I decided to do so only because it seems like a good career move to know Spring in this economy. So, my honest evaluation: learning Spring is frustrating and not an enjoyable experience at all. Just the sheer verbosity of things hurts my Pythonista soul. It's not just that Java is inherently more verbose than Python, it's just that "the Spring way" forces you to create three classes with little to no shortcuts around it; even the most opinionated Python/Node frameworks I've encountered wouldn't be that draconian. Coming from Python/Node/PHP/serverless, the framework's philosophy seems incomprehensibly monolithic. All the layers of abstraction (and their resulting stack traces) make for an extremely confusing debugging experience especially for noobs. *BUT*, I admit, judging a technology for its learning curve is not fair. I just had to vent my honest opinion on the experience. I'm now at that point where I think I've grokked "the Spring way". That is, my Google searches on how to do X in Spring/troubleshoot a problem are smarter now. I've actually grown to appreciate it. (I'm pretty sure the Spring Gods would make me pay for the sheer hubris of this statement and will make me eat my words in the next feature I come up with in my side project.) JpaRepositories are powerful magic. If Spring has any advantage over the frameworks I've come to love, it's this. JpaRepositories compensate for what Spring/Java lacks in brevity. Oh, also, not a Spring-specific advice but Lambdas and method references have made Java easier to write and has definitely deflated the number of classes I've had to create otherwise. Some would say that's just lipstick on a pig but I prefer to see it as an oasis in a desert. Lastly, don't take this as advice for the backend you are building for a new start-up but I really see Spring's strength in that consulting CRUD-software market. If I can define specs in a legally-binding contract before writing a single line of code, if I can bang out a schema at the start of development and not worry about migrations, I would actually choose Spring. All the "corporate-rep" of Java won't hurt for these types of projects either. But on the other hand, for environments where I need a lot of flexibility and lack the leisure of time almost always, I feel like Spring would be a development death march. Misc notes: 1. I'm not actually learning vanilla Spring. I'm using Spring Boot alongside Vaadin. Overtime I've come to distinguish better between the two but maybe some percent of my frustrations in the learning phase is on Vaadin, not really Spring. 2. I made extensive use of ChatGPT in learning Spring. Even for such a boring/common tech, it's hilarious what ChatGPT gets wrong. But it also gets things right, giving advice in a level of clarity that blog posts and SO posts couldn't have provided. I would recommend anyone trying to learn Spring (or maybe any other framework/technology) to give ChatGPT a shot too. Even when it gets things wrong, the feedback loop that resembles actually talking to someone helps with the rubber ducking. Again, all 2c worth of opinions from someone not even a year in this framework. Caveat lector!
coderoffortune 3y ago
Don't worry, all negativity comes from those miserable Go devs.
m_0x 3y ago
The negativism towards has two main points: First, that Spring it's bloated. Spring now has a wide extension of modules that you may or may not need. Most of those modules won't even be added in your classpath unless specified in your pom.xml or build.gradle file. Very simple projects won't need the vast majority of the full Spring power. Second, that a Spring project takes too much time to launch the web app (Compared against other frameworks doing the same task). Part of the reason it takes too much time to start comes from how the engine inflates the beans and injects it. On that same topic, other frameworks such as Micronaut are more lightweight because they don't bloat the framework as much as spring, thus the launch time is shorter. Also take into account that Java developers adore complexity in code structure so that also affects launch time. Are you going to regret going with Spring? No, there is a lot of support from the community, if you have any issue you will find help in reddit and stackoverflow. It's a really mature framework. However it's not the only option. There are other frameworks that could be a better choice for your use cases.
lmm 3y ago
> Am I missing something? Will I regret this in six months? Yes. One day you'll add another dependency to your classpath and your application will magically be doing something you didn't want or need. And the way to turn it off will be an undocumented annotation that only exists in the next version of spring boot, so you'll upgrade to that, and then a whole bunch of other stuff will break.
itpragmatik 3y ago
Java 17, Hibernate, JPA, Spring Boot - all the way! Excellent combo! Reliable, high developer productivity, excellent community support, stable - have been using it for more than 8+ years now and won't think of using any other framework if I am going to build something in Java. Very easy to design, build, deploy, troubleshoot, maintain REST API Services! You won't go wrong at all if you choose Spring Boot.
moribvndvs 3y ago
The bulk of my full stack experience has been dotnet. But for the past 5 years I’ve moved into Java and Spring. I’m not a big fan of the JVM, but it works. However, Kotlin + Spring Boot is pretty fucking incredible. 1.x is kind of a pain in the ass, but 2 and 3 really blow me away at how well things integrate when you go with convention. The major gripes I have is that _up-to-date_ documentation on the best ways compose a modern app using several modules where you aren’t fighting the tools. Official module docs tend to breeze over stuff. I can’t tell you how much time I’ve wasted rolling my own ____ and fighting against autoconfig then finding there’s a simple but poorly documented way of doing what I need. But even with that frustration, I feel like I’m able to launch projects faster using Spring Boot than dotnet.

matwood 3y ago

No. Lots of spring hate is from a decade+ ago. Spring boot plus jOOQ is a very productive backend.

thegaulofthem 3y ago
Spring of a decade plus ago was fine, it just required a day or two of upstart to configure the whole deal if you weren’t already familiar and had a good project to reference as a basis for bootstrapping. The tradeoff of today with Spring Boot is you might get bitten down the line with a little configuration mystery, although it’s such a well-blazed path you’re probably in good company and will find your error solved and documented. In addition, it’s Java so virtually any serious task is done in a well-blazed fashion with numerous open-source options available. In contrast my Node library I used to generate and validate an XML document at work last month cannot read in its own XML output. It’s a boon for efficiency. The only downside Java really has is that it’s a bit harder to “hack on” a dynamic, evolving JSON structure so it may be a bad fit for organizational reasons if your company lacks a cohesive, mature Engineering staff.
- chasd00 3y ago
  my biggest gripe with old Spring was how far you had to go to get "hello world" on the browser when starting from zero. I never would have thought embedding the whole application server would be a good idea but SpringBoot proved me wrong. That plus the annotation based config vs xml files is what made fast development with Spring possible (in my mind). Also, Spring would be a miserable experience if it were not for Maven/Gradle. Have you ever counted the jar files included in a typical SpringBoot+Spring-Security+Spring-Data app?
  - lmm 3y ago
    > my biggest gripe with old Spring was how far you had to go to get "hello world" on the browser when starting from zero. I never would have thought embedding the whole application server would be a good idea but SpringBoot proved me wrong. That plus the annotation based config vs xml files is what made fast development with Spring possible (in my mind). All of this is long before Spring Boot. Embedding the web server so that your system is just a plain Java application is a great idea; annotation based config is a great idea; both of those are things you could do (and I did do) back in 2010 on Spring 3.3. The stuff that Spring Boot adds - the spooky-action-at-a-distance classpath scanning, the we-can-use-them-but-you-can't annotations, the way you can't override part of an autoconfig but have to either accept what the library gives you or write a full config from scratch - is a big mistake. Those who forget Java EE are doomed to repeat it I guess. > Also, Spring would be a miserable experience if it were not for Maven/Gradle. Sure. "Have dependency management that doesn't suck" is good advice for any software ecosystem.
- matwood 3y ago
  I think older spring was fine, but many people complain about xml configuration as a big one. And, like you said, it took time to setup. Spring Boot today with modern Java is a really nice backend environment to work in.

oweiler 3y ago

You won't regret it. Huge community, great docs, good enough performance, great testability. Integrations for everything. It's boring tech, which is a good thing IMHO.

_2z1p 3y ago

I think that’s the source of negativity for the HN crowd. It’s boring, predictable, mature enterprise grade software that quietly gets the job done. It’s too similar to what they are forced to work with in $DAYJOB, instead of the exotic, fun frameworks they’d rather be playing with that you always read about here.

hdjjhhvvhga 3y ago
Well, not exactly. HTMX, for example, is plain, simple, boring - everything but exciting. But people here love it. Why? Because they don't have to deal with overcomplicated crap for no reason.
- syspec 3y ago
  It's new
  - hdjjhhvvhga 3y ago
    Not that much - it's previous incarnation (intercooler) is almost 10 years old.

ojhughes 3y ago

Spring Boot is very productive but things can get very hairy when debugging auto configuration or understanding why a bean is missing from the context. Running Boot in a container is also not great due to the memory requirements needed for bootstrap (min 0.5 Gi). I know GraalVm makes this better but compile times are still too painful. I also think the push to make Reactor the default choice was a mistake (deprecating RestTemplate). The reactive model in Java feels unnatural and it can be very hard to debug. I am working with Go now and don’t miss Spring Boot that much but it still has a place in my heart for the amazing community and docs.

gabereiser 3y ago
Spring and the JVM (even modularized) is a huge sore for cloud ops due to container size. Great that you pointed that out. Go's chi router or Fiber along with gorm gets us not so far away if you're doing crud. I also love go's ability to bundle assets into the binary and serve them (front-end code). It's so good that if I want to run the entire web application on another machine, I just copy the binary and run. Docker memory requirements are in the 64m range and even that is probably a bit of overkill. I can run thousands of these on a raspberry pi 4. I can only run like 4 spring boot apps on it.
haarolean 3y ago
Which stack/frameworks in Go would you recommend to achieve a somewhat close developing experience? AFAIK the default library doesn't have much and there are no huge frameworks like Spring.

pjmlp 3y ago

Usually HN culture with their Python and Ruby stuff. I wouldn't change Jakarta EE, Spring, ASP.NET for framework of the day, with a subset of functionality and molass performance, unless told otherwise by customer architect.

ninjazee124 3y ago

I have been building with Spring for over a decade. You won't regret it. It's just stable, and works and something you use to build things that last.

cogman10 3y ago

You will not, it's a fine choice for a software stack. There have been startup time problems, which Spring has been doing an excellent job of addressing. There's also been some silly performance problems which afaik have been addressed. We personally use Quarkus and it's also pretty good. I think the Quarkus story has driven spring towards having a better story and both are pretty excellent stacks to go with.

gloryjulio 3y ago

Spring is old. The negativity comes from the the time where ppl would jump to Rails or Django instead of dealing with the config explosion/unnecessary complexities for startups/verbosity of the java at the time. Now, we have modern java + simpflified saner default named spring boot, that's a different story

cogman10 3y ago
Spring boot has driven spring to be a lot simpler as well. Further other frameworks like Micronaut and Quarkus have driven spring boot to be better. There's been some real symbiosis among the backend frameworks that has caused them all to lift in quality.
Alupis 3y ago
Kotlin + Spring/Boot is an amazing combination for backend work. The Spring/Boot Team have poured a lot of energy into making it very graceful to use.

topspin 3y ago

> Will I regret this in six months? Only if you plan to collect kudos with it on HN. Otherwise you'll be fine.

vbezhenar 3y ago

Spring is too automagical, often breaks with new releases, eats incredible amounts of memory, requires too much time to deal with its problems, produces stacktraces longer than my program. It's terrible, honestly.

mdaniel 3y ago

To add to the sibling comments, you'll also enjoy the monster amount of introspection made available in the combination of the JVM and JMX exposed via the Spring actuator endpoints. We regularly adjust logging levels of running pods in order to sniff out errant behavior versus bouncing them to fiddle with some log level. I have yet to play with a software stack that is designed for as much in-flight tuning as Spring on the JVM Don't overlook @ConfigurationProperties <https://docs.spring.io/spring-boot/docs/3.1.1/reference/html/features.html#features.external-config.typesafe-configuration-properties https://docs.spring.io/spring-boot/docs/3.1.1/reference/html...> as a way of strongly typing any configuration knobs that your application may require. That not only allows static typing to avoid the hazardous @Value("some.vaule.oops") but it also means that IJ will tab complete (with typechecks) in your application.{properties,json,yaml,whatever}

switchbak 3y ago

Despite the all-in opinion in this particular thread, my take is a little more nuanced. The modern versions of Spring are a breath of fresh air (no pun) compared to the older ones. It still does have a bit of a kitchen sink feel when you build something non-trivial, and some of the magic of the boot approach can become hard to reason about. You may prefer a simpler worldview of an alternative runtime, and you can also benefit from shorter compiles/quicker startup, etc. That said, the downsides aren't really that bad. It's got a strong community, will obviously still be around in 5 years, and the JVM is seeing strong investment and modernization. All in all, it'd be a strong contender if I was putting my money on the line. I'm still a fan of the simplest-thing-that-can-work approach (in the old days it was Jetty + Guice + whatever else you wanted), but modern Spring isn't all that far off from the experience anymore.

chasd00 3y ago

one nit pick, Spring is more than Spring Boot although when people say "Spring" they're likely talking about Spring Boot. You won't regret using it in 6 months except maybe for the fact that your backend will be just working and doing its thing and there's not really much else to do except watch it work.

nick__m 3y ago

Spring before spring-boot was an unreadable sea of unique xml. Spring-boot is a guardrail that steers you into the correct usage of the spring framework. spring => configuration over conventions spring-boot => conventions over configuration

gabereiser 3y ago
Mostly agree with this, the issue was that Spring Framework 3 introduced a new way of doing configuration with the @Configuration annotation. Up until then it was all xml driven (some minor packages like spring-integration still required it) bean soup. The advent of the annotation driven configuration paved way for spring-boot to provide sane defaults to the framework (previously reserved for certified spring framework engineers like myself to define in xml that we copied time and time again). You nailed it though with Spring being configuration over convention and Spring Boot being the opposite. At the time, there was a competing web framework that was really simple to build with called Rails that made the mindset shift to ease-of-use from a dev standpoint away from ease-of-use from an ops standpoint.
jonhohle 3y ago
I disagree but know I’m in the minority. I would take Spring config XML over the tightly coupled mess of Spring config annotations and code. Circa 2006, Spring config was about binding decoupled POJOs together and code didn’t require any build time dependency on Spring. Now Spring is required at build time and objects expect to be instantiated as beans, and unit tests either require a minimal spring context or some other method of injecting dependencies that would have otherwise existed as a constructor arg or mutator anyway. Now “config” is fully Turing complete as opposed to declarative. Yuck! I’m no fan of XML, but config as code is no longer config, imho.
- vbezhenar 3y ago
  I liked original Spring idea of being actually non-invasive framework as well and I never had any issues with Spring XML config. It worked for me and Idea has decent autocomplete for it. There was time when Spring was considered lightweight. Oh, well. Spring Boot is when it all went downhill.

reactordev 3y ago

No, you won't. People who gripe about spring didn't bother to do things the spring way. If you wrote your own DAL, you did it wrong. JpaRepositories and the like are the way. If you wrote your own JSON serializer/deserializer you did it wrong, Spring includes Jackson and will do it for you (YMMV). If you rolled your own authentication, you did it wrong. Spring Security can magically lock down your app with as little as a single configuration method, providing jwt/oauth/openid-connect enterprise security out of the box. The issue with spring boot is not it's feature-set or it's robustness. It's with it's heavy handedness to force you down the "spring way". Annotation driven. Extending provided interfaces. Making it "sticky" and impossible to remove. Want to introduce gRPC? yeah, you're going to have to find a way to weave that into Netty or use a different port. It's robust enough just up unto a point where you hit a roadblock and have to dig deep deep into Spring land to understand whats going on. It's still the best framework for standard crud web api's and such with Java. Though micronauts is quickly approaching. You can't go wrong choosing spring boot in 2023 if your intention is to ship in 2024. Whether or not that codebase is solid in 2027 is another matter.

yAak 3y ago
Sorta random, but I really appreciate this kind of post on HN. People have tons of domain expertise and hard-earned lessons that get shared like this, and it broadens my awareness without requiring any time investment on my part. Thank you, thank you (and others like you) for taking the time to type this up!
- gabereiser 3y ago
  I’m shocked actually that you don’t get this kind of mentorship where you work. What’s your Director doing? Not that we’ll be building spring apps but knowing where we, as an industry, have came from and tried things, we’ll avoid them in the future. My heart sinks when a good idea on paper, but bad IRL, get reimplemented 10 years later because someone didn’t bother to read history. That said, sometimes time is all you need for tech to catch up. Rarely that’s the case though. So yeah, you’re welcome, thanks for coming to my grey beard tech talk. Ask your managers for more brown bag/lunch & learns from the older folks at your company - they have stories.

paulddraper 3y ago

> Am I missing something? There's a huge difference between "Spring pre-Boot" and "Spring post-Boot." Not quite as significant as Angular 1 vs Angular 2, but close.

lfmunoz4 3y ago

In six months no but in 1-2 years yes. Spring has large tentacles so that when you start using it all code is coupled to Spring Boot and it's dependencies. I.e, the code you write is useless without Spring Boot, it is difficult to separate your code from Spring Boot. Now when technology changes you will have major refactor work i.e, like when Spring Boot moved from Dropwizard to Micrometer. It is possible to mitigate but takes advanced skills.

time4tea 3y ago

If you drink the kool-aid, you'll love it. It's a tricky question to get a real answer, due to all the vested interests, lack of real research, and differing views of "what is good" Which is better, Amiga or ST (Amiga!)

snvzz 3y ago
Yep, Amiga.

AtlasBarfed 3y ago

Spring is very good software, and basically and object oriented language will need to use stuff like it after enterprises throw their stack of requirements at it for 20+ years and following 20 years of technology evolution. Yes its been tied to many java architectural fashion boondoggles of the past (XML config madness, XML namespace magic, overly heavyweight serverside HTML rendering, JSP tag madness, software patterns) but I still turn to it for basic code structuring in any JVM app. Boot is pretty good ... until its not. If you are doing garden variety web services it gets you up and running fairly well. If you need to do anything fancy with routing or raw data in the html request/response, then it is not. And Spring is now so synonymous with Spring Boot that it kind of isn't a good thing. Spring also isn't a pure open source project, it has a company trying to constantly steer it to revenue production, but as those types of entities go, stewardship has been decent. Normally things like that have about four or five years of trying to use open source for market expansion before impatience/greed/frustration sits in and they go for the closed source grab (see: Hashicorp recently). 20 years is a remarkable run for something like that.

mongol 3y ago

A stacktrace in a Spring app can be painful to see. Tons of Spring code inbetween layers of your own app. Sometimes it has made me wonder, what happened with just plain old method invocations? Granted, it can probable be helpful in many ways, but it comes at a price. But I think improvements in developer tooling will make annotation-driven programming unmodern. I see a renaissance coming for plain old programming.

DonHopkins 3y ago
"Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back https://twitter.com/9600/status/90729345307521024 https://twitter.com/9600/status/90729345307521024
- mongol 3y ago
  Yeah, I think that is actually pretty insightful. But although that is what it has been it may not neccessarily be what comes next. I imagine developer copilots to take care of the mundande coding you would need to do without frameworks like Spring and basically make them unneccessary to a large extent. Instead you will have leaner apps, but with a larger proportion custom code, and less use of dependencies.
yCombLinks 3y ago
Spring does generate some giant stacktraces, but if you have all of your code in a unique package structure (like com.mongol) just jump through your own code by searching that name.

ecshafer 3y ago

You probably won't regret it, Spring is a solid framework. But the issue with Spring in my experience is that it has constant breaking upgrades with various dependencies But this is more of an enterprise issue. Upgrade breaks a dependency, fixing that dependency will break another dependency, etc. While some people say Spring Boot is convention over configuration, I don't really buy that, the configuration is done via annotations which is still configuration. My other gripe with Spring is that despite it all being annotations, when it breaks it can be opaque about why it broke, or why it didn't bind something.

derefr 3y ago
> Upgrade breaks a dependency, fixing that dependency will break another dependency, etc. If you just upgrade all your spring-related dependencies to latest-of-same-major-version every time you upgrade, on average how much does your own code end up breaking?
- ecshafer 3y ago
  In that light pretty rarely. Which I suppose is a point in favor of Spring. When spring's dependencies break you usually can't even run the server.

eweef3334 3y ago

I thought the same thing 20 years ago. Still using spring. It's not a panacea, but compared to other technologies which came and went, it's been a great investment. The same could be said for Java, linux, python, bash, vi.

willsmith72 3y ago

For a new full stack project I'd use a full stack JavaScript framework, but spring boot is still awesome. Especially so when slow starts and higher resource consumption aren't as important as developer productivity, testability, reliability (which is pretty often).

nprateem 3y ago
But which one? Next.js, sveltekit, etc. are tied to frontend frameworks. Nest.js seems good, but basically Spring Boot in JS. A lot of JS devs seem to want more FRP based patterns (unless they like Angular), and the rest are just small frameworks that'll be difficult to hire for. Have I missed any? I want something fullstack and so more structured than just Express.

misja111 3y ago

It's like you say, Spring Boot can get you from nothing to a production ready application in no time, it is reliable and the community support and documentation is great. It is also pretty flexible, up to a certain limit. If your product happens to be something serving a zillion requests per second, using some exotic protocol, or doing some wildly complex calculations, then Spring might not be be the best choice. And it just so happens that the HN community's primary interest goes out to these rare exceptions and not to the 99% other projects in the real world.

yallpendantools 3y ago

Let me throw-in my 2c worth. I started my career in consulting with an in-house but Spring-inspired framework. I hated it, turned to other jobs that used other tech stacks; nowadays I largely consider myself a Pythonista. Lately, after about a decade from that first gig, I've finally decided to learn Spring properly and I've made good progress with it. Mind you, I decided to do so only because it seems like a good career move to know Spring in this economy. So, my honest evaluation: learning Spring is frustrating and not an enjoyable experience at all. Just the sheer verbosity of things hurts my Pythonista soul. It's not just that Java is inherently more verbose than Python, it's just that "the Spring way" forces you to create three classes with little to no shortcuts around it; even the most opinionated Python/Node frameworks I've encountered wouldn't be that draconian. Coming from Python/Node/PHP/serverless, the framework's philosophy seems incomprehensibly monolithic. All the layers of abstraction (and their resulting stack traces) make for an extremely confusing debugging experience especially for noobs. *BUT*, I admit, judging a technology for its learning curve is not fair. I just had to vent my honest opinion on the experience. I'm now at that point where I think I've grokked "the Spring way". That is, my Google searches on how to do X in Spring/troubleshoot a problem are smarter now. I've actually grown to appreciate it. (I'm pretty sure the Spring Gods would make me pay for the sheer hubris of this statement and will make me eat my words in the next feature I come up with in my side project.) JpaRepositories are powerful magic. If Spring has any advantage over the frameworks I've come to love, it's this. JpaRepositories compensate for what Spring/Java lacks in brevity. Oh, also, not a Spring-specific advice but Lambdas and method references have made Java easier to write and has definitely deflated the number of classes I've had to create otherwise. Some would say that's just lipstick on a pig but I prefer to see it as an oasis in a desert. Lastly, don't take this as advice for the backend you are building for a new start-up but I really see Spring's strength in that consulting CRUD-software market. If I can define specs in a legally-binding contract before writing a single line of code, if I can bang out a schema at the start of development and not worry about migrations, I would actually choose Spring. All the "corporate-rep" of Java won't hurt for these types of projects either. But on the other hand, for environments where I need a lot of flexibility and lack the leisure of time almost always, I feel like Spring would be a development death march. Misc notes: 1. I'm not actually learning vanilla Spring. I'm using Spring Boot alongside Vaadin. Overtime I've come to distinguish better between the two but maybe some percent of my frustrations in the learning phase is on Vaadin, not really Spring. 2. I made extensive use of ChatGPT in learning Spring. Even for such a boring/common tech, it's hilarious what ChatGPT gets wrong. But it also gets things right, giving advice in a level of clarity that blog posts and SO posts couldn't have provided. I would recommend anyone trying to learn Spring (or maybe any other framework/technology) to give ChatGPT a shot too. Even when it gets things wrong, the feedback loop that resembles actually talking to someone helps with the rubber ducking. Again, all 2c worth of opinions from someone not even a year in this framework. Caveat lector!

coderoffortune 3y ago

Don't worry, all negativity comes from those miserable Go devs.

m_0x 3y ago

The negativism towards has two main points: First, that Spring it's bloated. Spring now has a wide extension of modules that you may or may not need. Most of those modules won't even be added in your classpath unless specified in your pom.xml or build.gradle file. Very simple projects won't need the vast majority of the full Spring power. Second, that a Spring project takes too much time to launch the web app (Compared against other frameworks doing the same task). Part of the reason it takes too much time to start comes from how the engine inflates the beans and injects it. On that same topic, other frameworks such as Micronaut are more lightweight because they don't bloat the framework as much as spring, thus the launch time is shorter. Also take into account that Java developers adore complexity in code structure so that also affects launch time. Are you going to regret going with Spring? No, there is a lot of support from the community, if you have any issue you will find help in reddit and stackoverflow. It's a really mature framework. However it's not the only option. There are other frameworks that could be a better choice for your use cases.

lmm 3y ago

> Am I missing something? Will I regret this in six months? Yes. One day you'll add another dependency to your classpath and your application will magically be doing something you didn't want or need. And the way to turn it off will be an undocumented annotation that only exists in the next version of spring boot, so you'll upgrade to that, and then a whole bunch of other stuff will break.

itpragmatik 3y ago

Java 17, Hibernate, JPA, Spring Boot - all the way! Excellent combo! Reliable, high developer productivity, excellent community support, stable - have been using it for more than 8+ years now and won't think of using any other framework if I am going to build something in Java. Very easy to design, build, deploy, troubleshoot, maintain REST API Services! You won't go wrong at all if you choose Spring Boot.

moribvndvs 3y ago

The bulk of my full stack experience has been dotnet. But for the past 5 years I’ve moved into Java and Spring. I’m not a big fan of the JVM, but it works. However, Kotlin + Spring Boot is pretty fucking incredible. 1.x is kind of a pain in the ass, but 2 and 3 really blow me away at how well things integrate when you go with convention. The major gripes I have is that _up-to-date_ documentation on the best ways compose a modern app using several modules where you aren’t fighting the tools. Official module docs tend to breeze over stuff. I can’t tell you how much time I’ve wasted rolling my own ____ and fighting against autoconfig then finding there’s a simple but poorly documented way of doing what I need. But even with that frustration, I feel like I’m able to launch projects faster using Spring Boot than dotnet.