10 ms·
TC39, ECMAScript, and the Future of JavaScript
- flavio81 9y 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 9y agoTC39 has no affiliation with Node or its package manager. It's only for the ECMAScript language specification.
- k__ 9y agoWell, the module spec tries to be a standard for Node AND browser modules
- dean177 9y agoNo 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__ 9y agoWell, npm got faster over the years and with v5 they got consistent hashing for versions, which should make deployment much safer.
- seangrogg 9y agoOut 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.
- flavio81 9y agoThanks 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 9y agoyarn is a great alternative to npm
- JoshGlazebrook 9y agoReally looking forward to class decorators.
- spleeder 9y agoI for one am not. What is wrong with calling a plain function?
- SimeVidas 9y agoYou need to use `.bind()` to set the context, or switch to using arrow functions. Both methods are sub-optimal. `@autobind` solves that.
- k__ 9y agoClass properties solve that too, with less magic IMO.
- dtzur 9y agoDecorators are awesome! Stop this blasphemy.
- tlrobinson 9y agoWhy is @autobind foo() { // ... } more optimal than foo = () => { // ... } ?
- jopsen 9y agoPlease, Nothing is ever _more optimal_.
- solidr53 9y agoBad example, checkout mobx or core-decorators. @computed get value() { return this.a + 1; } @readonly bar = 5;
- arve0 9y agoWhen will js have enough features? Maybe not there yet, but is there an endgame?
- bevacqua 9y agoWe don't ask ourselves that of websites or apps, why would we ask it of programming languages?
- arve0 9y agoBecause 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 9y 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/043307.html 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_holmes 9y agoMore 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 9y agoBut 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.
- camus2 9y 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.
- dean177 9y agoYep, 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-decorators-legacy https://github.com/loganfsmyth/babel-plugin-transform-decora...
- rhencke 9y agoTo 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 9y agoAngular uses the decorator syntax, with a preprocessor that gives it different meaning.
- TheAceOfHearts 9y agoIt'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 9y agoThe 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 9y agoAh, 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
- segphault 9y agoReally 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 9y agoyou mean you wish you had an Option monad, right? ;-)
- pas 9y agohttps://github.com/saneyuki/option-t.js https://github.com/saneyuki/option-t.js :)
- arve0 9y agoWe have deep-value and deep-reduce easily available: https://www.npmjs.com/package/deep-value https://www.npmjs.com/package/deep-value https://www.npmjs.com/package/deep-reduce https://www.npmjs.com/package/deep-reduce
- Lordarminius 9y ago> Even Ruby has that now Are you implying that Ruby is a backward language ? :/
- esamatti 9y agoIt's at Stage 1 https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining and babel plugin is coming here https://github.com/babel/babel/pull/5813 https://github.com/babel/babel/pull/5813
- jorangreef 9y agoIs there any plan for 64-bit integers?
- sluukkonen 9y agoThere is some work underway. https://github.com/tc39/proposal-bigint/blob/master/README.md https://github.com/tc39/proposal-bigint/blob/master/README.m...
- medalist 9y agoI 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