[whatwg] Thoughts on recent WhatWG blog post

[Adam van den Hoven]

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>

and so on.

Further, in CommonJS, the library has to export an object in order to make
it available. If we could define things in such a way that the browser
compiled the library independent of the page that loads it, the browser
could cache the *compiled* code and provide that to the browser page. It
would also be necessary to either enforce that these cached libraries be
immutable or that a copy of the compiled code be made available. I couldn't
implement this so I'm not sure how feasible this is but I suspect that
requiring immutability would be the easier to implement.

This would have two interesting effects. 'widgets' loaded this way could
easily be taken from different libraries, this jquery accordion that
mootools tree view. No having access means that it would have to require it
itself, and the normal scoping would keep that version internal to itself.
Second, this could reduce security risks, if the widget requires a library
using some authoritative URL (say from Google's CDN), then some blackhatter
who injects JS onto a page by what ever means could not modify the meaning
of, say, jQuery.ajax to do something else. They would have to compromise the
the source code itself which is a significantly more difficult thing to do.

That is the extent of my conscious thought on the subject. I'm sure someone
has a better idea than I in this regard but I thought I'd throw it out
there.

Adam van den Hoven