Will Groovy work for the PHP crowd?
It feels like there has always been somewhat of a divide between PHP and Java development. A large number of PHP projects seem to be quick and dirty hacks with no regard for scalability or extensibility, but that is why it has been so successful. A sad fact is that most people in this world aren’t forward-thinking and just want a quick fix and they want it now.
You can do dirty hacks in Java but you have many more obstacles to overcome – you have to use Objects for start, compile them, deploy a web application etc.
It’s a no-brainer really to see how even a rather ugly scripting language like PHP can trounce Java in the web marketplace.
However it seems natural that an awful lot of people who previously lived in the PHP camp will defect to Ruby on Rails. I’ve not used Ruby or Rails yet, but I’ve read a bit about them. I can see exactly why PHP-style developers will find it attractive.
There appears to be some kind of anti-Java snobbery or psychological barrier to people deciding to learn and deploy Java. Maybe it’s hideous misconceptions of performance, complexity or limitations. I wager there’s quite a bit of urban myth and folklore among the younger website "hackers" who don’t spend time to actually discover the facts and just cite some ill-informed blog somewhere that said "Java performance suckz man".
Groovy has the potential to change this. It supports scripts, not just classes, which makes small jobs easier for everyone. In Groovy it is easy to write many constructs that feel cumbersome in Java. It is dynamic, and this appeals very much to the "coding by the seat of your pants" side of one’s programming persona – without the feeling of also needing a shower afterwards as when you use PHP.
The trouble is to leverage all the great libraries out there for doing web stuff – like RSS parsing, caching and rendering, Ajax, sending email – are in Java land. They are trivial to call from Groovy but they require you to cross the bridge from functional libraries (as most core libraries in PHP are) to often quite complex OO APIs.
I think that if you could download a single .tar.gz containing Java, Groovy, Jetty and a trivial groovy scripting servlet, that the prospects for Groovy and hence Java in the website space could be very different. Not everybody wants Rails… I imagine it is overkill for most "static" websites that just have a contact form or two.
These types of sites represent a very large part of the market and serve as the training ground for young developers. These sites will continue to be written in PHP for a long time I think, unless someone provides an "install and go" solution. Oh, and makes it palatable to all the ISPs in the world 
**
For the moment at least, it looks like Ruby On Rails will be in the limelight for some time. The main gripes I’ve seen about it are related to performance and scalability, and lack of unicode support. For many applications these things don’t matter, or in terms of performance a new server can be added for relatively little outlay compared to the perceived development cost of using a Java based solution.
The web development market as opposed to the Enterprise market has always been dominated by lowering costs. That’s why people don’t want to have to spend long learning something, and want instant gratification. That’s what scaffolding is all about, even though it is often useless in real life applications beyond the prototyping stage.
So Java has the feel of a more "software engineering" solution, and PHP has a feel of "just getting things done". Perhaps the two philosophies will start to collide in Rails and Grails.
I hope that we will be able to make Grails an attractive solution to non-Java developers. Instinct tells me we have the performance edge thanks to Hibernate under the hood, and JIT compilation in the Java VM. It will be good to see hard stats on this one day.
** – which requires a custom servlet container I think, that makes it really easy to host multiple applications from multiple home directories, with controls over how they can affect each other in threading terms etc
12 Comments
Paul Barry
February 21, 2007I think one point you left out about PHP is hosting. You can host a PHP/MySQL site for as little as $3 a month. Neither Java or Rails can compete with that.
Marc Palmer
February 21, 2007Yes absolutely… on that front Rails and Grails (groovy) are on a level playing field really.
DHH
February 21, 2007It’s ironic that you lambast others for their lack of knowledge about Java’s scalability and ease of deployment and then yourself commit the same fallacy regarding Rails scalability and unicode capabilities.
Java can no doubt be a scalable platform. Just as Rails can. Just as PHP can.
Marc Palmer
February 22, 2007DDH thanks for your comment, and to a degree you have a point – I apologise.
However, as far as I know extra libraries and changes to code are required to support unicode in Ruby, and there are still rough edges. I this is wrong please point me to the docs.
Also it appears that to avoid the 1+N query problem with ActiveRecord effectively you must code your query to achieve a JOIN including the relationships. http://www.infoq.com/articles/Rails-Performance
Just these two things make RoR feel reminiscent of PHP to me – hacks and special knowledge required to work around limitations.
Sure we have a few of these ourselves currently in Grails, but we’re working to eliminate them. Grails criteria support for advanced queries is very powerful. We have built in support for toggling lazy/eager fetching also.
FWIW I don’t believe I said anything about ease of deployment with regard to Rails. In fact you have Capistrano in the Rails camp which looks very interesting, and we may well add support for it to Grails.
DHH
February 22, 2007Easier access to unicode manipulation has been in Rails for quite a while. It premiered in a public release back in November: http://weblog.rubyonrails.org/2006/11/23/rails-1-2-release-candidate-1.
re: 1+N, you say “you must code your query to achieve a JOIN”. Hu? Yes, you must indeed tell AR that you’re interested in prefetching an association. That takes all the work of Post.find(:all, :include => :author). Or you can set it on an association, so you just do weblog.post and get it prefetched.
Are you suggesting that all associations should be prefetched at all times? That doesn’t sound very performant and quite wasteful.
Anyway, I’m glad we got these misconceptions cleared up. I’m always happy to help dispel “hideous misconceptions” born from “urban myth and folklore” among older Java folks “who don’t spend time to actually discover the facts and just cite some ill-informed blog”.
(If the connection needs to be cut in neon, see paragraph five of the original post).
Marc Palmer
February 22, 2007So you’re saying that Rails has had unicode manipulation for… three months tomorrow. I also note from the article you linked that there are special cases where you have to do things differently (i.e. length access). I note that you have unicode support but actually, when we Java developers say “support for unicode” we actually mean native support for unicode plus conversion to relevant charsets.
It seems Rails is at an unfair disadvantage however as these features should be in the language Ruby rather than the framework – they have been in Java since year dot.
I am not suggesting data should be prefetched at all times, but the query optimisation issues go well beyond this I believe – aren’t queries required every time a request is made, rather than the ORM layer employing object caching for example? Also what about the lazy execution of updates etc to the database to improve performance?
Marc Palmer
February 22, 2007David, you also need to chill out a bit as you seem oversensitive to criticism of Rails. If you re-read my original post:
“The main gripes I’ve seen about it are related to performance and scalability, and lack of unicode support.”
Notice that I am not making any accusations, I am clearly stating that this is what I have seen other people complain about.
I also go on to say how to many this doesn’t matter as hosting is a cheap commodity now, provided your application itself can scale to clusters.
archnemesis
March 7, 2007I’m a java developer by trade, but I find it to be clunky for doing stuff on the web. I think java suffers from a number of legacy problems at this point (J2EE, JEE whatever it is now), which I don’t care to go into right now. I will say that most – read 99.9% – hosting companies do not have the skills to support java servers/apps for their clients. I really like the idea of tying Groovy/Grails scripts to java libraries and other services, but the hosting situation will continue to be an enormous barrier until someone does create that 5 minute, Grails/java website hosting and deployment solution. I don’t even see an inkling of this migration now.
Anthony
March 14, 2007Groovy/Grails will not work for the PHP crowd, and it never will.
If PHP developers want the structure and order that a good framework imposes on a code base, they’ll go to Rails before they even consider anything built on top of Java. And if the hosting issues with RoR vs. PHP are an obstacle, they’ll resort to things like Cake or CodeIgniter first — not that those frameworks are necessarily a substitute for Rails.
Grails has only one realistic target audience, and that’s Java developers, consisting of two subsets.
The first group consists of Java developers who’ve already been turned (like myself). We use Rails wherever we can. But we haven’t been able to overcome the numerous, mostly political obstacles that prevent the adoption of Rails at our day jobs. Grails is an acceptable alternative — a tolerable compromise for both the opinionated developer and the resistant, conservative organization.
The second group consists of Java developers who still haven’t seen the light. They may be Java loyalists. They may not want to concede the problems with Java. Or maybe they can’t seem to leave the safe cocoon of Java — even though Ruby is a butterfly, to quote Steve Yegge (http://steve.yegge.googlepages.com/transformation). In this case, Grails saves them to some degree from their unwillingness/inability to break out of their coccon.
You mention that the “Enterprise market” is not as cost-conscious as the “web-development market.” I don’t think that’s the case at all — they’re all about cutting costs. Why else has there been such a drive to offshoring development? The problem is the perceived costs — costs to migrate to a new platform, train/hire/find new staff, abandon investment in existing infrastructure, the lack of legally-enforceable support contracts, the perceived risks in terms of stability, scalability, performance, availability, etc.
So right now, the enterprise world thinks it’s too expensive and risky to adopt RoR. They may have only a superficial understanding of the huge productivity gains — both for up-front development and ongoing maintenance.
It’s funny, one big sell with Java are the perceived maintenance benefits. The allegedly more mature, well-engineered solutions of Java would help you recover any upfront costs in the long run, by producing cleaner, more maintainable code. So while PHP is quick-and-dirty, and Java may be slow (development-wise), it’s at least clean — at least, theoretically.
But in reality, too many Java/J2EE code bases degenerate into the same, unmaintainable, non-DRY spaghetti. And things are made worse by the still-endemic artificial complexity and over-engineering. So effectively, what you get with Java is slow and dirty — meaning slow in the long run, as well as in the short-term.
As soon as the enterprise market really realizes this en masse, the perceived relative cost and risk curves will cross. They already have for many organizations.
Depending on how rapidly we get to that tipping point, we may see the window where Grails is still relevant and important really compressed.
I guess that was just a really long-winded way of saying, nobody gives a damn about Grails and/or Java except for Java developers. And even then, some of us only care in the interim, until the enterprise world finally gets it, and gets Rails.
Marc Palmer
March 14, 2007Anthony – I agree with much of what you say. However I don’t agree that Rails + Ruby are the solution. Java has a huge base of code that provides high performance scalable solutions.
That, other than using Groovy which is “close” to Java but agile, is why Grails is a solid bet for enterprises.
I think if hosting issues for Rails improve, then yes the “kids of today” will grow up hacking sites in Rails instead of PHP. It doesn’t meant Enterprise will follow suit.
Why do you feel Grails is a compromise compared to Rails? Have you used it, if so what are the issues? Please remember it is a relatively young project but is packed full of features already.
Remember Objective
May 23, 2007Yeah, while I agree with Anthony, still attracted to Grails based on its own merit.
Also, for so many smart people in Ruby/Rails, they still haven’t delivered a pre-forked deployment (PHP). They still haven’t solved the multithreading issue definitively (Java). We’re supposed to use something called “Mongrel” and “lighttpd”…
In theory, neither Java nor Rails can approach the ease-of-scalability of the pre-fork model of PHP.
Stephen Lewis
April 15, 2008After (many) years of Microsoft application development (SQL Server, VB, C#, .Net) and a bit of Borland Delphi I have fallen in love with my new Apple iMac, and am starting to look at the non MS alternatives for web application.
I first looked at Java with Java DB and found the multitude of frameworks very confusing, then I built some sample Ruby on Rails web apps, fun, but strange…
Having discovered Groovy on Grails it seems just the right balance, an agile programming language, with all the tools to build robust database driven we applications. Getting Groovy, Grails with Netbeans installed on the Apple iMac has been a puzzle, and any (simple) install instructions would be very much appreciated …