Accidentally sent this only to Brendan, meant to send to list, resending: On Wed, Nov 2, 2011 at 10:39 AM, Brendan Eich <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
