W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: [DOM4]: Element.create

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 20 Sep 2011 23:59:14 +0200
To: Sean Hogan <shogun70@westnet.com.au>
Cc: www-dom@w3.org
Message-ID: <pp1i77ls7bd7coudv9bj8g1rookcovqol4@hive.bjoern.hoehrmann.de>
* Sean Hogan wrote:
>I can't imagine any scenario where people would switch to using this, 
>because:
>
>a) it won't be universally supported for some time. Meanwhile it is just 
>another feature to detect
>b) even when it is universal, the old methods will still be available
>c) it gives no appreciable performance boost

Web browser developers are and talk the most to people who work very
closely to the browser cores. Consider people writing applications for
only one browser like "demos" often are these days, or browser-specific
test suites or extensions and so on. They love this kind of stuff and
actually will use it. Others not so much, but they don't care much.

>Is there any precedent for js devs switching to a different API when it 
>isn't necessary and doesn't improve functionality or performance?

Release and distribution policies and methods are changing, it used to
be that you get the latest browser by buying a magazine that has it on
a CD and then install it if you like. Now browser vendors take control
of your computer and install whatever they think you should run, and
do so quickly, so looking at precedents is not very instructive in the
mid-term as this is a relatively recent development.

But yes, there are some features that slowly get picked up in niches
and eventually spread. Most people don't notice because the libraries
and frameworks offer the relevant features reliably long before they
become viable to use directly, and it is not unusual that they do not
work well alongside the library if it does not wrap it. If loading a
library was as easy as saying "use Library;" without first pulling in
another library and without landing in a intra-library compatibility
nightbare, and a library maintenance nightmare, which we do due to JS
language design and library curation and general testing problems, we
would be talking a lot less about pulling all sorts of things into the
Core.

But we do have these problems and warped perspectives so we do get to
discuss proposals such as this one, and it is difficult to argue with
the low effort / low benefit argument in support of such proposals.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 20 September 2011 21:59:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT