ECMAScript 2017 Language Specification
ecma-international.org
ecma-international.org
* Object.values/Object.entries - https://github.com/tc39/proposal-object-values-entries
* String padding - https://github.com/tc39/proposal-string-pad-start-end
* Object.getOwnPropertyDescriptors - https://github.com/ljharb/proposal-object-getownpropertydesc...
* Trailing commas - https://github.com/tc39/proposal-trailing-function-commas
* Async functions - https://github.com/tc39/ecmascript-asyncawait
* Shared memory and atomics - https://github.com/tc39/ecmascript_sharedmem
The first five have been available via Babel and/or polyfills for ~18 months or so, so they’ve been used for a while now.
[0] https://github.com/tc39/proposals/blob/master/finished-propo...
I consider the fact that a stupid-simple package was depended-upon by so many mature libraries as an indication it should be a language feature.
Working with network protocols I find myself needing padding functions all the time, and there isn't really an elegant way to do so inline, so I welcome this addition.
Sure, left-pad being deleted was what resulted in most people's problems but this was just the fallout from npm Inc forcibly reassigning an actively used package name from a major open source contributor to appease a company that didn't even threaten them directly.
Unfortunately neither the npm module nor the browser version really do what most people want and string handling in javascript is still a minefield.
'\u{1F4A9}'.padStart(5, '1') => "111" // oops (\u{1F4A9} is at the end of this, HN filter)
'\u{1F4A9}'.length => 2
[...'\u{1F4A9}'].length => 1 //WTF?
'mañana'.padStart(7, '1') => "1mañana" // ok
'man\u0303ana'.padStart(7, '1') => "mañana" // oops
'man\u0303ana'.length => 7
[...'man\u0303ana'].length => 7 // WTF? Why doesn't this match the behavior of [...'\u{1F4A9}'].length ?
'man\u0303ana'.normalize('NFC').padStart(7, '1') => "1mañana" // OK
I do understand the unicode issues here, but the inconsistency in the APIs from a user perspective and lack of any fully cross browser support for sane string processing in Javascript means we still have only a few options:
1) Don't do string processing in javascript at all.
2) Include a library to make it sane, these are usually huge as they usually need large lookup tables.
3) Accept that things won't always be correct.
This is one example but the lack of a sane standard library in Javascript is one of the biggest problems the web has right now. I'd be curious to know how many bytes of JS are loaded on the average website just to work around the lack of standard library support for basic functionality, I'd bet it's a very large number. Another fun one: Try to parse a URL and append extra query params to it, correctly.
That's not what it is. Look again, and pay attention to the ... part.
You're misunderstand the code, it's using the spread operator on a string:
[...'word'] => ["w", "o", "r", "d"]
What is being demonstrated is that under the hood, javascript stores astral plane codepoints as surrogate pairs and strings operate on 'characters' which is why '\u{1F4A9}'.length => 2. But, when the spread operator is applied to a string, it breaks up the string into codepoints, not characters. This is also why [...'man\u0303ana'].length => 7, the combining tilde is a separate codepoint.
This is an example of how wonky string processing in JS is, [...string].length is actually the most straightforward way to get a count of codepoints in a string.
The key thing to remember is that iteration over Unicode strings only makes sense as iteration over code points, not UCS-2 characters, not bytes, not grapheme clusters. The JS String iterator was very deliberately made to iterate over code points. That length reports UCS-2 characters is a historical mistake. That padding is operating on UCS-2 characters is probably a reflection of the fact that the operation isn't well-defined beyond ASCII.
There are tons of situations where interating over grapheme clusters is what you want to do.
'mañana'.padStart(7, '1') => "1mañana" // ok
'man\u0303ana'.padStart(7, '1') => "mañana" // oops
'mañana'.length // 6
'mañana'.length // 7
This is a major improvement: double-wide and stacked characters have been there since ES3, but now the language is providing standard tools to work with them.
I think it would be less confusing to define .length as the number of characters and have an additional .size method returning the number of bytes (I'm assuming that's what .length returns, if not it's even more confusing).
Of course, that already wasn't done - meh.
It's actually not the number of bytes, it's the number of...'codepoint pieces' is what it could be called I guess? Javascript's language level string implementation is something like UCS-2 with the addition of surrogate pairs being allowed, but counted as separate 'characters' for things like length and index access. It's some twisted middle ground between UCS-2 and UTF-16.
I understand a need in some contexts to distinguish between a character and its subsequent modifiers - but I do not see such a context here.
Design by committee?
If it were so simple...
`normalize` doesn't exist in IE at all and not in Safari < 10 so to take this advice we need a polyfill. As you may expect, polyfilling unicode normalization isn't pretty, it requires a massive lookup table.
The best polyfill out there, unorm, clocks in at ~38KB gzipped. Now, keep in mind there are a half dozen or more iframes on many web pages, each would have to load their own copy and it's unlikely the caching would overlap for a number of reasons. Also keep in mind that code builds / loading based on browser support isn't realistic in many cases, so if I want to use normalize, everyone pays the network bandwidth usage penalty not just the IE11 users. Of course this is only one part of the problem, want to iterate over graphmeme clusters? That'll be another massive library. Etc, etc.
The browser JS ecosystem is full of these problems, it's not just text processing. If you've ever wondered why a site needs to load 2MB of javascript, it's because that's about what is needed to create a cross browser compatibility layer and a reasonable standard library.
Switch to loading it via JS modules and using HTTP2 to keep connection lag low on cellular 3G connections? I agree, more needs to be done to promote these kinds of edge cases. A similar problem occurs with locale-aware date parsing and formatting.
As to your last bit, I tend to favor encodeURIComponent and have done it correctly... the main reason, is to avoid "+" vs " " in query strings.
I'm basing this on the assumption that the desire for trailing commas is making editing easier and reducing noise in diffs.
Just curious if there are niches where people are spending a lot of time manually editing JSON or if the use case is something else entirely.
I love them in code, despite initial resistance.
const hello = {
, 'one'
, 'two'
, 'three
}
const hello = {
'one',
'two',
'three',
}
...but in my experience usage of ES6/ES7/ES8 as names far outweighs usage of ES2015/ES2016/ES2017. Calling it ES2017, while technically correct, would in my opinion be far more confusing to most people than calling it ES8.
I personally prefer the terse version, but there are advantages to using the year-based naming.
What matters is the ongoing standardisation process. New JS features are proposed, then graduate through four stages. Once at stage four, they are "done" and guaranteed to be in the next annual ES edition write-up. Engines can confidently implement features as soon as they hit stage 4, which can happen at any time of year.
For example, async functions just missed the ES2016 boat. They reached stage 4 last July [1]. So they're officially part of ES2017 – but they've been "done" for almost a year, and landed in Chrome and Node stable quite a while ago.
[1] https://ecmascript-daily.github.io/2016/07/29/move-async-fun...
ECMAScript is more a thing for backwards compatibly.
Things get proposed and HAVE to be implemented in runtimes before they get into ECMAScript.
They want to know if things can be implemented nicely before they standardize them.
This is more a game between ECMA and Browser vendors, JS compilers (like Babel) and vendors of other JS runtimes like Node.js.
If you are an enduser, i.e. a user of Babel, it's more a question of the support you get from the Babel devs.
They say JSX is on? No matter what ECMA says, as long as Babel gets this compiled into ECMAScript conforming JS.
That means that you're not imposing an unusual configuration on downstream users, and depending on the environments you support, at some point you won't even need to run Babel at all.
With IE11 approaching end of life, and more and more sites dropping support for it, we're rapidly approaching a time when we can assume the vast majority of users are on a modern, evergreen browser. And the last version of node that didn't have full ES6 support just went out of long term support.
That's what stage 4 means. Completely finalised. Appearing in the next 'edition' document is just a formality. Once it's stage 4, it's effectively in the standard. If you restrict yourself to stage 4 features, you have all the same guarantees you mentioned. If you restrict yourself to the last published edition, you'd have missed out on async functions until almost a year after they were completely finalised, for example.
> the last version of node that didn't have full ES6 support
No version of Node supports ES6 imports yet, which is a huge part of ES6, and it won't be supported for at least another year. This emphasises the point that following ES editions is pointless.
All that matters is what combination of individual features is supported by your engine. Thinking in editions has pretty much no benefit.
A spec is never symbolic. If a library claims it implements ES2017 then its consumer expects the library to follow the entire spec.
And JavaScript engines don't implement ES editions, they implement ES features. These features now have a five stage process ending with their inclusion in the next edition of the language spec.
Most engine vendors want to be on the bleeding edge, so they start implementing features long before they are fully stable.
The reason the editions are symbolic at this point is that they are just snapshots of the collection of features that have reached stage 4 by the time they are published.
People writing internal tools.
People writing software for tech-savvy users with modern hardware.
People using babel to compile to a supported version.
You, several years from now.
The inclusion of features in the standard is an important part of the evolution of the language. But it's just one part. More recent browsers have already implemented many of these features, and there will come a day when they're pretty much everywhere. Just be patient.
(source: I'm old and remember the era when our sites had to work with Netscape 4 due to its market share)
Not so long ago, we had to support IE8. Before that, IE6. If you go back a little further IE5 for Mac was the biggest pain point. Before that, Netscape 4 and IE4, which were often mutually incompatible.
There will always be a legacy system many people have to support at any given time. But over time the number of people that has to worry about it will shrink along with its market share. You probably don't see many support tickets about Netscape 4 these days anymore.
Having these standards today means the next generation of legacy browsers will support them when you're stuck with them in the future. That you're not chasing the bleeding edge doesn't mean you don't benefit from these advancements, just that you'll do so with a delay, and likely far less gradually than those privileged enough only to care about the evergreens.
CSS custom properties are interesting because they are dynamic. CSSNext just translates them statically, hence why it restricts definitions to `:root`. So the only thing CSSNext gives you over other "variables in CSS" preprocessors is that the syntax looks like actual CSS.
But good luck swapping out colors at runtime without recompiling the generated CSS, which is trivial with "CSS-in-JS" solutions like styled-components or glamorous.
EDIT: Also CSS variables are often advocated with `@apply` replacing preprocessor mixins. But `@apply` is pretty much dead outside faux-css preprocessors: http://www.xanthir.com/b4o00 so you probably shouldn't rely on CSSNext for this unless you understand that even if it looks like CSS what you're writing won't necessarily ever work in a browser.
Object.entries(obj).map((prop, value) => ...).reduce((newOdj, [prop, value]) => newObj[prop] = value);
Object.entries(obj).map(...).reduce((acc, [prop, value]) => ({...acc, prop:value}))// eslint-disable-line your-rule-to-ignore
Object.assign(acc, { [prop]:value })
I like to write it this way, using as much syntax sugar as possible:
const mapObject = fn => obj => Object.assign( ...Object.entries(obj).map( ([key, value]) => ({ [key]: fn(value) }) ) );
It's not possible to say this on the internet without being rude so, apologies, but, why code like that? It genuinely was a struggle to parse (in my brain) your oneliner of code there. If I found this in our code base it would be a huge waste of time and energy.
I said I like to write it this way, not that I always do it.
> why code like that
It's a fun exercise.
> it would be a huge waste of time and energy
I don't fully agree on this: from the name and signature it's pretty clear what the function does, so you don't need to waste time "parsing" the details. And with unit tests it is also very low-risk.
But that's speculative, in a real project I'd just use lodash.
To your point, though, this one is pretty esoteric.
So you have weird things like `'foo'.map()`, `( 42 ).map()`, `new WeakMap().map()`, `false.map()`, etc.
'foo' is a string and can be iterated over.
42 is a number that can be provided to a function. Not sure about this one tbh. Could be useful for passing a number to a function if-and-only-if the number is valid (not NAN)
WeakMap(), I don't know what it is but I assume it's a map that can be iterated over.
mapping 'false' would fit well the Maybe monad.
WeakMap is a new-ish type whose keys are objects. The references to those objects are weakly held, which means that an object `x` whose only reference is a WeakMap key will still be eligible for garbage collection. They are non-iterable for exactly that reason.
Also: how do you iterate over `false` or a function? What about user-created classes?
There are so many cases where the behavior would either be nonsensical or at least unintuitive that (in my personal and completely subjective opinion) they outweigh the slight convenience of being able to "map" a plain old JavaScript object.
Granted, in JavaScript maybe this wouldn't make sense.
https://kripken.github.io/emscripten-site/docs/porting/pthre...
Granted it may be limited to consumption via Emscripten, it is nevertheless now within the realm of possibility.
For this that cannot grok the gravity of this -- proper concurrent/parallel execution just got a lot closer for those targeting the browser.
Not only are these difficult to reason about and program against, introducing locks over mutable memory causes performance problems and are a speed bump to high concurrency. (Heck, just yesterday on HN, a story was published "24-core CPU and I can't move my mouse" [0] - the culprit? Low-level locks.)
Creating too many threads introduces performance problems, too, thanks to CPU context switching; pools must be created and threads reused from those pools.
And now in JS land we're trying to introduce threads and mutable shared memory? Are we just going to learn these lessons over again?
[0]: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and...
Joe Duffy, who had originally done quite a bit of initial work on the TPL, argues in favor of this paradigm[0] of raising the abstraction level.
I feel like introducing the low-level tools without providing a raised abstraction level may be beneficial in the long run (you need low-level tools to build high-level abstractions), however, without these abstractions I suspect a generation of JS developers will need to re-learn all the multi-threading lessons of the last few decades.
[0]: http://joeduffyblog.com/2016/11/30/15-years-of-concurrency/
I'm not surprised that TPL author discourages mutable shared memory and locks - this is the conclusion to which anyone dealing with concurrency a lot arrives sooner rather than later. But that's orthogonal to TPL design.
Now, PLINQ does attack the whole mutable shared memory thing head-on. But it's a much higher level of abstraction on top of TPL.
It would be nice if EcmaScript could give us a middle ground -- ability to use 32/64 bit integers without having to go all the way down to asm.js or wasm.
But yes, 100% agreed; this is a major pain point of the language right now. Nice to hear that there's finally some movement on fixing it (as per arthurdenture's comment)!
I'd like to see TC39 tackling the big problems of JS like the lack of static type checking. I'm tired of looking at a method and having to figure out if it is expecting a string, or an object.
We had EcmaScript4 about 10 years ago with plenty of great features but TC39 killed it. And yeah, it probably made sense since the browser vendor landscape was very different back then. Today it would be possible to implement significant changes to the language much like the WebAssembly initiative.
For example: https://vuejs.org/v2/guide/typescript.html
How well major breaking changes like that work out on the web can be seen by the massive success (cough) of XHTML -- I dare you find me one notable site correctly using XHTML with the appropriate MIME type (rather than just sending XHTML as HTML tagsoup using `text/html`).
Web Assembly works because it is not a breaking change to JavaScript. It's actually defined in a way that is mostly orthogonal to JavaScript -- it shares some of the APIs but most likely there will be (low-level) APIs only Web Assembly code can use and some (high-level) APIs that only exist for JS.
I can find some references to "Javascript" being an implementation of ECMAScript, but doesn't appear to true [1]. Mozilla's implementation is SpiderMonkey, Google's is V8, and Microsoft has Chakra and JScript.
[1] https://en.wikipedia.org/wiki/ECMAScript#Implementations
"Eich commented that "ECMAScript was always an unwanted trade name that sounds like a skin disease.""
Netscape created a language which they called LiveScript when it first shipped in a beta build, largely influenced by Java. By the time of Netscape Navigator 2.0 beta 3, they had negotiated a license for the Java name from Sun and renamed the language JavaScript (and, as wamatt pointed out, Sun owned the JavaScript trademark, now owned by Oracle following the Sun acquisition).
IE3 shipped a reverse-engineered copy of JavaScript, which they called JScript because they didn't have a license to the JavaScript trademark.
Later in the same year that Netscape Navigator 2.0 and IE3 shipped, Netscape submitted a specification of their JavaScript language to Ecma. What followed, as far as I'm aware, was a bit of a debate about naming: JavaScript was basically out of the question due to it being a Sun trademark, JScript was a MS term that Netscape didn't want to legitimise, and hence the compromise was ECMAScript (why this uses the pre-1994 capitalisation of Ecma is a good question!).
So, essentially, JavaScript, JScript, and ECMAScript are three names for the same language.
This then gets a bit complicated as Netscape and then Mozilla referred to ECMAScript revisions as JavaScript versions, and then started adding non-standard extensions as new JavaScript versions, though they've basically killed that now.
I believe that's backwards. Javascript was based on Scheme & Self, the Java resemblance is only superficial; added later for marketing purposes when they picked up the JavaScript name.
This is a little wrong/misleading.
ECMAScript is the specification; JavaScript, JScript, and ActionScript, are various implementations of the specification. Each implementation provides additional features not described in ECMA specs, such as access to ActiveX and the local computer in JScript.
As far as I'm aware, MS has used JScript to use to both their original implementation and the language it implements, as well as JScript.Net being both the implementation and the language it implements. I can't find any citation for this, however.
Adobe considers ActionScript a language, with implementations including AVM.[2]
[Edit:] I just realised you could also potentially mean "implementation" insofar as they define a host environment for ECMAScript, except JavaScript especially does not: just look at the difference between SpiderMonkey-in-a-browser and SpiderMonkey-on-the-CLI.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Abou... [2]: http://wwwimages.adobe.com/content/dam/Adobe/en/devnet/actio...
- Oracle own the trademark on JavaScript (though buying what was left of Sun, through the Sun Netscape Alliance)
- Nobody trusts Oracle
A good idea proposed is just to call the language itself 'JS' and have it not stand for anything.
Javascript, JS, ES2015, ES2016, ES2017, ES5, ES6, ES7, ES8, Ecmascript 2015, Ecmascript 2016, Ecmascript 2017, HTML, HTML5, CSS, CSS3.... etc.
I worked as a recruiter so I know it's necessary because 1: recruiters ctrl+f like a mofo, and also your resume won't pop up on linkedin/ other sites if you don't hit their tags, and 2: recruiters will scan the "technologies" section to make sure you "have" the language that was given to them on their spec sheet.
Spec sheet will look like:
Web Developer 3+ years experience Knowledge of Javascript, HTML, CSS3
If you have CSS but not CSS3 the recruiter may not realize the difference (or may not realize that pretty much the most important thing on that spec is "Web Developer") and probably won't call.
So in short is calling it Javascript correct? shrug Nothing is correct in this mad world!
So you see, they're following long-standing industry practice :-)
Java 1.4 -> Java 5.
(Yes, I'm a Java programmer)
``` >dotnet Microsoft .NET Core Shared Framework Host Version : 1.1.0 Build : 928f77c4bc3f49d892459992fb6e1d5542cb5e86 ```
``` >dotnet --version 1.0.0-preview2-1-003177 ```
The version numbers aren't necessarily weird, but the versioning sure is.
Disclaimer: MS Employee who uses Dotnet, but doesn't work on it.
https://docs.microsoft.com/en-us/dotnet/standard/net-standar...
I should probably print it out
I was in version hell yesterday, targeting a standard (1.5) because I thought it would help me run as .NET Core 1 whilst supporting a 4.6.2 .NET Framework dll but that broke something else. It was a juggling game of trade offs
Surface Pro. Surface Pro 2 (note: Surface Pro is now surface pro 1!), Surface Pro 3, Surface Pro 4, Surface Pro. By the way we also have Surfaces (1, 2, and 3?) as well as Surface Books, and Surface Laptops! :D
Android: here's a bunch of fucking candy
OS: here's a bunch of fucking animals. By the way, sometimes people call your macbooks 10,1 or some shit.
whose initials follow alphabetical order
JavaScript, that's a scriptable version of Java, right?
/sarcasm
The last one is for ES6.
His blog is full of useful and specific deep dives into individual ES proposals as they reach certain stages.
I haven't read this one but I started one of his other books that was a very large book of JavaScript showing warts and all.
I would definitely support these authors though by buying the books if you have the money to do it.
ES6 (very comprehensive!) http://es6-features.org/#Constants
ES7 (succint, easy to read) https://h3manth.com/new/blog/2015/es7-features/
If applicable there are examples of both before and after conventions as well as links to more technical external resources.
And some interesting tweets by Kent C. Dodds: https://twitter.com/kentcdodds/status/880121426824630273
Edit: fixed KCD's name. Edit #2: No, really.
No you didn't.
Everything is supported, except "Shared memory and atomics"
https://github.com/tc39/proposals/blob/master/finished-propo...
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But I may be able to use Proxy just to capture object changes. I will try it out
>BT: Assuming we get standard modules?
>AWB: We'll get them.
lol
Am I the only one who finds this ironic..
What's the feature you're most excited about?
has been possible with babel on older versions of the JS, but nice to have it after all officially.