Hi,
I have been following this discussion and I think its not fair to call
Wicket Ajax support broken.
I started using Wicket back in 2007, and the environment then was:
- Support for IE 6 was a must.
- JavaScript on the browser was still slow and unreliable
- The applications where designed to work mostly with standard HTTP
request/replies, with only some specific functionalities being implemented
in Ajax.
Since then the web has evolved a lot - IE 6 is dead (or dying), Google
Chrome raised the bar for the JavaScript engines and most modern browsers
now support WebSockets for low latency communications. We are now at the
point where some people are deciding not to use a web framework at all, and
rely instead on JavaScript plus RESTful web services (Google Plus is an
example of such an architecture).
Wicket is still very good at what it does, specially considering the
environment in which it evolved. I personally dont think the API is an
issue - every API is a compromise and once you learn to live within its
limitations there is very little you can't do with Wicket Ajax one way or
another.
The issue I see is: there is a lot of opportunity for making applications a
lot more interactive by moving processing to the browser. GWT does that by
compiling Java into JavaScript, but my latest experiences with JavaScript
have convinced me that this step is probably unnecessary - you can be pretty
confident that once you use a framework like JQuery your code will run
unmodified in the major web browsers. The only thing that is not so easy to
do is to interact with the server-side state.
This is where I believe improvements can be made - enabling JavaScript to
interact easily with Wicket models and listeners. This would make it
easier to write more compelling user interfaces by leveraging current and
future JS frameworks while preserving the Wicket component and model
structure, which is in my oppinion Wicket's strongest point.
Regards,
- Juliano.
