>what matters most to me is speed of development and whether or not I enjoy the process.
Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important consideration over enjoying the language.
[1] All benchmarks are suspect until proven otherwise. You can write slow software in Java/C/C++, you can write fast software in Python/Ruby etc etc etc
I think most people these days take scalability to mean the ability to handle more load by adding hardware without changing the architecture. That's quite different from how much load the same hardware can handle (performance).
I dunno, I hear the term "scalable" applied to business decisions all the time. I think it encompasses more than "Is this problem embarrassingly parallelizable?"
In business terms, what people usually seem to mean is "able to bring in more revenue without having to hire people with skill sets that are rare or difficult to qualify". A software consulting business doesn't scale because it requires hiring programmers; a telephone support business might because it's much easier to hire people who can speak English and follow a script.
From my experience, the Spring one would take 10x as long to make, which means more developer cost and more feedback reaction time. Certainly not a deal breaker, but a cost/tradeoff one must consider.
As someone who recently came back to Java from a 5 year stint with Rails, I can safely say this is not true by any stretch of the imagination. If you stick to those tools in the Java ecosystem which meet your requirements, you can be incredibly productive.
The problem is that the Java world is full of over-engineered solutions which are really targeted at extremely large enterprise applications surrounded by a community of folks who like to menturbate about them. As a startup, you don't need to focus on those solutions. You'll not need 99% of them.
However, you can choose bit and pieces. I'm using Vaadin, JPA and Guice and finding it incredibly productive and am able to deliver functionality in far less time than it took me in Rails. I'm not using 90% of the Java EE stack, but it's available to me if/when I need it.
Rails was a great thing for the software development world. It drove convention over configuration and caused a lot of the competing technologies to pause and question why things were the way they were. But IMHO, managing the whole Rails stack (rails + coffeescript + css in our case) across a group of people became a chore. YMMV, but the statically-typed nature of Java along with the very capable technology stacks you can assemble have eased our daily jobs tremendously.
I use Spring every day as part of my day job, and I agree that a lot of the development time slowness is due to culture/enterprise. But that is a serious problem that can't be readily dismissed.
So far, so good. It's very different from your typical template-driven approach. We have a decent amount of Swing experience, and developing with Vaadin feels similar (but much easier) than Swing.
If you are developing business-facing applications and not just consumer web sites, as we are, I think Vaadin makes a lot of sense. It might even make sense for consumer sites, but that's not our current target.
I should also say: putting together a new screen (form or otherwise) in Vaadin is extremely fast. It's the fastest I've ever been able to develop web-based UIs, simply because all I'm forced to think about is Java.
Do you have actual experience with developers of similar skill levels building a similar app in Spring and Rails?
While undoubtedly less expressive I think most of the bad rep Spring gets is because it's used in "Enterprise", which means programmers that are, if not of lower level, constantly interrupted and yanked around and told what not to do.
I wouldn't choose Spring anymore because there are better alternatives, but I'm pretty sure the 10x is in the programmer and not the framework. The framework might be 2x, if that, but not much more I think.
P.S. If you include Spring Roo then I'm pretty sure the 10x no longer holds, but I never got up to speed on Roo myself so I can't say anything authoritative on that.
Oh sure, there are reasons to use an easier/faster-to-develop language, I believe every developer should know a 'hard-and-fast' language and a 'slow-and-easy' language... and know when to use them.
98% of the websites out there could run on python and I doubt we'd see a big performance difference.
However, I really don't think there exists a 10x difference developing in Spring. Hell, I don't think there is a 10x difference in using Struts vs Rails.
Spring development is considered slow as it brings images of enterprise shops taking several years to go through the bureaucratic red tape necessary to incorporate a new feature.
I've worked with plenty of small companies using Spring and their development/release cycle is maybe 1/2 or 1/4 the speed of comparable 'easier-to-build' technologies, but it definitely isn't 1/10th the speed to develop.
I worked at a start-up a few years ago. I worked on a PHP-powered website that spoke to a Java-powered (Spring/Hibernate) service layer. The PHP team consisted of one: me. The Java team consisted of over 10 engineers. I outpaced them easily and consistently.
In other projects with similar divisions, I've had similar experiences, though not always so dramatic.
I used to be a hired gun that would be called in occasionally to, like you, code circles around bigger teams when deadlines were tight.
Last few years however I decided to stick around with one of my clients for a while and I realized that quite a few of the employees I considered sub-par before were actually pretty decent programmers doing their best to do quality work in a dysfunctional environment.
I've since then learned to really appreciate this quote, which my gut tells applies to your situation as well:
"Never attribute to incompetence that which is adequately explained by bad management."
You're exactly right. I hope my comment didn't come across as critical to the engineers I worked with. Some of them are the best engineers I have ever worked with, and I have great respect for them.
Hm, I'm not sure a benchmark like these allows one to draw such conclusions.
The benchmarks, although good, are a best case scenario and of limited aspects of those frameworks. Real applications don't behave like this. What if on the average case such huge differences in performance becomes eclipsed by other factors?
The reason why I don't like to see this same argument somewhere at the top of every single performance related thread is that it is not a law of physics that faster languages/frameworks are necessarily less productive than slower ones. It's not even an empirical truth.
If someone from my team suggested to use Cake PHP I would say no without even looking at it once. Not because I would never trade performance for productivity, but because I simply do not believe even for a second that productivity gains are the reason for that kind of horrific performance.
I 100% agree with this. It has been a huge point of discussion for us here internally. "Developer efficiently with language x." Ultimately, language performance does matter but there are ways to make up for less performant languages. If it takes you 2x as long to get something out the door though, then that is a huge problem.
Just use the language and framework you are most efficient in and enjoy using. Worry about framework performance when you notice server load increasing over time.
Sure... as long as you have the migration and rewrite plan done and ready to go, and have engineered the product for that rewrite. Otherwise you're gonna be wishing you'd failed rather than succeeded.
Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important consideration over enjoying the language.
[1] All benchmarks are suspect until proven otherwise. You can write slow software in Java/C/C++, you can write fast software in Python/Ruby etc etc etc