Zied Hamdi schrieb: > > Surely since it's based on the servlet API, but I think the servlet API > is abtract enough to be exended to any user machine interaction. When I > was just reading without applying JSF, I was thinking JSF events are > processed at the moment they occur, which a completely possible > alternative through Ajax, When java come in, everybody was saying : it's > too slow, and I fan of java, was answering: you said C++ is too slow > (compared to C) but machines come faster and the user experience stopped > to be handicaped. I think the same phenomena is coming with internet > connection speed and the client-server applications: every application > will be client server based in the future, the need is clearely there... > being the first to believe in that "write once deploy everywhere" can be > extended to these limits can have some advantages on our next ten years > salaries ;-). > > > The main problem with ajax is less its speed, that will be resolved over time as you say, the entire concept is broken by design and could be fixed or killed but wont be on a browser independent level.
Several problems are with ajaxs approach: a) You have a huge document singleton which is the dom tree, this is an antipattern in itself because everything can influence everything, there is no isolation on subdom level which would isolate components in their designs from each other. (We currently have XUL and something IEonly which resolves that issue) b) You have ajax in combination with javascript, ajax is a cludge and quick hack, a typical microsoft solution. The underlying javascript has no mechanisms for concurrency no threading nothing, and ajax adds pseudo parallelism (which is not really parallelism in itself) The ajax communication layer is pure http with all its limitations, but that is not really the problem. The problem is the complete package. Add to that that JavaScript at least in the version implemented by the browsers is seriously broken, due to the lack of namespaces and a decent class/inheritance mechanism (altering the vtables-prototype arrays to achieve it is not everybodies taste) and you get a mix out of hell. Speed issues are really the last issues to think of if you target ajax, there are other issues which makes dhtml a living nightmare in itself. Speed will resolve itself over time, the other issues wont, because it is not in the business interest of a huge big player to fix this mess in a platform neutral way.
