ECMAScript 2017 Language Specification

https://www.ecma-international.org/publications/standards/Ecma-262.htm

by samerbuna • 9 years ago

600 241 9 years ago

pi-rat• 9 years ago

Really hate the naming for JS standards.. ES2017, ES8, ECMA-262. Way to confuse people :/

wwwigham• 9 years ago

ES2017 is the conventional name now that there's annual publications of the spec. ES8 is someone reading the edition number on the document and trying to be terse. ECMA-262 is the formal name of the spec document, not the language the spec defines. All slightly different things, only one of which names the language itself, officially.

jl6• 9 years ago

Which one is it that names the language officially?

PrunJuice• 9 years ago

So which name is the correct one?

gregmac• 9 years ago

Is calling it "Javascript" even still correct, or should it be called "ECMAScript"? If someone says they write "Javascript using ES2017" are they talking utter nonsense?

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

wamatt• 9 years ago

Sort of related: JS is officially written as "JavaScript" (yeah, ikr) and surprisingly the trademark is owned by Oracle.

gsnedders3• 9 years ago

History time!

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.

nailer• 9 years ago

Really short and accurate answer from People Who Know about why you don't see 'JavaScript' used as often:

- 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.

komali210• 9 years ago

Unfortunately because of marketing and the (general) lack of technical expertise by recruiters, you gotta just put the whole kit and kaboodle on your resume. Mine looks like:

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!

BurningFrog• 9 years ago

Think of it as JS 8 came out in 2017 and is defined in a document with an irrelevant ID.

ScottBurson• 9 years ago

"The versions of Unix are numbered in a logical sequence: 5, 6, 6PWB, 7, 4.1, III, 4.3, V, and V.3." -- quoted from memory from The Unix-Haters Handbook

So you see, they're following long-standing industry practice :-)

bartread• 9 years ago

The .NET and .NET Core version numbers are another minefield, and I still can't remember (and don't really care) what's what. Your choices are either to laugh or be filled with rage. I'm coming round to the first one having mostly opted for the second in recent months.

komali210• 9 years ago

Angular 1, angular 2, angular 2.1... Angular (note, Angular 2 is now Angular! And so is every version after this! Angular 1 still exists though).

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.

SilasX• 9 years ago

Xbox, Xbox 360, Xbox One.

teraflop• 9 years ago

Don't forget openSUSE: 13.1, 13.2, 42.1, 42.2, 42.3, 15.0

amelius• 9 years ago

Way to confuse people :/

JavaScript, that's a scriptable version of Java, right?

/sarcasm

Swizec• 9 years ago

Time to update https://es6cheatsheet.com

What's the feature you're most excited about?

TheCoreh• 9 years ago

Definitely async functions. JavaScript code will be _so much cleaner_ thanks to them. Can't wait for the much needed improvement in readability.

iso-8859-12• 9 years ago

You don't have to wait, it is already supported server-side and client-side.

tehlike2• 9 years ago

async/await +1

has been possible with babel on older versions of the JS, but nice to have it after all officially.

flavio813• 9 years ago

Async/await has been implemented in node.js for a long time, in fact I consider that not using it at the server side is almost criminal...

vdnkh2• 9 years ago

