TC39, ECMAScript, and the Future of JavaScript

https://ponyfoo.com/articles/tc39-ecmascript-proposals-future-of-javascript

by bevacqua • 9 years ago

123 97 9 years ago

flavio812• 9 years ago

TC39 is currently working on over 30 active proposals. What else does the future hold in store? These days we download our packages from npm.

I am surprised that no more mentions of NPM were made. I hope that commitee TC39 addresses the topic of NPM and tries to create a new version that is standarized and that elliminates the serious flaws of NPM, which for me are one of the major hindrances to adopting Node.js for things that go beyond prototyping.

idbehold• 9 years ago

TC39 has no affiliation with Node or its package manager. It's only for the ECMAScript language specification.

k__3• 9 years ago

Well, the module spec tries to be a standard for Node AND browser modules

dean1772• 9 years ago

No mentions of npm are made because this is about language specification not the broader ecosystem around javascript.

Package managers are completely detached from language specifications so that they can evolve independently.

k__3• 9 years ago

Well, npm got faster over the years and with v5 they got consistent hashing for versions, which should make deployment much safer.

seangrogg• 9 years ago

Out of curiosity, have you seen the latest changes to npm? Since they've added lockfiles I've yet to have any issues with dependency management, really.

flavio812• 9 years ago

Thanks for your reply, Sean.

Googling on lockfiles i found out more about the features of the Yarn package manager. Perhaps that's what I should use.

However what i meant with my comment is that I feel that package managers should be standarized into a language -- as long as the package registry is not private but can be pointed to whatever URL one wants.

root_axis• 9 years ago

yarn is a great alternative to npm

JoshGlazebrook• 9 years ago

Really looking forward to class decorators.

spleeder• 9 years ago

I for one am not. What is wrong with calling a plain function?

SimeVidas• 9 years ago

You need to use `.bind()` to set the context, or switch to using arrow functions. Both methods are sub-optimal. `@autobind` solves that.

abritinthebay8• 9 years ago

Decorators are one of those things that I've not seen a use case that sells them to me.

Like... I'm sure one day I'll see something and it'll just click, but not there yet.

saghm2• 9 years ago

I'm the same way, except less sure that I'll find something that will change my mind.

solidr532• 9 years ago

https://mobx.js.org/best/decorators.html

danielbarla3• 9 years ago

Well, in C#-land, we often use / abuse attributes to get information about a class or property at runtime. This way, framework or library code can inspect entities that you've authored, and dynamically deal with them. Perhaps a decent example is validation, where a declarative style has gained a lot of popularity. A JS example might be:

  @required firstName;

This simply declares the intent / rule, but does not provide the implementation.

We can argue terseness vs verbosity, implicitness vs explicitness all day - I'd argue that for certain basic things that you do highly frequently, a terse and implicit style is not a bad thing. It tends to increase the signal-to-noise ratio of your code, allowing the developer to focus on things that really are interesting, and not have to read through a lot of boilerplate.

Matthias247• 9 years ago

In angular2 they are for example used for dependency injection, which works really well.

