What is the right framework for modern application development?

Everyone I know who might have contract work is getting an email from me these days! In my email to David Ascher of Mozilla Messaging I wrote
[...] my time at the start up was all Ruby on Rails .. which I grew to like .. but it is still the wrong language and framework for modern development.
to which David said
Can you explain your last bit?
Here is my attempt to do so.

Google Maps and then GMail significantly raised the expectations of web applications. Today, tools like GWT are raising it even higher. Tools on the web are in one of two classes:

1) sequential data access or
2) compound data use.

Rails and its imitators deal well with sequential data access. They are the GUI of REST. You have a canonical URL that represents the state of the application and the UI. For compound data use, however, you don't always have a canonical URL that represents the state of the application.

Ask the question "What is the URL for the state of my Thunderbird use right now?". As engineers we can imagine a nastly URL composed of very many parameters. A veritable URL maze. But we also know that this is not what is needed.

So, what is needed for modern development?

1) Rich GUI front-end tools as good as Apple's Interface Builder or at least as good as NetBean's Matisse and what Visual Studio has in it today. Apple, Microsoft, Sun and Qt Software (TrollTech) all have the advantage (today) of have an established user interface toolkit (the look) and user interface guidelines (the feel). For web applications this is missing today. There are lots of players attempting to provide this at the DHTML level (css + html + javascript), but I think what is really needed is a new browser standard akin to XUL, and, perhaps, Java Faces, Java Portlets, and even the "widget" ecology.

2) SOA and RESTful backend support of the GUI. This can be done today with all the web application toolkits like Rails, Grails, Django, Joomla, JSTL, etc. and workflow tools like BEPL. Most of this backend support can be stateless and so scale using common techniques and tools.

3) The last item is just the stuff that connects the GUI and the backend. While the developer should always be aware of the network between the two, I don't think the developer need be concerned about how data is marshaled and transmitted. I am not sure how this would be manifested. What Interface Builder and Qt have -- slots, channels, interface points, etc -- would be a useful line of inquiry.

I am generally out of the loop these days when it comes to cutting-edge UI frameworks. What I see in the open-source world though is inadequate. GWT is the torchbearer today but even here the tool pales in comparison to Interface Builder and what the SmallTalk and Lisp worlds have had for decades!

I realize I did not answer the question about language. I am sure Ruby is not it but it is better than many other languages in its language category.

No comments: