Re: XMLHttpRequest Comments from W3C Forms WG

On Mon, Dec 21, 2009 at 1:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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 agree, there are instances where it doesn't really make a
difference. However, there is evidence that in some APIs, it did make
some sense to implement native support (Selectors API):

http://ejohn.org/blog/queryselectorall-in-firefox-31/

I guess by "faster" I really meant more logical and usable, meaning
hopefully faster for developers to work with. Like i don't seem to get
as nauseous when I use JQuery compared to when I use native XHR.
Anyway, that's just me and I don't want to take this discussion down
some rathole.

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

If you mean average web developer (say, someone that uses JQuery to
build some website), I think we can all agree that this would be nice
but probably impractical. I think it would be better to engage those
who built the great JS frameworks, which already engage with
developers on the ground and have made the innovations that have made
the unruly mess that is the Web development a bit more tolerable.
These are usually the people that, in my experience, know a lot about
incompatibilities across UAs and, more importantly, can give an
insight as to how developers actually wish JavaScript and related APIs
should look and behave.... though, it could lead to creepy method
names, like "$$()" :D

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au

Received on Monday, 21 December 2009 12:41:32 UTC