[whatwg] Thoughts on recent WhatWG blog post

[Aryeh Gregor]

On Mon, Feb 7, 2011 at 6:15 PM, Adam van den Hoven <adam at littlefyr.com> wrote:
> But that is exactly what has happened, or perhaps some existing pollution is
> simply being codified.

atob() and btoa() were first implemented years ago, I guess by
Netscape, and are supported in all major browsers except IE.  So they
were already in the global namespace (except if you only care about
IE).

> You could collect them into a single global object, and that was something I
> though about, as well. But I think that this is a more generally applicable
> solution. There are many libraries that do nothing but load javascript from
> within javascript. They all do it by writing a script tag to the DOM. I
> believe this is a code smell. Having a consistent way to do this sort of
> thing would improve the lives of a lot of code developers and create some
> consistency between what is happening on the server side as well.

It would certainly make sense to have some way to include JavaScript
other than adding <script> to the DOM, but I don't think it needs the
namespace/module-style functionality that's part of your proposal.
Your proposal seems to be trying to do several different things at
once, not all of which look necessary.

To make a good proposal, you need to first clearly identify all the
problems you see with the status quo, in the form of use-cases -- "I
want to do X but can't", where X is something of self-evident utility.
 Only once you've clearly identified the problems is it useful to talk
about solutions.  Mixing the problem statement together with your
solution makes it harder for everyone else to consider alternative
solutions to your problems.

> It seems to me that allowing a mechanism by which compiled javascript to be
> cached between page requests should be a benefit.

What does "compiled" mean here?  Browsers these days do compile
JavaScript to machine code, but if they could cache the compiled form
with your proposal, they could cache it without your proposal too.
How does your proposal benefit caching compared to the status quo?

Or do you mean "compiled" as in JavaScript minification?  In that
case, I don't see how it's relevant to browser-level features, since
browsers don't know about minification.

> Inserting a script element is great, so long as you're writing code that
> only gets run in a browser.

What non-browser agent are you thinking about here?

> The number of well behaved libraries is very limited and generally they
> don't work well together.

Jonas says this is being worked on elsewhere at the language level, so
no need to consider it here further.

> Its quite simple. If you have a page that contains user contributed content,
> you spend lots of time trying to prevent people from injecting bad code. For
> example, if you were to bypass the filters (which unfortunately does happen
> from time to time) you could redefine jQuery.ajax to send a copy to where
> ever.

You could also steal the user's cookies and send them off to your evil
site without using jQuery at all.  How does access to jQuery
exacerbate the attack?  Once you can run JS, you don't need libraries
to carry out typical attacks.  Put another way, why would an attacker
even bother trying to use the libraries you've loaded instead of just
running whatever code they like directly?