Atomics & shared memory. We use a ton of array buffers along with web workers to transmux HLS video in the browser (https://github.com/video-dev/hls.js). Being able to share memory across the worker instance will hopefully save a lot of memory/time.

52-6F-62• 9 years ago

Off topic: I've been using with hls.js at work recently for some stream debugging. Great stuff!

pk2200• 9 years ago

Array comprehensions. Anytime I switch from Python to JS, it's the first thing I miss.

speg• 9 years ago

Is there a "What's new" section?

samerbuna2• 9 years ago

The "finished" proposals have a good list:

https://github.com/tc39/proposals/blob/master/finished-propo...

43224gg252• 9 years ago

Can anyone recommend a good book or guide for someone who knows pre-ES6 javascript but wants to learn all the latest ES6+ features in depth?

elevenE• 9 years ago

I found the You Don't Know JS series books by Kyle Simpson very helpful.

The last one is for ES6.

https://github.com/getify/You-Dont-Know-JS

samerbuna2• 9 years ago

exploringjs.com

WorldMaker• 9 years ago

I like Dr. Rauschmayer's blog, as well: http://2ality.com/

His blog is full of useful and specific deep dives into individual ES proposals as they reach certain stages.

stevula• 9 years ago

I found it helpful to go through the airbnb style guide. They have lots of examples of the "bad" (often old) way to write something, along with the "good" (often new) way. Then I updated one of my projects to follow those guidelines.

skeletonjelly3• 9 years ago

linkies

https://github.com/airbnb/javascript

https://news.ycombinator.com/item?id=9822975

flavio813• 9 years ago

This is a very nice and comprehensive overview:

ES6 (very comprehensive!) http://es6-features.org/#Constants

ES7 (succint, easy to read) https://h3manth.com/new/blog/2015/es7-features/

gabergg• 9 years ago

http://www.react.express is intended as a learning resource for those used to ES5 Javascript. Granted, it's for learning React through modern Javascript, so it may not be exactly what you're looking for, but it has interactive sections for new ES6 and ES7 features.

peterkelly2• 9 years ago

I've found Pony Foo's articles to be excellent:

https://ponyfoo.com/articles/tagged/es6-in-depth

jacobwylie• 9 years ago

I took a class on ES6 and curated it in a github repo: https://github.com/JacobWylie/ES6

If applicable there are examples of both before and after conventions as well as links to more technical external resources.

HugoDaniel2• 9 years ago

I would really love to see an object map function. I know it is easy to implement, but since they seem to be gaining ranks through syntax sugar, why not just have a obj.map( (prop, value) => ... ) ? :)

thomasfoster966• 9 years ago

Is Object.entries(obj).map((prop, value) => ...) close enough? Object.entries is newly standard in ES8.

HugoDaniel2• 9 years ago

Not really object map. Does not return a new object ;)

bartq• 9 years ago

Object.assign({},obj)

nevir• 9 years ago

Until then, lodash.mapValues is your friend :P

kevincennis2• 9 years ago

I believe that one of the main reasons not to do this is that adding anything to `Object.prototype` means that now everything inherits that new method.

So you have weird things like `'foo'.map()`, `( 42 ).map()`, `new WeakMap().map()`, `false.map()`, etc.

radarsat13• 9 years ago

Those all sort of make sense to me.

'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.

raquo• 9 years ago

Adding a `map` method to every single object is not a backwards-compatible change. That's why those new methods are under the `Object` global.

sghiassy• 9 years ago

Perhaps use the new ‘Map’ object in ES6 instead?

lukasm• 9 years ago

What is up with decorators?

thangngoc89• 9 years ago

It's now at stage-2

thomasfoster966• 9 years ago

Proposals [0] that made it into ES8 (“what’s new”):

* 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...

yahelc• 9 years ago

Interesting that String padding made it in -- sort of jumps out as the simplest of these additions. I wonder how much of that had to do with negative PR for JS-land due to left-pad-gate.

DelaneyM• 9 years ago

You can read that disaster in two ways...

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.

hajile• 9 years ago

I believe the string padding proposal predated the "leftpad" incident by a year or so.

a13n• 9 years ago

I love the trailing commas for function calls. Wish we could get trailing commas for all of JSON too!

pas• 9 years ago

For that you'd need to wait until all major parser libraries support it, aaand that all deployments get updated. That means that little change is an at least 10 year long project.

bfred_it• 9 years ago

It's called JSON5 and it also has comments. The standard JSON will never "change"

ballenf• 9 years ago

Why? I just don't find myself doing too much JSON manual editing. A few config files and such. Occasional editing of a server response or call for testing.

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.

WalterSear2• 9 years ago

What I want are leading commas. Much tidier and one small thing you wouldn't have to edit/think about when adding and removing list items.

