[whatwg] Thoughts on recent WhatWG blog post

[Brett Zamir]

On 2/8/2011 1:33 AM, Adam van den Hoven wrote:
> Hey guys,
>
> I was reading the blog today and something I read (
> http://blog.whatwg.org/whatwg-extensibility) prompted me to signup to the
> list and get involved again. What follows is not exactly well thought out
> but I'm hoping that it will spark something.
>
> window.atob() and window.btoa() feel wrong, so does
> window.crypto.getRandomUint8Array(length), not because they're not useful
> but because there is no answer to 'what does converting binary data to a
> base 64 string have to do with window?' beyond 'nothing but where else would
> it go?'.
>
> In reality all these belong to javascript, but modifying JS to include them
> is not feasible. Also, what if I don't want to do crypto in my code, why
> should I have all that lying around (not that its a hardship but why pollute
> the global namespace)?
>
> I think that we would all be better served if we were to introduce something
> like CommonJS to the browser, or perhaps a modified version of the require()
> method. This would allow us to move the crytpo and the atob/btoa into
> specific modules which could be loaded using:
>
> <script>
> var my_crypto = window.require( 'html:crypto' ); //or however you wanted to
> identify the 'crypto library defined by html'
> var my_util = window.require( 'html:util' ); // my_util.atob();
> var $ = window.require( '
> https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js' );
> </script>
I really like this approach of using require() for namespacing. Besides 
being semantically more accurate, the approach looks to the future as 
well, in that it does not burden the user with needing to avoid names 
which could end up being co-opted by HTML in the future. (Also, just 
because WhatWG may verify names are fairly unique or unique on the 
public web, does not mean they are catching HTML uses off the web and 
for which there could be conflicts; abdicating responsibility for 
effects of such apps just because it is not within the scope of the spec 
would I think be rather shoddy stewardship of a language relied on for 
many purposes.)

Also, whatever the caching behavior, I like the idea of having a simple 
way of importing remote scripts dynamically, without having to define 
some wrapper for XMLHttpRequest ugliness each time one wishes to use 
such a basic feature, such as to ensure one's application stays modular 
(particularly for reusable libraries where the library does not wish to 
burden the user with needing to specify multiple script tags).

The final and even main reason I like and had wanted to suggest this 
approach is because it is neatly compatible with another idea I think 
the web (and off-web) needs: a formal way to import proprietary objects 
(e.g., such as specific browser vendor(s) or browser add-ons might make 
available), with the potential for fallback behavior, with require() 
throwing distinct exceptions such as "NotSupported" (the default for 
unrecognized modules) or "UserRefused" (for privileged features a 
browser or add-on might wish to make available from the web but which a 
user specifically declined).

Maybe a second argument to require() could be specified to allow for an 
asynchronous callback (where one did not wish to keep checking for the 
setting of a particular property or force the user to wait).

Brett