I was recently having a discussion with some other webdevs about Google Web Toolkit, a Java-based library for creating dynamic, application-y websites.
GWT, as I see it, has two main ideas:
- Writing for many browsers is hard; write once and compile to any/all browsers.
- The best way of creating a user interface in code, is a layout manager, like Java and other desktop application languages.
Idea 1 is sound, and IMHO completely inevitable. Idea 2 is laughably, embarrassingly wrong, and it's why nobody but Google is using GWT.
Eventually somebody will get it right for HTML and CSS. I'd love it if Y! were the company to come up with a HilariousLanguageNameHere -> universal HTML+CSS compiler. It's a hard problem, but we shouldn't shy away from those.
The key point about HLNH is that it will have to still look a lot like HTML does. The interface-first method of application development, where you see what your application looks like first, and then hook functionality into it, is one of the most important concepts that the web has given computing.
Hooking the idea of an interface language into code compiler process is a hard one, and one that Google hasn't solved. Where does HLNH sit in the flow, and interact with existing technologies?
- a filter on the web server, like an apache module?
- a code-generation library for PHP/Python/etc., used at will?
- a feature of a framework?
- god help us, a browser plugin?
It's a hard problem, and GWT is at best half of the solution, which is as good as no solution.
* The thing about the longevity of this blog is that if in 10 years time I get bored and become a monk or something this statement will still be here for you to laugh at.