sAbakumoff• 9 years ago

I suspect that they borrowed this idea from Golang's "composite literal" spec. which is really nice feature https://dave.cheney.net/2014/10/04/that-trailing-comm

michaelmior• 9 years ago

Thanks for sharing! Interesting to me that separate repositories are used for each proposal, which is news to me. Although I can see some nice benefits to doing so.

thomasfoster966• 9 years ago

I think that’s because a lot of proposals are initially developed away from TC39 by individuals or small groups.

bjacobel• 9 years ago

Please don't call it ES8. It contributes to confusion around the language. ES6 was renamed to ES2015. There is no such spec as ES7 or ES8.

thomasfoster966• 9 years ago

I know I’m technically wrong and it’s too late to edit the comment...

...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.

drinchev• 9 years ago

For anyone wondering what's NodeJS support of ES8.

Everything is supported, except "Shared memory and atomics"

[1] http://node.green

kovek• 9 years ago

Shared memory? Is that also maybe going to be implemented on chrome? I would not have expected shared with code running on the web/in a browser. I'm confused about the goals of ECMA and how ECMA relates to JavaScript.

andrewaylett• 9 years ago

That's memory shared between the main thread and Web Worker threads. While it's exciting from an "easily implementing multi-threaded applications" point of view, given the nature of the objects, it doesn't actually allow sharing any data that couldn't be shared without the new spec.

cies• 9 years ago

Nice 90s style website ECMA!

kronos29296• 9 years ago

Its funny that ECMA website is not more modern. Maybe they are too busy with the spec to change it. Who knows?

komali210• 9 years ago

It's a site read by a bunch of programmers. Why does it need to be pretty? We can read lightly styled text quite easily. It's how most engineers I know prefer their technical documentation.

imhelpingu• 9 years ago

I'm not clear on if it's dated and ugly or just way too future for me.

pgl3• 9 years ago

Here’s what’s in it: https://github.com/tc39/proposals/blob/master/finished-propo...

And some interesting tweets by Kent C. Dodds: https://twitter.com/kentcdodds/status/880121426824630273

Edit: fixed KCD's name. Edit #2: No, really.

sjclemmy• 9 years ago

If you're a Brit, this is a funny misspelling of Kent's name.

https://en.wikipedia.org/wiki/Ken_Dodd

pgl3• 9 years ago

Whoops, that's absolutely why I misspelled it!

choward• 9 years ago

Edit: fixed KCD's name.

No you didn't.

pgl3• 9 years ago

Oh, dear lord.

callumlocke3• 9 years ago

This is mostly symbolic. The annual ECMAScript 'editions' aren't very significant now except as a talking point.

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...

k__• 9 years ago

As far as I understood it:

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.

rictic2• 9 years ago

I think it does matter to end user developers though. Once something is in the standard, you can rely on it. It won't change in a backwards-incompatible way.

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.

camus2• 9 years ago

This is mostly symbolic. The annual ECMAScript 'editions' aren't very significant now except as a talking point.

A spec is never symbolic. If a library claims it implements ES2017 then its consumer expects the library to follow the entire spec.

BillinghamJ• 9 years ago

The per-feature specs are finalised significantly earlier than the yearly official versions. Nothing practically happens or changes.

callumlocke3• 9 years ago

True, but in reality such claims almost always have caveats. Like how almost no one supports ES6 imports yet.

pluma6• 9 years ago

Libraries don't implement ES, JavaScript engines do.

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.

komali210• 9 years ago

I don't understand who gets to use these things. We have to support back to IE11 so other than some things we've managed to find effective polyfills for, we basically just threw our hands up and code as if it's 2012.

iso-8859-12• 9 years ago

You could use Babel.

hoorayimhelping• 9 years ago

People using node for more than just building.

People writing internal tools.

People writing software for tech-savvy users with modern hardware.

People using babel to compile to a supported version.

tracker15• 9 years ago

Most modern projects should probably use Babel and a bundler like Webpack for web targets. You may even want to separate legacy and modern browsers into separate targets so the 80-90% of users on evergreen browsers get a smaller download.

peterkelly2• 9 years ago

I don't understand who gets to use these things

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)

pluma6• 9 years ago

I feel you. I'm also stuck with IE11 for the time being. No CSS variables, no ES6 symbols. Babel takes the edge off it but there's still plenty we're missing out on for the time being.

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.

jadbox• 9 years ago

I wish this-binding sugar would get promoted into stage 1.

empyrical2• 9 years ago

The :: syntax is one of my favorite proposals - does anyone know what's holding it up?

gregjw• 9 years ago

I should really learn ES6

ashnehete2• 9 years ago

Literally after seeing this on #1 felt like, "Wtf? I just started learning ES6"

Andrex• 9 years ago

The additions in ES2016 and 2017 are minimal compared to the massive changes ES2015 (aka "ES6") introduced. Check the full list of them here: https://github.com/tc39/proposals/blob/master/finished-propo...

rpedela• 9 years ago

Has there been any progress on supporting 64-bit integers?

giaour• 9 years ago

The BigInt proposal[0] is stage 2, meaning we should see some implementations soon.

[0] https://github.com/tc39/proposal-bigint

elmigranto2• 9 years ago

Heck, what about any kind of integers, so we can use bitwise operations without `double -> int -> double` casts?

ihsw23• 9 years ago

Notably, with shared memory and atomics, pthreads support is on the horizon.

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.

slackingoff2017• 9 years ago

Shhhh node people still pretend threads don't exist

always_good• 9 years ago

Not sure that anybody is "pretending" anything. Seems like you're just going out on a limb to be condescending.

olingern• 9 years ago

Hmm... can't tell if this is an attempted Node slam, but figured I would add that you can mimic threads / concurrent tasks by utilizing the child_process or cluster modules.

judah2• 9 years ago

Are locks and mutable shared memory a good thing? Advances in modern programming languages aim to abstract threads away (e.g. .NET's Task Parallel Library), because mutable memory shared between threads is a minefield (atomic, locks, mutexes, compare-exchange, etc.).

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...

int_19h5• 9 years ago

TPL abstracts threads away, but not mutable shared memory, nor any primitives used to synchronize access to such from concurrent tasks.

imtringued• 9 years ago

You can only send strings to webworkers in javascript. Without shared memory you have to send a serialised copy of your data to the other process which then has to deserialise it. In most cases this is perfectly fine. But if you have a lot of data then moving it around might take more time than the computation itself. In this case you're forced to use shared memory.

ascom• 9 years ago

Looks like ECMA's site is overloaded. Here's a Wayback Machine link for the lazy: https://web.archive.org/web/20170711055957/https://www.ecma-...

danielsamuels• 9 years ago

If you're using Chrome, you can also go to cache://www.ecma-international.org/publications/standards/Ecma-262.htm (replacing https:// with cache://)

empyrical2• 9 years ago

That's just doing a google search, so you could do "cache:{URL}" in firefox's search field too

emehrkay3• 9 years ago

I'd like to be able to capture object modifications like Python's magic __getattr__ __setattr__ __delattr__ and calling methods that do not exist on objects. In the meantime I am writing a get, set, delete method on my object and using those instead

tkone• 9 years ago

This is what Proxy[1] is for.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

emehrkay3• 9 years ago

I've used Proxy in the past. It doesn't allow for the capture of both `object.attr_does_not_exist` and `object.methodDoesNotExist()` simultaneously, it is one or the other. I will admit that I am trying to use another lang's paradigms in JS, but only because it is so similar and it makes sense to me.

But I may be able to use Proxy just to capture object changes. I will try it out

z3t4• 9 years ago

theres defineproperty in es5. ive used it to create a orm where foo.bar = 1 executes async sql: update foo set x=1

emehrkay3• 9 years ago

That sounds pretty cool. Are there any public examples that I can learn from? Thanks

silviogutierrez• 9 years ago

I'd also love to see examples.

espadrine• 9 years ago

I made a short sum-up of changes in this specification here: http://espadrine.github.io/New-In-A-Spec/es2017/

baron816• 9 years ago

Regardless of what gets included in the spec, I hope people think critically about what to use and what not to use before they jump in. Just because something is shiny and new in JS, it doesn't mean you have to use it or that it's some sort of "best practice."

flavio813• 9 years ago

What I wish ECMAScript had was true support for number types other than the default 32-bit float. I can use 32 and 64 bit integers using "asm.js", but this introduces other complications of its own -- basically, having to program in a much lower level language.

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.

arthurdenture• 9 years ago

There's a BigInt proposal at stage 2, which might meet some of your needs: https://github.com/tc39/proposal-bigint

hzoo2• 9 years ago

It's parseable in Babel 7, issue to implement the transform is https://github.com/babel/proposals/issues/2

buu700• 9 years ago

Tangential to your point, but JS numbers are actually 64-bit floats (capable of safely representing 53-bit ints), not 32-bit.

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)!

bitL2• 9 years ago

Heh, maybe JS becomes finally usable just before WebAssembly takes off, rendering it obsolete :-D

drew-y• 9 years ago

JS won't be entirely obsolete. You won't be able to access the DOM from WebAssembly. It will be way easier to make way more performant web apps though.

goatlover2• 9 years ago

DOM access is coming to WebAssembly after GC is supported.

https://github.com/WebAssembly/design/blob/master/Web.md

komali210• 9 years ago

Wherein a Hackernews suggests an unknown, unpopular technology will replace a known, popular one in short order.

bitL2• 9 years ago

Come on, many people are looking down at JavaScript for a reason - if the new standard allows proper multithreading, it suddenly gets closer to "usable" language as defined by many. But if they had a choice of another language running on top of Web Assembly (or whatever you name the web's VM), I am not sure they would even consider learning JS despite it being finally on par with their favorite language.

j0e1• 9 years ago

Kindly note that the normative copy is the HTML version;

Am I the only one who finds this ironic..

mrec• 9 years ago

What's ironic about it?

komali210• 9 years ago

AWB: Alternatively we could add this to a standard Dict module.
BT: Assuming we get standard modules?
AWB: We'll get them.

lol

idibidiart• 9 years ago

Wait, so async generators and web streams are 2018 or 2016?

wilgertvelinga• 9 years ago

Really interesting how bad the only JavaScript code used on their own site is: https://www.ecma-international.org/js/loadImg.js

pcbeef• 9 years ago

Do what I say, not what I do.

skeletonjelly3• 9 years ago

I've seen worse.

pier254• 9 years ago

In the last couple of years we've seen a small number of significant improvements like async/await but mostly small tepid improvements like string padding, array.map(), etc. It's like TC39 are simply polishing JS.

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.

shinypotatoe• 9 years ago

Checkout TypeScript. It's great.

pier254• 9 years ago

I know, but it's not JavaScript.

pluma6• 9 years ago

The reason ES4 was killed was that there was no consensus between the stakeholders. It would have been a breaking change, making conforming engines incompatible with all existing JavaScript code.

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.

pier254• 9 years ago

I'm not advocating for breaking changes, in fact static type checking in ES4 was optional, the language remained just as dynamic if you wanted to use it that way.

correctsir• 9 years ago

I've been looking at the stage 2 and 3 proposals. I have a difficult time finding use for any of them except for Object spread/rest. The stage 4 template string proposal allowing invalid \u and \x sequences seems like a really bad idea to me that would inadvertently introduce programmer errors. I do hope the ECMAScript standardization folks will raise the barrier to entry for many of these questionable new features that create a maintenance burden for browsers and ES tooling and a cognitive burden on programmers. It was possible to understand 100% of ES5. I can't say the same thing for its successors. I think there should be a freeze on new features until all the browser vendors fully implement ES6 import and export.

ECMAScript 2017 Language Specification

Related Stories