Alexander Olaru on Infoq: "In Neal's opinion this demonstrates the confusion in the Java world
about web frameworks. He argues that if people only had 3 choices, they
could go and compare them while, when presented with 10 or 20
alternatives, paralysis sets in and they end up using Struts or
creating another version of their home-grown framework. He views this
situation analogous to the classic example of the store selling jam
presented in the book "Paradox of Choice: Why More Is Less":" - In a World of Web Framework Choices, Some Developers Still Build Their Own
I think this really gets to why Struts 1/classic still dominates the market, despite its limitations and age. And I remember feeling like this about the Python world back in 2004/5. Every month, a new framework that did 50% of what you needed, and the decision space multiplied by the number of template languages. The rise of Django and Turbogears in 2005 ended this problem (I don't think anyone would argue that Zope was dominant, although it was/is futureful). My own opinion then was that Django had "won" and that it would be generally a good thing for the entire platform to have less web framework options:
"Python, going mainstream, is in need of a major cull on the web
frameworks front, and Django seems to be just the thing to help that
process along."
It wasn't a popular opinion back then, but it seems to have played out. Django and TG are dominant, Python usage is on the up again, and my guess is that it's correlated to their use.
Java could do with a similar gutting, frankly. Once upon a time there was Struts/Webwork/Cocoon/Turbine/Tapestry/AnotherTapestry/Whatever. It sucked. Now there's a newer tendency in the Java world that complexifies decision making and helps keep things sucking - interesting frameworks which imply adopting a new programming language. Grails, Lift, JRuby On Rails - I think all have merit*, but aren't Java The Language and despite what people say about Java The Platform good or bad, not being Java The Language brings up problems (typically, "who will maintain my legacy") that can't be brushed away by claiming easy cross language interop or "familiar syntax". Aside from telling us something about how Java The Language fits at the web layer (remember we've been inventing pseudo-languages like JSTL/JSP since forever, nobody actually uses just Java**), I don't understand why frameworks and languages have to come as exclusive double acts on the JVM. Page controllers/Actions can be scripts running inside a Java frameork. Berlin Brown has demostrated this option at least twice, once for Jython and once for JRuby. There's a good multi-year maintenance story here; bang out controllers double quick for a one-oh in JRuby/Rhino/Jython/Scala/Groovy and port them to Java for the other 80% of the lifecycle, if you need to. [Porting is good? Yes, on the basis that all successful software gets constantly rewritten
over time, whether or not business owners like it.] SpringMVC seems to be a basis for this, becauses it use page controllers and chunks up code nicely (and it runs Grails). I remember not-finishing-a-hack on WebWork a few years ago for embedded Jython actions, which I guess means Struts2 could do this as well. This is good because if you have motivated get it done types with Groovy or Jython or JRuby skills you can ship websites faster without freaking out everyone who's cutting Java . It's bad because if you have highly motivated get it done types with Groovy and Jython and JRuby, you'll have a maintenance headache. I suspect managing this class of headache is why Google has a set of approved languages (Python, Javascript, Java, C++ that I know of) and most shops tend to settle on one or two - tho' of course there's always some joker who'll find a Turing equivalent loophole.
Infoq also quoted Charlie Collins, who thinks Neal Ford is wrong:
"The quintessential argument with Java is the plethora of web
frameworks. But, and here's the rub, that's a complicated space with a
lot of people working to solve the complicated problem in different
ways (and much of the problem not being their fault, but rather the way
HTTP works)."
I'm fairly sure the problem isn't that HTTP is a complicted problem, it's that web frameworks try to hide the web, the abstraction is leaky (transparency is a fallacy), and they end up sucking.
Incidently Neal Ford coined "Polyglot Programming"; I'd like to see Polyglot Frameworks.
* without sounding like a wiseacre, the answer to "have you looked at X" is very probably, yes I have looked at X.