The hidden agenda behind GoGoEgo as a Web Development framework: creating a friendly framework that provides one solid development model, but warmly embraces others.
Because of the variety of my work, I get to use a number of different Web development environments. In the past two weeks, I've done non-trivial work on projects using:
I'm fortunate to get front-line experience with the good and bad of all these ways of producing something on the Web. Of course I have certain favorites that work really well for the way I think, and the dynamics of my team at Solertium -- everybody knows I love Restlet and GWT, and the latest bleeding edge trunk versions of each.
I have other favorites. I think you can't beat the terse elegance of Ruby with a DSL like Sinatra and an awesome ORM like ActiveRecord. I'm still wowed by Rails' ability to scaffold a complex application with a couple shell commands. Even my non-favorites have their bright points: ASP's performance really is the number to beat, and while I personally lack the Microsoft-fu to get good results with it, I'm blown away by the sheer transaction-per-second output of a platform virtuoso like Scottie Nguyen of NACA. I can't make a maintainable application in PHP, but obviously some other people can: WordPress and its plugin community are proof.
But ... can't we all just get along? It's very frustrating how heavily each framework optimizes for its own development community, and typically gives lip-service to interoperability. Microsoft, of all unlikely entities, is often in the lead with its COM-based cross-language, interconnected-framework approach, and heavy leverage of SOAP and similar APIs ... assuming you're running a Microsoft OS and web server, interoperability within those constraints is a breeze.
So this is me coming clean about my hidden agenda behind GoGoEgo as a Web development framework: creating a friendly framework that provides one solid development model, but warmly embraces others. Working in order of favoritism (because that's my prerogative as a CTO), we began by laying out a development strategy based on Restlet, GWT, and OSGi in the Java world. Now that the model is mature, we're heavily embracing JRuby -- Rails, Sinatra and friends -- essentially making GoGoEgo into a super-performant and manageable container for Ruby deployment, that happens to support injection of static artifacts via a rich browser based Studio. We have three very large projects going on now that combine GoGoEgo Java and Ruby bits in this way -- announcements to follow later this year.
Other JVM-hosted languages and frameworks are easy to bridge in later. I'm looking for a Groovy/Grails expert to get on board. Scala will probably get its own terse version of the Restlet-powered GoGoEgo API, sometime after Restlet 2.0 GA. Python scripting is already the best way to do server side script in GoGoEgo -- now with Jython 2.5 -- and no reason we couldn't do Rails-like tricks with Django. The guys at Caucho already have a really solid PHP emulation on the JVM, and they're brilliant, so why not support PHP as well? I doubt a Microsoft-optimized GoGoEgo will ever come out of Solertium directly, but that's the miracle of open source ... as the platform keeps expanding exponentially, someday an enterprising soul will make a port.
Of course, to live up to my friendly framework objective, at some point we'll have to expose some kind of session model for non-RESTful applications. But, again in order of favoritism, this can be at the bottom of the queue. Nobody said we had to be that friendly!
