HN Explorer

Ask HN: Why do sane developers use Spring MVC?

7 points by unclebucknasty ↗ HN
Is it me or is Spring MVC the most ridiculous Web framework in history? Please someone help me to understand why this hodge-podge of programming techniques is considered anything near desirable, let alone a leading Java framework?

When doing anything, you have: XML-based configuration, mixed with some convention over configuration, combined with annotations, and the rest implemented in code.

You never know where anything is or what's going to happen magically, you repeat yourself...er, repeatedly...and it's only half-automated. Some things happen auto-magically, some only when annotated, others declaratively, then finally some in code. Oh yeah, and some requires a combination of anywhere from two to all approaches simultaneously or it just won't work.

It is just plain awful, yet everyone acts like it's normal. What gives? Emperor's New Clothes?

19 comments

[ 5.3 ms ] story [ 62.1 ms ] thread
good-citizen
i'm not sure the answer to your question, but it made me LOL. I completely agree.
unclebucknasty
Whew! As long as there's one other person out there who agrees, I know I haven't slipped into a parallel universe.
eip
What would you use instead? Spring MVC covers a lot use cases simultaneously.

I use Wicket but it doesn't cover all the use cases that Spring MVC does.

yowza
There it goes. Trying to cover a lot of use cases.
unclebucknasty
>What would you use instead?

Maybe Assembler with a little Perl? Anything else! Seriously, even the old Struts was better.

>I use Wicket

Wicket is pretty elegant. Clean, componentized, and fosters reuse. Issues with heavy session-reliance probably keep it from being more general-purpose, but it's actually fun to use.

VaidasC
Well, whatever your opinion is of Spring (mine is negative) or however you look at this you need to acknowledge that Spring MVC is probably the best Java "Action" framework. Combine it with the fact that it's most popular framework too (arguably above JSF) and also the fact that people get things done with it on consistent basis.

My only complaints are something along the lines you mentioned - Spring overall and MVC specifically to me is framework without philosophy. It once had very clear philosophy, but now it become just mixture of features and multiple ways to do same thing. Once it was like "understand principals and let your mind do the magic", now its more like "there are no principles, just multiple snippet for doing thing you want - just Google it when you'll need it". Basically, it's no longer rewarding.

Second complaint is - Spring MVC, despite being so popular, is just not a 5 minute project setup technology, setting it takes time.

unclebucknasty
>Spring MVC is probably the best Java "Action" framework

I'm not so sure. But, just the fact that it's even arguable is depressing.

The rest of your comment is right on. Feels like I'm just gluing together a bunch of small messes into one big mess vs. coding.

arisAlexis
what a rant. Spring has many many useful stuff going on boosting production (dependency injection? easy integration testing?). Just because your learning curve is steep doesn't mean that a product is bad. XML configuration is in the past you can do everything annotation based. If you don't like annotations maybe you don't like Java? If your problem is with Java GO get another language ;)
unclebucknasty
>what a rant

Thanks, but I can't take credit for it. I owe it all to Spring.

Dependency injection is overrated.

>XML configuration is in the past

Show me your empty -servlet.xml file!

But it is funny that you picked just one thing to eliminate. That still leaves at least 3 other approaches!

I don't have a problem with annotations per se. But when you throw them in with a hodge-podge of approaches, at some point the result is a hot mess.

>because your learning curve is steep doesn't mean that a product is bad

Oh, but it can be a pretty big hint. And, here, that's exactly what it means! It's way too kludgy, overengineered and error prone. If you start with the question, "why is the learning curve steep with this particular framework?", you should quickly realize that it's suboptimal at best. ;)

splix
> Show me your empty -servlet.xml file!

Easy. You don't event need empty one, just in web.xml:

<servlet>

    <servlet-name>spring-dispatcher</servlet-name>

    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

    <load-on-startup>1</load-on-startup>

    <init-param>

        <param-name>contextClass</param-name>

        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>

    </init-param>

    <init-param>

        <param-name>contextConfigLocation</param-name>

        <param-value>com.mycompany.MyConfig</param-value> <!-- annotated with @Configuration -->

    </init-param>
</servlet>
arisAlexis
but what are you talking about? have you seen spring boot? There is no .xml file to be empty to start with. Please research technologies better before you judge them.
unclebucknasty
I am finding that less needs to be done in .xml. Instead, you can use heavily annotated classes or annotated config classes.

But, that's still awful. First, why give three different ways of doing the same thing? Provide one clean way and teach it. Is the other stuff just legacy baggage? If so, at least clean up your docs.

And, that's part of the point, right? If you have this unnecessarily large learning curve because of all this unnecessary framework cruft, then it speaks to the quality of the framework, as well as the ease of development and maintainability of the apps that use it.

Secondly, I know some people think annotations are the path to everything, but they really can be abused. At some point, you are sacrificing coherence and just introducing a lot of functionality that is not expressed through code.

And this doesn't get into the hidden gems like, "use this automagical feature and it quietly disables that other needed automagical feature". And, "add this thing that will be needed by 99% of Webapps to your config, or it won't work." Really? Then why not make it the default?

Maybe you've been using Spring for a while, so it's awfulness is no longer a big deal to you. You have adapted to it. Heck, I did the same with Struts years ago. But, I would bet that if you were starting today or if you were given a chance to work with a cleaner framework, your first thought about Spring would be "are you kidding me?"

