2 ms·
Unfortunately it's the name we're stuck with though, and it makes a lot more sense because ECMA releases are yearly. Not judging, but if high profile articles
by vmasto 9y ago
Unfortunately it's the name we're stuck with though, and it makes a lot more sense because ECMA releases are yearly.
Not judging, but if high profile articles and browser vendors started addressing it correctly we wouldnt have any issues migrating, more syllables or not.
- ergothus 9y agoI'm a touch confused...are you saying that if everyone used the year-based nomenclature, the inconsistent support would go away? Today in 2017 I have some ES6/ES2015 features I can use as well as some ES7/ES2016 features, but there are also other ES6/ES2015 that I can't count on being supported, and quite a few ES7/ES2016 features I can't count on. How are these problems alleviated if we change the name we use? Or have I totally misunderstood your point? Side Note: I'm not a fan of using a year for the same reason we (i.e. most everyone) stopped using it for versioning - That previous iterations have been done on a yearly cycle does not mean that future iterations will follow that schedule. That, however, is a side argument that neither of us touched on.
- vmasto 9y agoJust talking about the name. You can see how this is confusing, here's a recent one just from today by Craig Federighi https://twitter.com/feross/status/871839072590979076 https://twitter.com/feross/status/871839072590979076
- int_19h 9y agoI'm pretty sure this ship has sailed for ES6. It's been referred as such while it was in development for so long, it's here to stay. The next one might be different. But they really need to come up with a better than than "2017" or whatever. There's no similar problem with C or C++, and that's likely because they use 2 digit years, not 4 digit - C++17 isn't super short, but it's not a mouthful.