I am trying to get a hang of ESx (Harmony?) Proxies. I think I know the basics now, but I don't think I'm capable of taking advantage of them.
Has anyone managed to use them for any good? I don't know any library or whatsoever that has done that.
Proxies are a rather strategic feature that is primarily intended for implementing bindings or advanced library abstractions. Don't worry if you don't see an immediate use case for your own code. In fact, if you did, you should think at least twice before using them -- more often than not they are overkill, and there is a simpler and more efficient way to achieve the same thing.
There are a couple of examples on the original proposal page: http://wiki.ecmascript.org/doku.php?id=harmony:proxies
For more info on proxies, check out this article by Assistant Professor Tom Van Cutsem. Together with Google's Mark Miller, Tom actually played a key role in the proposal of proxies for inclusion in a future ECMAScript standard during his work at the es-lab project.
Further, note that DirectProxies.js has been superseded by the new reflect.js shim.
Finally, check out Sindre Sorhus's negative-array project for an example of simple use case.
UPDATE:
Today, it's almost 5 years since this question was asked. While they have become part of the ECMAScript 2015 standard (aka ES6) in 2015, many browsers still haven't implemented them :
If you want to know which browsers support proxies by the time you're reading this answer, take a look at CanIUse.
Things have evolved a bit! Firefox supports Proxies natively. Using the implementation of harmony-reflect.js, you can try using proxies according to the proposed specification of Direct Proxies. This works with current Firefox or latest Chrome.
Possible use case: You have an object that represents a node in a graph containing an id, type, and arbitrary other user-defined properties. The library drawing this node to the screen wants to save screen-coordinates and similar directly to this node as well. This could possibly overwrite existing properties.
You can now hand over a proxy to the drawing library that catches access to the drawing specific properties of the node. And then, redirect them to an internal namespace property of the node - for example, drawing - to separate this data.
This way, all data according to one node can be kept in a single place. There is no need to copy and transform it around for different libraries and maybe later change the same properties in different places.
Most of the proxy "functionality" can kind of already be implemented in current Javascript. For example, getters and setters can be made as explicit "setXXX" or "getXXX" methods.
The largest up front advantages of proxies I can think of are
Taking existing behavior that currently resides in evil browser objects and allow it to be implemented with pure Javascript. (Great for browser implementors and for people writing shims)
Give you more freedom to change an implementation without breaking the interface (for example, if a property is removed from an object you might put a magic getter in its place to avoid breaking old code).
That said, I'm still curious about what other nice things are possible this new feature :)
First of all I would like to point out that according to this: http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies the direct proxies are the latest specification of the ES proxies and its now part of the draft, which means that this gonna be the ES6 standard, once it goes live, as well as the latest gecko engine: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy using direct proxies already.
I wrote a little code using the new proxies to make the childnodes inside the DOM be available as properties of their parent node and multi-get, multi-set and function multi-call them, similarly to the query-selectors. This cannot be done dynamically without the proxies, and using proxies made this whole code be less than one KB.
Generally talking proxies makes prototyping and meta-programming be dynamic and easy.
Object fail safe access, without eval, for example:
someObj.someMethod.someFunction('param1');
//--> someObj doesn't exist (with fail safe, no error thrown)
I used ES6 Proxies together with ES6 Promises in a library in order to implement Lazy Loading:
https://github.com/Daniel-Abrecht/Crazy-Loading
ES6 Proxies are currently working in Firefox 45 and Edge 13, and Chrome 49.
Related
There are many ES6 features that look great like => syntax, Map object, and a long etc.
To be honest I'm kind of tired of checking if there is support for addEventListener due to ie8 attachEvent, and I wouldn't like that kind of pain coming back to my life.
So how, would you deal with this new posibilities? (or how will you, lets say, in a year or so). Would you not use them for basic actions but to add another layer of extra functions? Would you use it just for apps that you know you will be running in browsers that support them? Would you wait untill there is at least 90% of support?
I understand these are great features but for short to medium term usage it seems that you'd need to double your code checking and fallbacking for support.
Any enlightment about this subject?
EDIT: Please, don't mark this as duplicate. Notice I'm not asking how to check for support, I'm asking if it is wise to start using it, or it is better to wait. I'm also asking if the support check is the best option, not how to do it, or if there are other ways to proced while designing your code.
tl;dr: Make use of transpilers and polyfills.
Whether or not you should use new features primarily depends on your target environment and how exactly you are using new features. E.g. if you are targeting only the latest browser version, then you won't have an issue. Have to support IE8? That could be more difficult.
In general though, you should start using new features as soon as possible, and make use of tools that help you with that.
There are two aspects to look at:
New APIs
New syntax constructs
APIs
New API's can often (but not always) be polyfilled. I.e. you include a library which checks whether certain parts of the API exist, e.g. Map, and provides an alternative implementation if it doesn't.
These alternative implements may not be 100% equivalent or may not be as performant as a native implementation, but I'd say they work for 95% for all use cases.
The nice thing about polyfills is that you will be automatically using the native browser implementation if it is available.
Syntax
Making use of new syntax constructs, such as arrow functions or classes, is a bit more complex (but not much). The biggest issue is that browsers who do not support the syntax cannot even evaluate your code. You can only send code to the browser that it can actually parse.
Fortunately many of the new syntax elements, such as arrow functions, are really just syntactic sugar for things that are already possible ES5. So we can convert ES6 code into their ES5 or even ES3 equivalent.
Several such tools, called transpilers, have emerged over the last one or two years. Note that the transpiler has to convert your code before it is sent to the browser. This means that instead of simply writing your JS file and directly include in your page, you need to have a build step that converts the code first (just like we have in other languages, like C or Java).
This is different from how we wrote JS a couple of years ago, but having a build step has become increasingly more accepted by the JS community. There are also many build tools that try to make this as painless as possible.
One drawback is, unlike with polyfills, that you won't magically be using the native features if they become available. So you could be stuck with shipping the transpiled version for a long time, until all your target environments support all the features you need. But that's probably still better than not using the new features at all.
You can use BabelJS or Google Traceur
You have to include in your build process a step to transform ES6, ES7 code to Javascript compatible with todays browsers. Like a gulp or grunt task. Babel has a list of supported tools here
I was seeing the W3C Document Object Model and excited that different programming languages have to implement their interfaces accordingly. Like other languages, JavaScript also maintains the DOM.
So I'm curious to know about the following questions:
Which versions of javascript implements dom level 1, 2,3 and so
forth.
Are they all implemented in javascript?
Are they implemented by javascript or implemented by ECMAScript and
followed by JavaScript?
And what are the IDL definitions described in W3C DOM: Are they
needed to understand for javascript developers or is that the symbol
of implementation by HTML?
The pedantic answer is "none".
There is no formal mapping of JS iteration to DOM-specification.
In general, JS-versioning has all but been abandoned (save major overhauls), though can be seen as signposts of when you might start to consider feature-checking.
This is because...
Not really, no.
That is to say, yes, the APIs which you will use to interface with the HTML DOM are all implemented in JavaScript...
However, no browser has a stable, feature-complete implementation of either
JS or HTML DOM[1-4].
Because both specs are so large, and ever-changing, different vendors have prioritized different features at different times, leading to patches of incompatibility.
To further this actual answer, the JS spec says nothing of DOM or BOM ("Browser ...") APIs.
This is the reason #1 must be a "No", as different DOM/BOM combinations on different JS implementations leads to the fundamental inability to say "All JS1.7-compliant browsers are DOM3 compliant."
The truth is that no browser is wholly compliant with either spec, and neither spec is the latest, anyway. As for technical-implementation (the code behind the API), there are no rules, so long as the behaviour is well-defined. Some browsers defer to C/C++ for core JS/DOM/BOM functionality, while older IE browsers had an ActiveX layer between the browser and JS DOM access (making touching elements for any reason arbitrarily expensive).
Here's the rub.
Most people would consider them to be different things.
Most people would think "JS is the thing that you use in the browser, to do your scripting.".
Really, ECMAScript and JavaScript are the same thing, and "JavaScript" is a Sun (now Oracle) trademark... how none of us are getting sued is a mystery.
JS/ECMAS knows nothing of DOM or BOM, and it's up to the vendors to include DOM-access in their browser (on a per-feature, rather than per-version basis). It should also be noted that while VendorA might implement a feature from the spec, and VendorB might omit it, VendorC might have an off-standard implementation of it, and also implement a similar but completely out-of-spec feature, as well.
Don't worry about the DOM implementation specifics.
As a JS-dev, you won't need to know or care what a Java implementation of an HTML node might look like.
Even with WebIDL, and moving away from the old-world Java-centric view, as far as day-to-day usage of JS as a language, the DOM-node interfaces are as dry as toast, unbuttered, face-down in a sand dune, unless it's really what you're into.
Even then, it's more for people who make the browsers, and not the people who make things which run in them.
These aren't all of the answers. And while I've tried to remain subjective, I'm sure there's a little objectivism in there, as they aren't wholly cut and dry. I've tried to be, at least, factual.
From an engineering perspective, being careful about how and when you use the DOM in client-side JS is important -- both for making code portable and for allowing each language in the client-side stack to have access to the HTML in question, without doing somersaults in JS, to accommodate, because you built your whole site using DOM construction in JS.
From a pragmatic standpoint, rather than trying to match features to versions, use sites like http://caniuse.com to match features to browser versions. It's much more productive.
And have fun.
Where can I find a list of all the differences between V8 and ECMAScript? For example V8 supports const, which isn't part of the ECMAScript standard.
Edit: Direct answer: Track status of ES5 implementations in progress which indicates the V8 googlecode issues tagged es5
or https://github.com/joyent/node/wiki/ECMA-5-Mozilla-Features-Implemented-in-V8
V8 implements all of ES5 currently aside from a handful of edge cases, and only then in order to be compliant with the majority of how other current browsers handle the given situation.
Because it won't be living on its own nearly all of the differences you'll be dealing with will be in the host environment implementation wrapped around it. For most uses this is the various APIs web browsers provide. As a non-browser example, Node.js provides custom APIs for file system and network interaction. In terms of core language there's just not that much wiggle room. Minus the DOM, JavaScript is a pretty damn simple language to use (part of why it's so awesome) and has a really specific Specification document.
ES5 is an iteration up from ES3 and nearly 100% backwards compatible if not using 'use strict'. After nearly a decade of stagnation along with inability to gain a consensus among major JavaScript engine implementers ES5 was born and limited primarily to cut out and address the worst issues with the language. The extent of mainstream use ES5 is Array extras, Object extras (mainly Object.create), Function.bind, and strict mode (which is entirely about stripping features out), and a handful of natives helpers like built in JSON and base64.
Most of this 240 page specification is spent in laboriously defining every detail about behavior that has existed in JavaScript for almost 15 years, as well as the list of features which will be deprecated and eventually removed (with, various uses of eval, etc.).
Harmony (ES6) is the first real big change we're going to see. ES5 accomplished the goal of getting engine implementations on the same page and gutting most of the problematic parts of JS. Looking forward to ES6, it's time to address some fundamental language issues that require syntax changes to fix. ES6 is scheduled for finalization in late 2013 but large chunks are already implemented in JS engines in order to test them and see how they work in practical usage. The web is a living thing and implementing new standards isn't a matter of creating a new spec and then unleashing it on the world like it is most other industries. Ideas are floated and must past muster at both the implementer level (the guys who write V8, Spidermonkey, JSC, Chakra, etc.) and then the actual user level (user in this case being web developers writing code to run in those engines). Ivory tower dictation just results in lack of use.
Specifically in the case of const: this is currently not exactly defined entirely. It's a keyword with similar but not exactly the same functionality in V8 and Spidermonkey, and has a similar but not exactly the same meaning for ES6. You're probably safe to use it if you expect your target audience's engine to support it currently, but as implemented it wasn't technically part of any official spec. migrating let' andconst'
Beyond that there's "Host Objects" which are exposed by the given engine a JS script is running in. JavaScript existed first as an implementation and second as a specification, so until recently it wasn't obvious to non-experts to know where the diving line is. When it's running in a browser (as is usually the case) the Document Object Model is exposed as a host object for automatic usage. The functionality of the DOM is largely described using IDL and is under the purview of the W3C. The multitude of specification implementations encompass 6 top level sections, almost 50 separate working groups, and around 1000 separate specifications. These are interfaces exposed to JavaScript but completely ungoverned by the requirements of any JavaScript specification. The DOM encompasses a huge space of described functionality and continuously changing implementations thereof.
Are there general reasons not to deal with Document's and Element's prototype?
I like to create my own little framework, because my current project doesn't need the mass of features of the existing frameworks.
I don't need to support browsers which don't support Element/Document-constructor and also will not execute scripts that are not under my control.
So would you recommend to extend the prototype or should I go the usual way and create own objects from Element/Document?
Do you plan to extend default DOM elements? If so, please don't. Juriy Zaytsev (aka Kangax) clearly describes why not in What’s wrong with extending the DOM.
Yes, unfortunately. It would be lovely to be able to add functionality by fiddling the DOM prototypes, but in practice it's just not reliable given today's technology.
Document, Element and others etc may be ‘host objects’ implemented by the browser with no ability to fiddle with their prototypes. Host objects may potentially have many other weird behaviours that a native JavaScript object wouldn't. DOM Nodes are host objects in IE6-7 and many older, niche and mobile browsers.
Even if they are implemented as native-JavaScript objects, there is no standard (yet) that described where the constructor-function for them is to be found, for you to go fishing about in the .prototype. Document, Element and so on are just W3 DOM interface names, they say nothing about what the implementation objects are to be found.
It happens that modern browsers (IE8 native mode and recent versions of Firefox, Opera and WebKit) do make constructor-functions available so you can start adding methods to Document or HTMLElement. But even then, there are differences between what objects are exposed, as not every browser provides the DOM interfaces with implementations under the same names. (The subinterfaces/implementations of NodeList are particularly troublesome.)
You can see how DOM prototyping has worked in practice by looking at the Prototype.js framework. When it works, it's super smooth. But because you can't prototype everywhere, you end up with some extremely ugly stuff where the framework has to deal with places prototyping won't work by copying methods into every instance of a Node. And then you've got the situation where your code might forget it needs to force this ‘augmentation’ and so it might work or not work depending on whether some other function happened to augment the same node before. This leads to really horrible browser-specific, interaction-order-specific, race-condition-prone debugging pain.
If you can limit your prototyping work to a few well-supported interfaces, and give up on all but the latest browsers, you can probably get away with it.
I was wondering why JavaScript has such a confusing API. It is not consistent across browsers, there is a different way to get the value from each type of form input, and it is unforgiving of mistakes. jQuery has changed my life because its API is so much easier. Why did the creators of JavaScript not set up the API like that in the first place?
The JavaScript API, itself, is consistent between browsers (and is defined by ECMA, though originally developed by Netscape). The difference between browsers is the document object model (DOM). The DOM was developed independently by the different browsers, originally IE and Netscape, but now IE, Mozilla and others. The W3C has joined to try to consolidate the differences and create a common standard. For backward compatibility, the old differences remain. And, yes, jQuery has gone a long way toward making the DOM easier.
Creators of Javascript did not setup the API, since Javascript is a language, not an API.
What you are refering to is the Document Object Model (DOM) which is the document manipulation API. It is a standard specified by the W3C and its behaviour should be consistent among browsers.
Unfortunately, some parts were badly specified, some other parts are badly implemented by browser vendors. Additionally, vendors extend this API with proprietary extensions that may never be added in the standard but that are very popular (like document.all in its time).
That's why today's API in browsers are so inconsistent.
I think most of it is the remnant of the browser war. Javascript had a very troublesome history, made of a total war between microsoft and netscape, with Sun involved as well. Javascript is actually a very nice language. It has some critical design mistakes, but you can work around them. As for the API, you can use a good wrapping library that hides all the complexity and uses the most appropriate API.
One important suggestion, if I may. Don't fight it, nor try to use it masked as something else. Embrace it even with its defects. Once you know them, you won't step on them anymore, or if something is fishy you will find the problem easily.
I'll bite. Check out Douglas Crockford's videos (http://javascript.crockford.com/), he does a good job explaining why some of JavaScript is in the situation that it's in. (http://yuiblog.com/blog/2007/01/24/video-crockford-tjpl/)
This doesn't directly answer your question, but:
A lot of people are bothered by the between-browser inconsistencies. While a few folks become really good at ironing out the differences in their own JavaScript code, most can't afford to spare the time. This is why there is such a profusion of frameworks available to do the dirty work for you. JQuery is the most popular of these, I think, and I'd recommend it to you as an alternative to swallowing a lot of Aspirin for your headaches.