matthewking
I'm coming from Rails (7 years) and am now looking at Spring Boot - I've also experimented with Scala and Play, Scalatra, Sinatra, Go, .Net MVC, Elixir/Phoenix. I'm impressed with what I've seen so far from Spring boot. I've only got a experimental app connecting to a database and producing JSON, but no XML config yet other than my POM. I'm actually very impressed with how much code I'm not writing, which is something I've become accustomed to with Rails and was a surprise from Spring/Java.

On your point about maintainability: If you're writing a large app that you're likely to be supporting for the next 10 years, I like the idea that backwards compatibility or at least some form of lenient deprecation is in there. Once you're over 25k LOC do you really want breaking changes every framework update which require you to drop all your planned features and improvements and change all your code again?

gt565k
As someone who came from a Rails and Django background, and is currently using Spring MVC, I completely agree. Spring MVC is light years behind other frameworks.

Why do companies use it? Because Java developers tend to get stuck in bigger companies, working on enterprise projects, and they tend to get tunnel vision. Thus, they stick with anything that's Java.

I went to the DevNexus conference and a person in the audience asked the presenter:

"Why do things like Rails, and Python exist? Why don't people use Java and Spring for everything?"

Now this is an isolated anecdote, but it gives you an idea of the state of Java developers. They tend not to go outside their comfort zone to learn new tech.

The presenter mentioned that they are actually trying to take the Rails asset pipeline, and implement it into Spring. Something that has existed for years in Rails, is just now making its way into Spring.

I want to also highlight that certain things are just not possible because of statically typed languages like Java. Dynamic languages are a lot more flexible.

Another talk I attended at DevNexus was called "Framework Fanboys". It addressed this exact issue about exploring different tools, libraries, and frameworks, and using the right tools for the job.

While developing with Spring, I often find myself writing boilerplate code that would have been unnecessary in other frameworks.

Spring MVC can't even touch modern frameworks when it comes to rapid development and functionality

unclebucknasty
Good points and Java being typed vs dynamic does impose some limitations (though properly used reflection can mitigate some of this).

Still, there is no reason Spring has to be that bad! It's not so much a Java thing as it is Spring-specific. I literally laughed out loud while reading their documentation. I thought more than once, "are they kidding?"

It's true about enterprises though. Most took forever to allow any open source. And, now that they have, they seem to be perpetually at least one generation behind. Some stability is good, and I think the startup culture tends to be at the other extreme: constantly throwing off some new tech flavor of the week. But enterprise is way to slow too adopt.

There has to be a happy medium!

gt565k
There's a reason why Grails exists. It takes advantage of the JVM by running Groovy, and gets rid of all the Java cruft.

Spring is just meeh...

vorg
> certain things are just not possible because of statically typed languages like Java. Dynamic languages are a lot more flexible

It's not the static typing of Java that stops certain things not being possible, it's simply that some things like lambdas/closures weren't built in. Dynamic language Beanshell existed for a long time but didn't have closures, so many things were still not possible. Then Groovy came along adding closures to what Beanshell already had, so Gradle could use those closures, and Grails could add a MOP to the closures and use them too. Now that Java 8 has closures and Scala exists, new apps could even use them when they need a language with closures, even though they're not dynamically typed.

splix
There're two parts: why java, and why it's so popular in java.

About Java there are many reasons, I think, like it's very strong, rich ecosystem, a lot of libraries, for everything, mostly well documented, os independent so you could distribute you app in binary form, etc. Last one is very important - you'll need only compiled .war file of your app, rather that installing this crazy amount of libs on target system, as you do in python/ruby (thanksgod Docker is going to help there). So, for many people, it's less ricky to choose Java (or JVM), know that it will be stable and focus on something else

Why Spring for JVM? probably because we don't have any good alternative. I can recommend Grails, it's good for many cases, I like it personally, I'm using it for simple projects since 2007 I guess, author of several plugins, etc. But I can't say that it's as solid as Spring. There're many other frameworks, some of them small and undocumented, some just outdated (like Struts), some too niche (like Vaadin), and so on. Spring is most universal, most flexible, most documented and have largest community. And don't forget that it's not just web framework, Spring MVC is just _one_ module of much bigger project.

I guess you've started with Spring no so long ago, right? so you got this confusion with configuration, with "magic", etc. Looks like you're mixing different types of ways of using Spring, maybe because you've read different docs/tutorials/SO answers/blogs posts, each of them for different versions, for different architecture, for different conventions. That's common. All could be mixed together, but it just makes it complicated and "magical". Spring is not forcing you to choose one way, not telling you how you should design your app, that's all up to you, there is not just one right way, but many. And it takes time to learn this. Spring is designed pretty logically, follows some rules, and at some point of time you'll get it, you'll get whole Spring at once, everything will be clear and logical, you'll know (or feel?) how to use it. But it takes a time, maybe months, maybe weeks.

PS and remember, nobody forces you to use Java for Spring, I prefer Groovy, for example. Same for XML, you don't need it, annotations + *Configurer can do all job for you

vorg
> Spring for JVM? [...] I can recommend Grails

> nobody forces you to use Java for Spring, I prefer Groovy

Recently the Groovy/Grails sponsor VMWare split them off from Spring and retrenched all the developers working on them, while keeping their ownership of Spring. The only reason I can think of is they didn't want Spring dependent on Groovy or Grails in any way, so if you use either of them with Spring, you might have incompatibility problems in future.