
TC39, ECMAScript, and the Future of JavaScript - bevacqua
https://ponyfoo.com/articles/tc39-ecmascript-proposals-future-of-javascript
======
TheAceOfHearts
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
The shared memory and atomics proposal was approved as part of the ES2017
spec.
[https://github.com/tc39/ecmascript_sharedmem](https://github.com/tc39/ecmascript_sharedmem)

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

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

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

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

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

~~~
pas
But in case of languages you don't have to use that feature. And it's there
for a reason, and that is that it makes certain class of things much easier to
solve/implement/model/approach.

And if you don't work in that subfield, you don't have to know that part of
the language. (Just as if you don't do compiler development you don't need to
know Assembly mnemonics, and you don't have to know how many cycles a a
particular microcode takes, and so on. You just use perf if you want to, and
see that duh, it's too much, let's use -O3... or ask an expert. Or look into
it yourself.)

But when you encounter something new in a language, you can learn about it. If
it's there because it made something elegant, great. If not, refactor it. Make
it simpler.

But this is the same Deletionist approach that is plaguing Wikipedia, just now
with the tragedy of commons language, JS.

~~~
camgunz
> But in case of languages you don't have to use that feature. And it's there
> for a reason, and that is that it makes certain class of things much easier
> to solve/implement/model/approach.

You can choose for _your_ code, sure, but you can't choose for everyone else's
code. This is brought up whenever C++ complexity threads start. Sure you can
choose to not use template metaprogramming or whatever, but some library will
use it, and then pow you're using it too.

~~~
pas
You don't have to use that library.

And as I've mentioned, that library started to use it for a reason.

If you use a library that just starts using expensive features (like templates
in C++), just because they think they're cool, then I regret to inform you,
that you already depend on a bunch of script kiddies.

This is the same thing as we always discuss with functional programming and
all those extremely complicated category-theory heavy con-fuck-structs. They
make sense in a setting for some problems. (
[https://stackoverflow.com/questions/5057136/real-world-
appli...](https://stackoverflow.com/questions/5057136/real-world-applications-
of-zygohistomorphic-prepromorphisms) )

But it's very much like a special weapon that is large, and heavy, and only
those can handle it that are blessed by the priests of The Temple of Homotopy
Type Theory, or whatever, and so on. So mere mortals should not touch it.

And in a proper library, those beasts are locked up well, encapsulated.

It's the language's (or the lib's) shortcoming if you can't interface with the
library, can't apply parameters to the library without knowing the hairy
internals.

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

~~~
dean177
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...](https://github.com/loganfsmyth/babel-plugin-transform-
decorators-legacy)

------
segphault
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
you mean you wish you had an Option monad, right? ;-)

~~~
pas
[https://github.com/saneyuki/option-t.js](https://github.com/saneyuki/option-t.js)
:)

------
JoshGlazebrook
Really looking forward to class decorators.

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

~~~
mmargerum
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

~~~
abritinthebay
None of that sounds particularly hard, complex, or tricky _without_ decorators
though.

Like, I get they can be used for _stuff_ but why are they a better option?

So far - based on the responses here - it appears to be syntax for syntax sake
and no practical benefit.

~~~
mmargerum
It's just sugar but it's less code and I find it easy to read at least in go.

~~~
abritinthebay
It’s not really _less_ code though. It’s about the same but with an syntax
that obfuscates where the logic happens.

Terse _at the usage point_ yes, but it swaps clarity for brevity. A sometimes
useful trade off to be sure but... not sure I’ve seen any demonstration of
benefits here.

------
flavio81
> 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
TC39 has no affiliation with Node or its package manager. It's only for the
ECMAScript language specification.

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

------
jorangreef
Is there any plan for 64-bit integers?

~~~
sluukkonen
There is some work underway.

[https://github.com/tc39/proposal-
bigint/blob/master/README.m...](https://github.com/tc39/proposal-
bigint/blob/master/README.md)

------
medalist
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](https://github.com/tc39/proposal-dynamic-import/issues/35)