Other use cases that I see are for example automatically generating [de]serialization code for members based on decorators and their values (like how Annotations are used in C# and Java serialization frameworks or tags in Go).

There are also web frameworks popping up which use decorators for routing and parameter binding in a similar fashion how some Java frameworks work.

mmargerum2• 9 years ago

When marshaling classes in and out of xml/json decarators can be added to properties to change the name of the equivalent Json field value as well as indicating if it's optional or not. Orms use decators to map object to relational tables the may have different field names, expressing key values, etc

andreineculau2• 9 years ago

Oh please. Decorators will never beat plain old functions when it comes to flexibility.

rhencke2• 9 years ago

C will never beat plain old assembly when it comes to flexibility.

tlrobinson2• 9 years ago

Really wish they had included function decorators too.

https://github.com/wycats/javascript-decorators/issues/4

netcraft• 9 years ago

I wish we could get macros then we could make our own decorators... (macro support in typescript would be awesome)

arve04• 9 years ago

When will js have enough features? Maybe not there yet, but is there an endgame?

bevacqua• 9 years ago

We don't ask ourselves that of websites or apps, why would we ask it of programming languages?

arve04• 9 years ago

Because languages that have few but powerful concepts are easy to use.

I also believe that we do ask these questions about apps. Sometimes less is more.

Note: I feel most proposals today are sane.

magicalist• 9 years ago

We don't ask ourselves that of websites or apps

To be fair, yes we do.

Most websites and apps have an additional advantage of not necessarily caring about backwards compatibility over decades and can cut out features that don't work out or are obsolete, something that may never be possible with JavaScript.

And, just like languages, apps that do become lumbering beasts are often abandoned for rewrites or new apps with similar functionality but streamlined of all that historical baggage.

why would we ask it of programming languages?

TC39 member Mark S Miller answered this question well in "The Tragedy of the Common Lisp, or, Why Large Languages Explode"

https://mail.mozilla.org/pipermail/es-discuss/2015-June/0433...

There is definitely a balance, but any language ignores this question at its peril.

marcus_holmes2• 9 years ago

More is not better.

I always like the old saying "it's not done until you can't remove any more". Adding features doesn't make a thing better, it just makes it more complicated.

krapp• 9 years ago

Obviously, Javascript needs to be complex enough to bootstrap the Singularity.

int_19h• 9 years ago

If that's how it goes, we needn't worry. It'll be an endless chain of AIs, each spending all its time designing a new and better language to write the next AI in. As we know full well by now, the process is so fascinating in and of itself, there's little else that they will have time for.

andreineculau2• 9 years ago

Based on Crockford, when tail recursion optimization lands, meaning soon. It's getting ridiculous now, with a super blurry line between language features and built-in utils

saghm2• 9 years ago

It's getting ridiculous now, with a super blurry line between language features and built-in utils

I think part of the problem is that there isn't really a standard library for JS, just a bunch of global variables that are automatically there when your program starts

copperx• 9 years ago

I don't understand why doesn't an ECMAScript2 exist at this point, instead of just trying to patch JavaScript. The whole reason JScript and others ultimately failed were because they were not standardized. How hard is it for browser vendors to say "we'll implement ECMAScript2, whatever it is" so that we can all have a sane language to work with (while we wait for WebAssembly).

dangoor• 9 years ago

To some extent there is, in that the javascript VMs can treat certain sorts of scopes (like Modules) differently because they know that those did not exist at an earlier time when certain bad behaviors were common.

They debated quite a bit while working on ES6 about having a different script type to make more breaking changes, but they decided that this would be bad for evolution on the web (see the adoption of Python 3, for example)

Vinnl3• 9 years ago

That's what Dart was supposed to be, in Google's eyes. The problem is both that it needs buy-in from all browser vendors (and the webdev community), and more importantly, that you'll now need to support both Javascript and the new language indefinitely. Especially considering that new mistakes will be made with the new language, and new quirks introduced, that doesn't sound that attractive.

mappu• 9 years ago

I remember being quite surprised to see the Property Accessors RFC for PHP get declined, largely on the basis of making the language more complicated.

It annoyed me at the time but I do respect the decision to resist adding every single feature under the sun.

mbell• 9 years ago

The language doesn't need too much more. Don't get me wrong, it's still not a great language but within the confines of what it is and backward compatibility, it doesn't need much more. The 'standard library' and browser apis though, have a long way to go.

pitay• 9 years ago

The need for backwards compatibility is what is keeping JavaScript still not a great language. The number of wtfs and surprising behaviour is justified by needing to conform to what the language already did, and that is not a good thing.

camus2• 9 years ago

Class Decorators (Stage 2)

Does it means both Typescript and AngularJS implement/use an experimental feature that is still under discussion as of now, in production? this is a bit risky.

dean1772• 9 years ago

Yep, interestingly the decorators proposal has changed significantly since it was in stage-0.

So much so that this exists: https://github.com/loganfsmyth/babel-plugin-transform-decora...

rhencke2• 9 years ago

To be fair, though, you must explicitly opt in to using decorators in TypeScript via --experimentalDecorators, and the documentation for said switch states: "Decorators are an experimental feature that may change in future releases."

evmar• 9 years ago

Angular uses the decorator syntax, with a preprocessor that gives it different meaning.

TheAceOfHearts2• 9 years ago

It's worth noting that proposals can move down as well. For example, I think there was lots of work done on atomics before it was ultimately scrapped. Heck, the global proposal doesn't look like it has moved in months due to a few web compatibility issues.

kevinb7• 9 years ago

The shared memory and atomics proposal was approved as part of the ES2017 spec. https://github.com/tc39/ecmascript_sharedmem

TheAceOfHearts2• 9 years ago

Ah, it looks like you're correct. Apologies, I actually meant SIMD[0].

[0] https://github.com/tc39/ecmascript_simd

segphault• 9 years ago

Really wish there was more momentum on adding a safe access operator. Even Ruby has that now, it's disappointing that we still don't have it in JS.

p4lindromica• 9 years ago

you mean you wish you had an Option monad, right? ;-)

pas4• 9 years ago

https://github.com/saneyuki/option-t.js :)

arve04• 9 years ago

We have deep-value and deep-reduce easily available:

https://www.npmjs.com/package/deep-value https://www.npmjs.com/package/deep-reduce

Lordarminius• 9 years ago

Even Ruby has that now

Are you implying that Ruby is a backward language ? :/

esamatti• 9 years ago

It's at Stage 1 https://github.com/tc39/proposal-optional-chaining

and babel plugin is coming here https://github.com/babel/babel/pull/5813

_urga• 9 years ago

Is there any plan for 64-bit integers?

sluukkonen• 9 years ago

There is some work underway.

https://github.com/tc39/proposal-bigint/blob/master/README.m...

medalist• 9 years ago

I would argue that the future of JS looks bleak when you effectively can't have any meaningful discussions about proposals if you are not in the committee (the author just ignored the issue for half a year, then closed and locked it): https://github.com/tc39/proposal-dynamic-import/issues/35

TC39, ECMAScript, and the Future of JavaScript

Related Stories