Recent language addition suggestions
+1
On Mon, Jul 17, 2017 at 7:24 AM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
realizing the added complexity of new language features, applying a much higher bar than this. [4]
(If you really want features like those, check out Sweet.js, or maybe write an Acorn plugin or a Babylon/Esprima fork.)
+1
I'm against the JSON5/JSON6/TOML proposal because I think it's premature, but I don't think it should be rejected for being an extra syntax proposal in the sense that it doesn't change the result of parsing a script, module, or expression (modulo ch. 16 early errors). It's an extra builtin proposal.
I would like to note that JavaScript is already starting to feel a bit large, and we should definitely take greater care on realizing the added complexity of new language features
my personal opinion is that es6 was a net-negative creating chaos in the world of frontend-development (making virtually everything more difficult and complicated and buggier) that will haunt us for years to come. javascript is NOT a general-purpose language, if trying to make it so comes at the cost of breaking the world-wide-web.
On Tue, Jul 18, 2017 at 4:16 PM, kai zhu <kaizhu256 at gmail.com> wrote:
I would like to note that JavaScript is already starting to feel a bit large, and we should definitely take greater care on realizing the added complexity of new language features
my personal opinion is that es6 was a net-negative creating chaos in the world of frontend-development (making virtually everything more difficult and complicated and buggier) that will haunt us for years to come. javascript is NOT a general-purpose language, if trying to make it so comes at the cost of breaking the world-wide-web.
Couldn't disagree more with just about all of that.
-- T.J. Crowder
A note on "largeness" of languages.
New features that represent a new way of doing things that are simpler to code, read/understand and maintain while offering all the same or even more power are a good thing. It allows ever increasingly complex technical ambitions to be achieved ever quicker.
As code bases transition to the "new" way, the old stuff is hardly seen any more. It is only preserved for backwards compatibility. New code can be written entirely in the new way, which means the old stuff is nowhere to be seen.
(e.g. "prototype", anonymous "function" declarations (as opposed to arrow functions), "var", "then" callbacks on promises (as opposed to await) etc. are gradually becoming relics, which is a good thing)
As such, the set of features in ideal usage doesn't necessarily grow just because these new ways are devised and implemented!
Old code can stay as it is and continue to work thanks to backwards compatibility, so nobody should get hurt by aggressive introduction of new features in ES that palpably allow ever quicker and quicker productivity for those that opt to use them instead!
"backwards compatibility" is a nice thing. But making a language larger just means harder to be backwards compatibility.
Supporting of more features do not mean more productive. Good features do contribute to productive. But there are more features just make things complex and less productive.
I'd like to see more "new" things. But I'd also like to see it just keeps simple.
2017-07-19 13:33 GMT+08:00, Naveen Chawla <naveen.chwl at gmail.com>:
Note that the initial discussion was not about not adding features or yes adding features. It was about adding niche and convenience feature that will help only in niche situations.
So, IMHO, adding features like async await that benefit everybody and change the language in a meaningful way, yes. Adding small convenience feature that can be implemented in a library, usually no.
On Tue, Jul 18, 2017 at 11:03 PM, Gil Tayar <gil at tayar.org> wrote:
Note that the initial discussion was not about not adding features or yes adding features. It was about adding niche and convenience feature that will help only in niche situations.
oh, you mean like...( accoding to medium.com/@ flaviohfreitas/es8-the-new-features-of-javascript-7506210a1a22 )
extra builtins Object.values and Object.entries somehow made it in. These are both easy enough to accomplish with two lines of code; and they certainly didn't make me go 'oh, that would have been useful at...'
On Wed, Jul 19, 2017 at 9:40 AM, J Decker <d3ck0r at gmail.com> wrote:
On Tue, Jul 18, 2017 at 11:03 PM, Gil Tayar <gil at tayar.org> wrote:
Note that the initial discussion was not about not adding features or yes adding features. It was about adding niche and convenience feature that will help only in niche situations.
oh, you mean like...( accoding to medium.com/@flaviohfreitas/es8-the-new-features-of-javascript-7506210a1a22 )
extra builtins Object.values and Object.entries somehow made it in. These are both easy enough to accomplish with two lines of code; and they certainly didn't make me go 'oh, that would have been useful at...'
The first line of the original post is "I've noticed lately that a lot of heavy syntax proposals ...," so I'm pretty sure they don't mean that. Object.values and Object.entries require no new syntax.
Take a look at the polyfills for both (linked from the proposal repo readme) - it's not two lines of code, it's not easy to do correctly, and both values and entries are a significantly common use case - which was part of the onus for getting them in the language in the first place.
Can we please not use es-discuss to just naively and loudly complain about things? It's not productive or friendly.
Isiah's initial message is a useful way to think about any proposal, syntax or otherwise, even before suggesting it to anyone, and to think about what the context might be if/when it's discussed in committee.
Can we please not use es-discuss to just naively and loudly complain about things? It's not productive or friendly.
+1
-- T.J. Crowder
I've noticed lately that a lot of heavy syntax proposals 1, 2, 3 have lately started appearing here that would only appeal to a small niche audience (and not likely garner general use), and are more like a "it'd be nice if we could write this instead" without much other benefit. I would like to note that JavaScript is already starting to feel a bit large, and we should definitely take greater care on realizing the added complexity of new language features, applying a much higher bar than this. 4
(If you really want features like those, check out Sweet.js, or maybe write an Acorn plugin or a Babylon/Esprima fork.)
Isiah Meadows me at isiahmeadows.com
Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com