cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Modernizing CForms
Date Mon, 19 Mar 2007 23:20:07 GMT
Grzegorz Kossakowski skrev:
> Sylvain Wallez napisaƂ(a):
>> Grzegorz Kossakowski wrote:
>> The "IE gives me shudders" feeling is partly one of the reasons for Ajax
>> toolkits to exist. This unfortunately doesn't solve everything, but
>> helps a lot!
> This only partly address my doubts. I really ask about the prospects for 
> AJAX. If I'm going to invest my time in learning AJAX toolkits I would 
> like to be sure that they are capable to do much more than flashy 
> examples. What's questionable for me if AJAX can become _platform_ for 
> building Rich Client Applications as we already would like to use it for 
> building such.
> I agree that REST is great because it's more standard way of doing 
> things (HTTP-compliant) and in theory would both reduce server's load 
> and improve user's experience. I also can see that this reduces a 
> complexity a little bit because it's more client-server architecture and 
> no viewer-(server+view producer) as it's now. However, what I'm trying 
> to say is that reduced complexity on server's side does not only come 
> from building REST-style applications but also from moving some 
> significant part of whole complexity from the server to client.

The idea is that total complexity for a "rich" AJAX+REST application is 
lower than for a "rich" MVC model 2 application. See for a 
detailed argument for this.

So for me it is quite clear that the AJAX+REST architecture is very 
promising. As I just have started to explore this way I have far to less 
experience of it to know if the promise holds in practice yet.

> Now it 
> becomes clear that we need tools and execution platform on the client side.
> What we have now is only bunch of quite compatible and 
> standard-compliant browser's and IE. There are toolkits that try to 
> improve the situation but they still need to be run on IE and I fear 
> that we are going to hit their limits in near future. I would like to 
> see strong arguments that my doubts are just unjustified...

It is of course always hard to know with Microsoft. I actually build my 
first (and this far only) Ajax widget (a lazy loading tree menu) on IE5 
long before the technology was dubbed AJAX. At that time all other 
browsers where far behind. Then Microsoft pulled the brake and stoped 
development of IE for a long time.

Now there seem to be some reasons to hope that they take browser 
development serious again. First they decided to consider browser update 
security critical. So thanks to that the vast majority of users have a 
modern browser now. And secondly they have given up their resistance and 
have developed a cross browser Ajax framework which probably will make them more 
motivated to make IE a good Ajax platform. But you never know about 
their priorities.

> Said that, I would like to stress that I do not stop anyone from taking 
> this approach and even I would be happy to help make Forms more 
> REST-like. What I wouldn't like to see is a Forms client app that we are 
> going to support. Haunting for IE bugs is not fun for me and I think we 
> could hardly find folks that I are enthusiastic about it either.
>>> Maybe I'm just ignorant but... is there any multi threading capability
>>> on browser side? Is it only me experiencing Firefox freezing while dojo
>>> toolkit is being loaded?
>> No, JavaScript is not multi-threaded, and although there are discussions
>> IIRC to introduce it in JavaScript 2.0, we won't be able to rely on it
>> on our browsers for many years.
> I'm really sad and even more doubtful hearing that :/

Although JavaScript as a language doesn't contain multi threading DOM 
objects like XMLHttpRequest obviously executes JS code in multiple 
threads, so I'm not certain that it is such a big problem if the 
language lacks such constructions.


View raw message