W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Non-ecmascript bindings (was Re: Serving up Theora <video> in the real world)

From: James Graham <jgraham@opera.com>
Date: Fri, 10 Jul 2009 22:27:05 +0000
Message-ID: <20090710222705.9145c4r4044csco8@staff.opera.com>
Quoting Kartikaya Gupta <lists.whatwg at stakface.com>:

> Really, it's not that much work to make sure the API can have   
> bindings in other languages. As long as you can write WebIDL for it   
> (and provide relevant DOM feature strings wherever necessary), you   
> should get it for free. I would also argue that considering other   
> languages forces you to think more about how the API may be (ab)used  
>  and therefore results in a better and more robust API, even if it  
> is  never actually implemented in other languages.

It's not about whether it is a lot of work; it's about whether the API  
matches the typical programming style and feature set of the target  
language. Where this doesn't happen (as in much of the DOM), the API  
ends up feeling clunky and difficult to use. My experience with  
dom-equivalent APIs that have been designed to fully take advantage of  
the target language capabilities is that they are much more pleasant  
to use than the equivalent DOM APIs. Indeed one of the first things  
that most javascript libraries do is replace most of the DOM  with  
their own API. This hardly seems like a ringing endorsement of the  
design strategy that gave us the DOM. I don't think it is sensible to  
optimise for the few people for whom the cross-language* approach is  
convenient at the expense of the many or whom it is bad.

Sadly it seems that canPlayType is going to be another hacky-feeling  
API because of cross-language considerations and because the problems  
with it were not picked up soon enough :(

*I idly note that DOM seems entirely unsuited to some languages so it  
is only really cross-language to the extent that it can be implemented  
in any language where you can mimic the style of java.
Received on Friday, 10 July 2009 15:27:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC