I once participated in a web security research project where we used ES6 Proxies to sandbox third-party scripts, basically controlling what DOM operations they're allowed to do in a whitelist. This is relevant when you include sketchy advertisement scripts or scripts you don't trust (e.g. "trusted" scripts but delivered through an untrusted CDN). By default, no operations were allowed and by whitelisting until there were no more errors, we managed to effectively completely sandbox jQuery, Google Maps and Google Analytics. None of these scripts were allowed to execute more operations than the ones exactly required for them to function. Proxies were an elegant way to intercept getters and setters on window, document, location, etc...
Are you able to link to the research? It sounds like a native-JS version of NoScript, which is really interesting (apologies to the dead comment under me which asked something similar)
This is interesting, I hadn't heard of Oasis.js. Both approaches try to solve the same problem, i.e. manage to sandbox third-party scripts. However, the implementation is different: oasis.js uses iframes, we chose for not using iframes, mainly because iframes are not enough to limit access to security-sensitive APIs such as XHR, Geolocation and local storage.
One constraint for Oasis.js when picking a technology was the compatibility with IE8. So we use modern technology everywhere we can, but we have to find a way to polyfill them for older browsers (mostly IE8/9).
Articles like this, about up-and-coming features in JavaScript, usually make me think two things:
1) JavaScript is starting to become a "big" language, in terms of number of keywords and syntax;
2) While many of these things that JavaScript is (finally) gaining are things we're familiar with in other languages (and have empirically found to be useful), they often seem somewhat more unwieldy, fiddly, and complicated in JavaScript.
As a handwavy example, Ruby generally has most of the stuff these sorts of articles describe, and it can be complicated at times, but usually (in my experience) only when you're trying to do something complicated anyway; in JavaScript, a lot of it looks quite complicated out of the box even when you're doing something that ought to be simple.
There are many JavaScript developers out there, some with years of experience, who are confused about, say, `var Foo = function() {}` versus `function Foo() {}`, or the difference between `new Foo()` and `Object.create(Foo.prototype)`. To be honest, it slightly worries me that even more complexity is being added at this point.
JavaScript has a lot of complexity and little gotchas. I often compare the simplicity of Go with JavaScript and wish JS were more like that, but I still find myself enjoying JavaScript. I hope that "use strict"; evolves to further limit the bad pit falls even experienced developers can get stuck in. Some of the new features like isPrototypeOf can replace the old behavior, like instanceof. I would hope that once browsers start supporting more of the new things we all migrate to using them, if they're implemented well.
Good thing that this is all coming to Javascript. But I can't help but think we're in bizarro land when the main language of the most ubiquitous medium of the 21st century is only getting all that rather basic stuff (at least by all the other languages' standards) in 2015 or something...
Everything there besides Proxies and Symbols is already in common browsers, and I can't say I'm familiar with Proxies and Symbols in other languages (not to say some other languages necessarily don't have them, but I don't think most users consider them basic or encounter them often).
I'm a bit puzzled what symbols are. If you want a unique thing that !== anything except itself, make an empty object. It seems to me: var foo = Symbol("foo") ought to let you dereference via bar.foo vs. bar[foo] (the latter shouldn't even work!) or it's not what it seems it wants to be.
Symbol has other traits beyond just not being unique. Properties added via symbols are not iterated over in a for in and do not show up in calls to Object. getOwnPropertyNames()
What a convoluted mechanism! But where do you keep your reference to the symbol to keep it private? Anywhere you keep it (e.g. in a closure somewhere) that's private doesn't need symbols, so what problem does this solve?
And surely in your private context, bar.foo should still work.
I think the slow browser updates that existed prior to Chrome might have contributed to a lull in developing the language. Some of these features can't be fixed for old browsers with a polyfill, but now that updates are happening quicker and there's a lot of excitement around the language I hope we see more of these.
I don't think there were ever any "slow updates" to Javascript, except maybe in the period of IE5/6 dominance to Firefox 1.0. In the Browser Wars, Microsoft and Netscape competed to add features as fast as possible. Firefox still has many additional features in its JS engine that aren't in ECMAScript (for each, coroutines).
I'm more concerned about adding features without fully considering the consequences. When you add a feature to Javascript, it's there forever. Rushed feature dumps are how we end up with things like the Web Audio API.
True, the early period had a furious pace of updates. I guess I was referring to the era of ES6, that lasted a long time. I think Microsoft at one point actually said that IE6 was the final browser and they wouldn't release a new version. IE6 was amazing when it first came out, but it became a blight in the end that hurt more than it helped.
I like that idea, but with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy and then in your code you can access via the . notation, like:
var obj = new Proxy(
{foo_: "bar"},
{get: function(target, name) {
return target[name + "_"];
});
console.log(obj.foo); //logs "bar"
Of course maybe you'd do something a little fancier than just return the value, like return null for property names with _ to prevent accessing private variables. I don't know what the performance of Proxy will be like, but it's an alternative to getters and setters and lets you have a fall through for things you haven't defined.
What I'm really excited about is reactivity on objects for setting and getting without using functions. You could have your setter trigger events without forcing someone to use a set function like you have in Backbone.
I think we'll see an entirely new set of model libraries because of these new ECMAScript 5 and 6 features.
I'm not yet excited about these getters and setters and new features in the latest JavaScript. I've put a lot of time and effort into developing ECMAScript (JavaScript) 3 patterns that overcome various limitations, and have got accustomed to the idea of deploying ECMAScript 3. In terms of providing an API, getters and setters will be very useful. It will be good to have out-of-the-box JavaScript functionality that does not require extra code to use, like various methods I use to overcome the ECMAScript 3 limitations.
Does anyone have an estimate for when ECMAScript 6 will be widely deployed across browsers, almost ubiquitous? I would say now it's safe to use SVG in many situations on the web that would not have been OK a few years ago, I'm curious about when the tipping point will be with ECMAScript 6.
Anecdotally, recently my customers have been a lot less interested in supporting older versions of IE, and I have used SVG in a couple of situations, and that would not have been OK a few years back. I have not been closely following the developments of ECMAScript 6, it has seemed like it will be a while until it's widely deployed. The only things I have found practical use for are typed arrays, and I have been using them in node specific code rather than in code that I expect to run across browsers.
Though I am interested in the latest developments in JavaScript, my focus will still be on what can be done with the JavaScript available in almost every browser. I am also interested in making use of getters and setters in my code but being able to compile it to ECMAScript 3, I may be able to do some relatively simple text replacement rather than having to parse and compile an abstract syntax tree.
Kangax's ES6 Compatibility Table tracks the implementation status for many browsers, though Chrome's ES6 support is hidden behind a pref: chrome://flags/#enable-javascript-harmony
> with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy
Doable with "old" JS. Consider this function:
function prop(name, gNs) {
var _name = '_' + name,
get = gNs && gNs.get,
set = gNs && gNs.set,
undef = function (v) { return typeof v == 'undefined'; },
if (get && set)
return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = set.call(this, x), this); }
if (get && !set)
return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = x, this); }
if (!get && set)
return function (x) { return undef(x) ? this[_name] : (this[_name] = set.call(this, x), this); }
return function (x) { return undef(x) ? this[_name] : (this[_name] = x, this); }
}
Pass `prop` (a) the name of a property you're defining getter/setter methods for and (b) an object with any custom getter/setter you might care to define (or neither, if you like), and it'll return a function that will act as both which you can assign to a prototype.
I like that, but you'd still have to call a function to get the properties though and this wouldn't prevent anyone from accessing those properties directly.
True enough, and if privacy is a must have, my implementation is a non-starter.
I tend towards the (somewhat unpopular and certain arguable) opinion that need for privacy via a runtime-enforced mechanism is overrated... give us developers using an API/library effective/well-documented methods that do what we need and warn us when we shouldn't touch something with a convention (like an underscore), and usually we're happy to leave the black box closed.
It's usually when abstractions leak or implementations aren't complete that we're tempted to tinker across boundaries, and when that happens, the lack of a privacy enforcement mechanism may not be the real problem.
(OTOH, they can indeed help keep some bad situations from getting worse, and when trusted code is mingling with untrusted in situations like web mashups, privacy-enforcement can be really helpful for security...)
I don't know why, because I haven't thought through it enough yet but I really like the idea of freezing or protection in the case of a reactive data model like Backbone models. I'm thinking of maybe writing up some quick implementation where you provide a schema and you get a reactive object that is frozen and has a catch all. Just want to see where that goes.
This foo.foo cannot be deleted. It cannot be written to. So it's a little different. But really I was just demonstrating the use of Object.defineProperty in a non-verbose way. You can try this out yourself, I made a jsfiddle: http://jsfiddle.net/btipling/q1v3fn20/
Regarding your second question, defineProperty is a method on Object, not Object.prototype. "Instances" as you might call them only have direct access to methods found on their prototype chain. You can think of Object.defineProperty as a static method on Object if that helps. I wrote a post about "this" which includes some information about prototypes:
I wasn't aware that the Firefox nightly had Symbol, I will download Firefox nightly later and update the post, I should have Firefox nightly anyway. Thank you!
> You can use Object.getOwnPropertyNames to get all the properties defined on an object. This might be a nice alternative to a for in loop.
Careful. These have different behavior for own properties which are not enumerable. A for-in loop doesn't include them, but Object.getOwnPropertyNames does.
CoffeeScript is not a static language - unless I'm misinterpreting what you mean by "static".
And the compilation is pretty light. The syntax is different, but for the most part the semantics are 1:1 with Javascript.
Having said that, any compile-to-language is going to introduce problems that need to be solved. Source maps and short watch+compile times have basically eliminated any problems for me.
