ECMAScript 6 collection: Set
http://www.nczonline.net/blog/2012/09/25/ecmascript-6-collections-part-1-sets/
Moderator votes: +4
Issue added by Matthew on 2012-09-26
To vote this issue up or down, simply include +1 or -1 in your comment.
-1
Given the complexity and the sheer number of variables, I'd keep ES6 subfeatures out of caniuse.
Maybe it could keep "ES6" as a single entity with all browser currently in "partial support", but that doesn't make a whole lot of sense.
+1
Not necessarily for set, but for ECMAScript 6 in general since it is complete as of June 2015. That said, AFAIK there is no complete implementation in any browser yet, so like @bfred-it said, we would have to make every browser have partial support.
+1 also for general support
+1
-1
Caniuse doesn't need to be everything to everyone. Kangax's table and Node.green already cover this well. Stick to browser APIs and CSS features.
@BillyWM then it should at least be consistent. Currently EcmaScript 5 browser support is shown, we either need to remove that or add ES6. Anything else would be inconsistent.
I don't care if it's inconsistent. Nor do I care of it's immoral or bad for my health. That doesn't matter to me as a user. What matters is that I already have a resource for this information and Caniuse would be a me-too latecomer. It's pretty pointless and I wouldn't recommend anyone put their time into it. (And wait, why should we remove ES5 in accordance with some weird high-concept consistency principle?)
ES6 is much bigger than ES5 as well. It needs to be one entry per feature. That's fine, it wouldn't hurt anything except being a waste of time.
There is also ES2016 (aka ES7) which is actually complete now and yearly ESNext releases from now on. I expect other resources will track this well.
Just did a quick poll of my friends and none of them knew about Kangax's table or Node.green since we are not primarily JS developers and those resources aren't as well-known as caniuse. All of us go to caniuse when trying to determine whether a feature is supported in the browsers we support.
What I'm saying about consistency is that the fact that there is a caniuse entry for ES5 causes one to expect entries for other versions of EcmaScript as well, or at least for EcmaScript features. The fact that there are no entries for these is an unpleasant surprise to the user.
I'm fine with having the ES6 features listed individually as well, as long as there is some sort of documentation for ES6.
One last point:
Caniuse doesn't need to be everything to everyone.
I agree with this statement in and of itself. However, I believe caniuse should strive to document every standard browser feature. The name "caniuse" implies that it is a one-stop source for checking browser support. The user does not expect to only have entries for a certain subset of standard features.
I've just seen this Visualization of Web Platform feature availability by Paul Irish which uses caniuse data exclusively. I think this should further drive home the fact that caniuse is indeed considered a one-stop data source for browser features by many people and that it should strive to be as complete as possible.
I think the discussion has been closed already. Set and WeakSet already appear on Caniuse as links to the Kangax table, so your point that people don't know about it is moot as you didn't even look on caniuse in the first place.
http://caniuse.com/#search=Weakset
@bfred-it I understand that, I was talking about the rest of the ES6 features. That said, you are right that this is off-topic conversation, and this issue should probably be closed since it has been implemented.
+1. Also Map.
any updates?
Now available at https://caniuse.com/#feat=mdn-javascript_builtins_set (and https://caniuse.com/#feat=es6 )
Most helpful comment
-1
Given the complexity and the sheer number of variables, I'd keep ES6 subfeatures out of caniuse.
Maybe it could keep "ES6" as a single entity with all browser currently in "partial support", but that doesn't make a whole lot of sense.