W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: XMLHttpRequest Comments from W3C Forms WG

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 20 Dec 2009 16:12:45 -0800
Message-ID: <63df84f0912201612p39ab1770g6ef2a9367426c556@mail.gmail.com>
To: marcosc@opera.com
Cc: Julian Reschke <julian.reschke@gmx.de>, Alex Russell <alex@dojotoolkit.org>, Maciej Stachowiak <mjs@apple.com>, "Klotz, Leigh" <Leigh.Klotz@xerox.com>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>, Forms WG <public-forms@w3.org>
On Sun, Dec 20, 2009 at 2:39 PM, Marcos Caceres <marcosc@opera.com> wrote:
> On Sun, Dec 20, 2009 at 10:43 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Marcos Caceres wrote:
>>>
>>> ...
>>> Yeah, you are right. I guess we get so used to having these crappy
>>> retrospective APIs around that one forgets that things could be done
>>> in better ways - thankfully decent frameworks have been built around
>>> them to make these things usable.
>>> ...
>>
>> Maybe that could be a lesson for XHR2?
>
> Perhaps, but I haven't been following the XHR2 work - it could already
> address all this, for all I know:) Nevertheless, if there hasn't
> already happened, it would be good if people who have worked on making
> XHR actually usable would contribute to making XHR Level 2 more
> aligned with how XHR is used on the ground - thinking Prototype, Dojo,
> JQuery, etc.
>
> Seems a bit ridiculous that everyone is building effectively the same
> wrappers around XHR to make it usable when all this could be done much
> faster if it was implemented natively in the browser. Apart from
> having a whinge, I don't have a better proposal for how this could be
> done - I haven't thought about it, and there are people much more
> qualified then me to do that. I can only hope that those working on
> the spec have looked at how the frameworks do "ajax" and if lessons
> can be taken and specified out of that... or that framework creators
> contribute back to the standardization process from the wild.

Note that just because something is implemented natively in the
browser doesn't mean it's faster. For example what a lot of libraries
that wrap XHR do is to cover up browser differences, as well as
present a friendlier syntax. The overhead of doing this in JS is in
the order of fractions of milliseconds, whereas the the full request
usually take several tenths of a second.

Performance optimizing the JS overhead here is clearly not worth it.

I do however definitely agree that we should be talking to web
developers in any spec we develop, XHR included.

/ Jonas
Received on Monday, 21 December 2009 00:13:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT