Loyal Opposition to Const, Private, Freeze, Non-Configurable, Non-Writable...

James Burke jrburke at gmail.com
Wed Nov 2 12:57:15 PDT 2011


Accidentally sent this only to Brendan, meant to send to list, resending:

On Wed, Nov 2, 2011 at 10:39 AM, Brendan Eich <brendan at mozilla.com> wrote:
> 2. Web developers both depend on and wish to minimize the size (to zero bytes) of libraries.
>
> 3. Programming in the large, even ignoring security, means many of us want to save ourselves from assigning to something we want non-writable and initialize-only. That's const. Or we want to avoid name collision worries, never mind hostile attacks, on private data. That's private, or else you use closures and pay some non-trivial price (verbosity and object allocation).
>
> (3) implies adding encapsulation and integrity features, on an opt-in basis.

Does encapsulation and integrity mean adding more things to the JS
language or addressing the how JS is encapsulated and run?

The SES and mashup use cases can be used as examples. Are the problems
with the JS language or are they better served by securing not just JS
but the DOM and network calls and having efficient containers that can
communicate?

iframes/the FRAG proposal maybe, or some other JS container entity,
with postMessage async passing of JSON-friendly data might be the way
forward for those things.

Getting those to perform well and perhaps building better APIs around
them might be more effective solutions than to adding more
security/integrity features to JS syntax.

Similar to how focusing on improving the VM container to get JS to
perform better was a better route than adding static type checking
syntax.

The Harmony module loader API feels like another parallel. That is
more of an API to a JS container of sorts with certain isolation
properties. It does not necessarily mean that a JS module syntax needs
to exist for that type of API to be useful.

Since it is an API, a loader API is easier to integrate into existing
systems. With legacy upgrade costs (IE and even older android) and the
possibility for editors to support comment-based systems that allow
type and intellisense support (for quicker turnaround on a deeper set
of errors than the module syntax could provide), I give a loader API a
stronger chance of having a wider impact than module syntax.

> (2) means we keep working on the language, until it reaches some macro-apotheosis.

In any game, it is tempting, particularly for the game designers, to
try to keep tweaking the game to "get better". But that easily turns
to destroying the reason the game existed in the first place, and why
it became popular.

I feel that getting to zero probably means not having a successful,
widely used and deployed language. This feedback is not so helpful
though, right? The devil is in the details. I just needed to get it
out of my system, and the mention of macros set off the "too much game
tweaking" bells.

James


More information about the es-discuss mailing list