Some thought ... Last week I thought a bit about reacting on events without client-server round-trip and without having to write JS. I had an idea - to write event handlers as methods and annotate them with special annotation @ClientSideEvent. Then feeding the class to the Java-JS compiler we would obtain the JS we need to embed into the page. And something similar about component model - properties annotated with @ClientSide would be available to client-side events (and marshalled to the server as path scoped cookies for instance). To start experiment with that I downloaded GWT 2 devkit and had a look to their compiler. Unfortunately it is not capable to compile single class into JS. It requires a bunch of configuration and core infrastructure and it always generates HTML. The class of your interest would be the inlined JS script within the generated HTML. That does not suits. And BTW gwt compiler is slow as hell (minutes!!!), how people are happy developing GWT applications?
Then I realized what I'm looking for - the decompiler from .class file to .js file with some filtering capabilities. Having such a tool it becomes possible to add dynamically decompiled .js resources to the components (js accessible via URLs) and write client-side state in Java, along with server-side state. All we would need to implement are client side context and client-state marshalling. Although it seems doable I'm afraid it may be extremely expensive to develop and support such a tool. And it would require some changes in Wicket rendering process (opeate with attributes in dom manner instead of handling onComponent rendering event). The next generation of HTML/JS would evolve towards client programming capabilities. I like Wicket for its full freedom of HTML (contrary to GWT) and I would like to use similar model when programming rich web client applications. And it is less about the Wicket way of splitting html and java. It is more about binding to dynamically loadable data with any deep of structure displayed on users demand. The GWT way would require to program it in any way when Wicket does it transparently. Another story is authorization that can be done transparently. But web development evolves and client side programming becomes more and more demanded. I tried to think about how technically we could use the best of both worlds. What do you think about all that?
