57 ms·
What’s New in ES2019
- dawhizkid 7y agoarr.flat(Infinity) seems like a strange decision for flattening the entire array - wouldn't the most common number of levels to flatten an array be all levels, in which case I'd expect arr.flat() to flatten the whole array but in this case it's just 1 level.
- calebegg 7y agoIf your array is contained in itself, flat(Infinity) gives a stack overflow. My guess is they wanted the default behavior to be safer/saner.
- kevlened 7y agoInfinity was originally the default (which feels intuitive), but here's the argument for changing it [0]: "I think Array#flatten should be shallow by default because it makes sense to do less work by default, it aligns with existing APIs like the DOM Node#cloneNode which is shallow by default, and it would align with the existing ES3 pattern of using Array#concat for a shallow flatten. Shallow by default would also align with flatMap too." [0] https://github.com/tc39/proposal-flatMap/issues/9 https://github.com/tc39/proposal-flatMap/issues/9
- dawhizkid 7y agoI’m trying to think of a single use case where I’d want to flatten exactly one level of an array and can’t.
- derefr 7y ago.
- ajanuary 7y agoDoesn't the fact that flatten by default only flattens one level mean you can still create nested output by emitted nested outputs?
- 2T1Qka0rEiPr 7y agoYes, it appears so. From MDN: > The flatMap() method first maps each element using a mapping function, then flattens the result into a new array. It is identical to a map() followed by a flat() of depth 1, but flatMap() is often quite useful, as merging both into one method is slightly more efficient. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/flatMap https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- swish_bob 7y agoFlatMap is often most useful when recursing, in my experience.
- ohaideredevs 7y agoI have used recursion two times irl outside of interviews.
- swish_bob 7y agoUsed with flatMap, it's a terribly good way of doing something to everything over an arbitrary object and all it's deep values. I do something like this every month or so. It's one of those tricks you use a lot once you've seen the problems it's applicable to.
- afandian 7y agoIt's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't know if you could retrofit features like const or mut. But, speaking personally, it might create enough safety-net to consider JS again. (Maybe I'm missing an obvious feature?)
- wongarsu 7y agoMutation is a real weakness of Javascript. I think the general idea is "methods don't mutate unless they are ancient". For example Array.map (an IE9-era feature) doesn't mutate, Array.sort (an IE5.5-era feature) does. Similarly a "for(let i=0; i<arr.length; i++) arr[i] = b" loop will obviously mutate modified elements while a "for(let e of arr) e = b" won't; the trend is towards less mutability in new features. Proper immutable support (or a stronger concept of const) would also help with this.
- jacobwilliamroy 7y ago> for(let e of arr) e = b Is that just arr.map( e => b ) ?
- dao- 7y agoNo, it's broken code and doesn't effectively do anything.
- amitport 7y agoNope. The first does not do anything. The second makes a new array of length 'arr.length' with 'b' in every cell
- wongarsu 7y agoIt doesn't do anything and was my attempt to give a simple example that is somewhat obvious while glossing over the complexity let arr = [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}]; let b = "!" for(let e of arr) e = b; console.log(arr) [{a: 1, b: ["a", "b"]}, {a: 9, b: ["a","c"]}] (unmodified) for(let e of arr) e.a = 2; console.log(arr) [{a: 2, b: ["a", "b"]}, {a: 2, b: ["a","c"]}] (modified) for(let e of arr) {let copy = {...e}; copy.a = 4;} console.log(arr) [{a: 2, b: ["a", "b"]}, {a: 2, b: ["a","c"]}] (unmodified) for(let e of arr) {let copy = {...e}; copy.b[0] = "!";} console.log(arr) [{a: 2, b: ["!", "b"]}, {a: 2, b: ["!","c"]}] (modified) The most frustrating thing about all of this is that the best way to make a deep copy to avoid all unwanted modification is JSON.parse(JSON.stringify(arr))
- kuon 7y agoThe part about parameter less catch reveals a lot about the philosophy of the language. For me, silencing error like this is a bad practice. You may still produce a sane error in the catch, but the design goes toward silencing things. I really love languages that force you to handle errors up to the top level.
- jmkni 7y agoWhat's a good example of this sort of language?
- Latty 7y agoElm (https://elm-lang.org/ https://elm-lang.org/) is a language that compiles to JavaScript that doesn't have runtime exceptions.
- jmkni 7y agoNeat, thanks
- codenirvana 7y agoThere's Elm, PureScript and many other functional programming inspired languages. But, TypeScript is a safe bet.
- iraldir 7y agoIt does, though I wouldn't go to the same conclusion. It gives more freedom to the developer. They are lot of cases where errors are in fact, expected. Parsing a user inputted JSON. Making a request to check internet connection availability. Any promise that is going to be consumed by an async - await pattern. In those cases (and many more), you may want to try something just simply to see if it works. It's completely different say to being on the backend, trying to write to a database which may or may not fail. In those cases, forcing the extra parameter in the catch, even though you are not using it, is slightly annoying. I mean it's literally 3 characters, but in this age of linters encouraging to not specify arguments you don't use, it just feels unnatural.
- moomin 7y agoThat’s a surprisingly small amount of change. I’ll leave it to others to determine if that’s a good or bad thing.
- EGreg 7y agoVery good! Personally, I am not a fan of languages growing. I think C is awesome, because everyone can understand the code, and doesn’t have to be a language lawyer like with C++. Concepts, Lambdas, crazy Template preprocessing, and more. The team can just work, pick up any module and read it without magic. In C++ I am not even sure if a copy constructor would run vs an overloaded = operator without looking it up.
- agumonkey 7y agoClojure too didn't change a lot. In these years of 'disruption' it feels odd. But it may just be that we forgot stability and maturity.
- moomin 7y agoExisting Clojure APIs don't change, but Clojure adds a lot more than this each year. Look at spec, reducers, transducers &c
- agumonkey 7y agoWell reducers and transducers were big announcements. IIRC clojure 1.10 didn't add any feature of that scale, and few people mentioned that it was quite a "smaller", without criticizing. spec seems important but is still alpha status.
- jillesvangurp 7y agoTechnically most of this is not even language changes but simple changes to the standard apis. E.g. flatMap is something I've missed and worked around by implementing it myself a few times. Not a big deal and nice that they added it. In any case, I use typescript by default now and have converted most of the code I care about at this point. I think most of this improves typescript as well so; overall a good thing.
- jeffwass 7y agoObject.fromEntries will be super useful, surprised it’s taken this long to become a native feature.
- vmasto 7y agoWhat would some common/helpful use cases be?
- tazard 7y agoI often use Object.entries so that I can use Array.filter/map/foreach on an object, but then I need to use Array.reduce to hack it back into an object. Object.fromEntries solves this.
- baron816 7y agoYeah this is what I’m most excited for. filter and map and my preferred array traversal methods. reduce can be awkward though, and people abuse it by using it to replace or combine filter and map. fromEntries almost makes reduce unnecessary when working with objects.
- masklinn 7y agoFunctional transformation of objects. There are lots of HOFs working on arrays / iterators but none working on object. fromEntries allows easily converting from object to entries, manipulating the entries sequence and converting back to an object. The last step is pretty annoying without it. The entire thing is very common in Python, where Object.entries() is spelled `.items()` and `Object.fromEntries(…)` is spelled `dict(…)`
- STRML 7y agoIt's a lot more verbose than _.mapValues() is, but it's nice to have a relatively simple solution without using a library.
- deleted 7y ago[deleted]
- estomagordo 7y agoUnder symbol.description: const test = Symbol("Desc"); testSymbol.description; // "Desc" --------- Should testSymbol be replaced with test?
- mradman 7y agoFixed the typo, thanks for the heads up!
- john-foley 7y agoHard to believe that const arr4 = [1, 2, , 4, 5]; is valid.
- dspillett 7y agoSeems perfectly logical to me: an array of length 5 with four populated elements and one empty one (3). Though I did double-check my understanding that the length property would report 5 rather than 4 (it does). What looks out of place to you in that example? Would it make more sense to you with a very slightly less arbitrary example, perhaps arr = ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for 4']; instead of simple mapping ints to ints? Because array contents are mutable [even if the array variable itself is declared const] that third index may be populated at a later point in the code.
- masklinn 7y ago> What looks out of place to you in that example? Most languages don't have sparse arrays so it's really weird. > Would it make more sense to you with a very slightly less arbitrary example, perhaps arr = ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for 4']; instead of simple mapping ints to ints? You'd usually put an explicit `null` there, especially as HOFs skip "empty" array cells so ['Value for 0', 'Value for 1', , 'Value for 3', 'Value for 4'].map(_=>1) returns [1, 1, , 1, 1] which is rarely expected or desirable.
- ZenPsycho 7y agoseems like a real missed opportunity to add string.leftPad()
- davman 7y agoYou mean https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ?
- alexlur 7y agoString#padStart already exists: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/padStart https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- soulofmischief 7y agoBut we still have trimLeft() and trimRight() and in true JS tradition we need some more redundancy for symmetry's sake.
- deleted 7y ago[deleted]
- STRML 7y agoAs in the MDN article: All major engines have also implemented corresponding trimLeft and trimRight functions - without any standard specification. So ES2019 implements trimStart() and trimEnd(), which are symmetrical to padStart() and padEnd(), but trimLeft() and trimRight() aliases are maintained as not to break working code.
- soulofmischief 7y agoYou're right, I was just being tongue-in-cheek.
- ZenPsycho 7y ago
- alexlur 7y agoThat Function.prototype.toString change is probably going to break some Angular.js code who relies on scanning function argument names for dependency injection.
- deleted 7y ago[deleted]
- robocat 7y agoIt also requires that comments get stored and waste memory: previously just enough of the AST needed to be stored to be able to regenerate the JavaScript. You can't throw away the comments because you can't predict where code might do someVarHoldingAFunc.toString() It seems like an unnecessary change - if the source needs to be accessed then get the source file.
- nkozyra 7y agoAgreed. I guess the argument for it is it's more accurately reflected but... who cares? Maybe I'm not understanding what people do with [function].toString() in the real world.
- robocat 7y agoWhat's even worse is that now frameworks (and viruses) will store data in comments. I know this because I have wanted to use fn.toString() as part of some meta-programming many years ago (but couldn't because comments were not stored). I am sure a lot of effort went in to making a good decision, aiming for a good outcome, but this smells like a bad one.
- snek 7y agoEngines hold the entire source anyway, with the exception of XS, which returns "[native function]" for everything.
- jlokier 7y agoES doesn't store quite enough of the AST to recreate the function anyway. Most functions reference variables and functions defined in a lexical scope outside themselves. Getting the source with toString(), and passing that to eval(), doesn't reproduce the function, and sometimes it compiles ok but the function does the wrong thing. Usually it doesn't matter, because these methods are used on functions that luckily only use well known names, mainly properties of window/global. But it's a risk, and I've seen subtle bugs caused by the assumption that the function's .toString() can be run through text substitutions and eval to get back a variant of the original code. Contrived example: let x = "wrong variable"; function f() { let x = "I am x"; return function g() { return x; } } f()() => 'I am x' eval(f().toString()) g() => 'wrong variable'
- NKCSS 7y agoWhy did they create a flatMap method? What is wrong with .map(...).flat()? Can they improve the performance by combining it that much?
- steenreem 7y agoThey could have also implemented flat in terms of flatMap: flatMap(x => x) I personally feel flatMap is a much more used method than flat, so if you want to remove one, I would remove flat.
- masklinn 7y ago> They could have also implemented flat in terms of flatMap: flatMap(x => x) Flat can flatten any level of nesting (it just defaults to 1), so would be difficult to implement in terms of flatMap.
- contravariant 7y agoYou could reproduce that behaviour of 'flat' by doing something like: function flatten(x, n=1) { return n > 0 ? x.flatmap(y => flatten(y, n-1)) : x; }
- masklinn 7y agoYou could also blow up your stack as there is no requirement whatsoever that javascript implementations be tail-recursive.
- tragic 7y agoYou could optimise either, I don't think that's the point. It's just a convenience that more clearly expresses the intent of the code where it's used. Imagine an example where the callback to map is quite long; seeing the flatMap identifier alerts you to the fact that the callback returns arrays, even before you start reading. You'll find equivalents in all the JS utility libraries and most functional programming language standard libraries (and languages like Ruby with functional-ish subsets), so there's a lot of evidence that people who write code in that style like to have such a function available.
- halfmatthalfcat 7y agoNow if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining
- cypressious 7y agoOptional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.
- chriswwweb 7y agoOh I didnt know about TS being so close to have it, that's great news EDIT: here is the confirmation TS 3.7.0 got tagged: https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784 https://github.com/microsoft/TypeScript/issues/16#issuecomme... EDIT 2: wow just noticed, that the issue ID is "16" and it has been open since Jul 15, 2014 (I guess: good things take time ... ;) )
- johnkpaul 7y agoThis is awesome and hopefully 2020 bound. The only thing I remember from my few months of looking into Groovy was the "elvis operator" and being very jealous of it.
- deleted 7y ago[deleted]
- chriswwweb 7y agoYeah very excited about optional chaning, which few days ago got accepted to stage 3 "candidate", so just one more stage (stage 4 "finished"), I guess and hope it will be ready for ES 2020
- phpnode 7y agoPattern matching is a really important feature but I strongly dislike that proposal because it feels like it introduces a bunch of single purpose syntax that's going to restrict the ability to evolve the language in future. It feels like it's an addon, not a holistic solution. I would much, much rather that type annotation syntax gets standardised first, because it is comparatively easy to build pattern matching when that's in place but going the opposite direction is difficult. What is a type if not a pattern?
- swalsh 7y agoSome half decent stuff in here, but I heavily disagree with changing the output of toString. That might cause problems if someone is expecting one output, but the new version creates something new. I don't see a reason why they couldn't have just added a new function functionCode() or something similar. It would give people the functionality they want, without destroying backwards compatibility.
- snek 7y agoIt's already been deployed in the wild for about a year.
- chriswwweb 7y agoA read a similar article few days ago (might be interesting too) (not mine): https://medium.com/@selvaganesh93/javascript-whats-new-in-ecmascript-2019-es2019-es10-35210c6e7f4b https://medium.com/@selvaganesh93/javascript-whats-new-in-ec... And also here is a good recap of ES 6/7/8/9 (just in case you missed something) (also not mine): https://medium.com/@madasamy/javascript-brief-history-and-ecmascript-es6-es7-es8-features-673973394df4 https://medium.com/@madasamy/javascript-brief-history-and-ec...
- namelosw 7y agoFinally, flatMap is here. I really hope there could be syntactic sugar like do expression in Haskell, for in Scala, and LinQ in C# for flatMap instead of type limited version like async await. Another thing is pipe operator seems to be very welcome among the proposals. There will be no awkward .pipe(map(f), tap(g)) in RxJS since then.
- intea 7y agoWhy are empty elements in an array allowed? oO [1,2,,3]
- vbezhenar 7y agoThey need to ensure that any combination of characters will produce some result.
- padolsey 7y agoQuite useful in situations such as: > (str.match(regexWithGroup) || [, null])[1] I.e. if the regex matches, then give me the first group (1st index) otherwise give me null.
- bzbarsky 7y agoBecause you can create that array anyway, like so: var arr = []; arr[0] = 1; arr[1] = 2; arr[3] = 3; so there's not really much downside to also allowing a literal syntax for the same thing.
- ahmedfromtunis 7y agoCan someone please point me to the rationale behind the new toString() function?
- delinka 7y agoI don't know the answer to your question, but I would like to add to it to gain some clarity for myself: why not give the caller the option to have comments eliminated? An optional parameter `includeComments` bool with default `false` would provide backward compatibility while allowing those who need the comments to request them.
- deleted 7y ago[deleted]
- masklinn 7y agoRather than how complete it is, the real improvements of the proposal are: 1. it all but requires that ES-defined functions stringify to their source code. Pre-ES2019 that's implementation-defined 2. it standardises the placeholder for the case where toString can't or won't create ECMAScript code (e.g. host functions), this could otherwise be an issue as with implementation-defined placeholders subsequent updates to the standard might make the placeholder unexpectedly syntactically valid, by having the placeholder standard future proposals can easily avoid making it valid 3. the stringification should be cross-platform as the algorithm is standardised
- soulofmischief 7y agoOk that makes sense... I was really confused because that's already more or less toString()'s behavior on modern browsers, though the whitespace discrepancy is important to define.
- masklinn 7y agoThat's in part because it was fed back through browsers during the specification process.
- rglover 7y agoThat array.flat() and array.flatMap() stuff is great to see. Always having to rely on lodash and friends to do that type of work. Exciting to see how JS is evolving.
- ptah 7y agoit should be faster than lodash too, i should hope
- stevenmays 7y agoI dig it too, but you could previously flatten an array with concat, and the spread operator. [].concat(...array) Lodash wasn't necessary.
- ulisesrmzroche 7y agoYeah but that reads so gross. Look at it. It’s actually painful. Much rather have the magic word “flat”
- deleted 7y ago[deleted]
- rglover 7y agoHeh, didn't know that. Thanks for the tip :)
- anchpop 7y agoDon't do that, it won't work for arrays greater than a certain size
- mantap 7y agoNo this is not an alternative, it will fail if the array is too large, as you will exceed the maximum number of arguments a function will accept (which is implementation defined). In general the spread operator should only be used for forwarding arguments not for array operations.
- zitto 7y agoIt's very exciting to see how JavaScript is evolving!
- dsego 7y agoHonest question, not playing. What is exactly exciting about it? 2020 is around the corner and the language created back in 1995 is only now getting features that have been standard in many other languages, either as part of the core language or the standard library for decades.
- MH15 7y agoIt's exciting to see the language that we use for the web gain these features (albeit late)! These changes will allow us to follow better programming practices with less overhead.
- deleted 7y ago[deleted]
- Accacin 7y agoWell, I'd think that was pretty obvious, right? It's exciting because if you spend the day writing JavaScript I don't give a hoot that another language has had that feature for decades because I don't get to use that other language. Are you implying that no other languages ever add features that other languages have? All languages except JS are feature complete? Come on..
- dsego 7y agoWell now, having an option to use other languages to script web pages, that would be exciting.
- hombre_fatal 7y agoThe better JS gets, the more I want to use it. JS with Promises + async/await is now one of my favorite languages.
- mmartinson 7y agoHonest question, not meant to be inflammatory. If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal. I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are.
- icholy 7y agoI like TypeScript's (stage-3) approach to feature adoption.
- svieira 7y agoGating on stage-3 really helps. (I have done the same on projects I work on and it helps) There are times when you need to consider the complexity of the specification and the amount of contention around it (decorators / SIMD for example). IMO, anything below that is effectively a custom macro anyway (for which you may want to consider sweet.js or babel.macro to make it clear that this may change and help you find places you use the feature). Real-world feedback may change anything from syntax to behavior (`flatMap -> flat`, `Object.observe -> Proxy`, `EventEmitter -> Observable -> Emitter?`, and the it-feels-like-dozens-of-options pipeline syntax)
- snek 7y agoIt wasn't TS's idea, stage 3 exists purely for getting feedback from implementations about implementing and using the feature.
- WorldMaker 7y agoIt was TS's 2.0+ idea to stick to Stage 3 like glue. Especially prior to 1.0, but even during 1.x, TS implemented proposals in stages earlier to 3 (or even not yet staged). One of the regrets you sometimes hear from TS devs is that they added decorators way too early (it's still not Stage 3 and increasingly likely if it ever hits Stage 3 it will look very different, and it may never hit Stage 3 because there is a bunch of opposition), even though that is behind an "experimental" flag, there's a huge amount of "Production" code written with decorators in Typescript. (Largely thanks to the Angular ecosystem that became hugely dependent on decorators.)
- Dirlewanger 7y agoCan we get some additions that replace the garbage one-liner `is-even`/`is-odd` npm libraries that are a scourge?
- tomduncalf 7y agoYou mean something like x % 2 === 1? I'm a JS fan but had to admit I chuckled at the implementation of is-even: https://github.com/jonschlinkert/is-even/blob/master/index.js https://github.com/jonschlinkert/is-even/blob/master/index.j...
- soulofmischief 7y agoThat's hilarious. What's not hilarious is that, after removing the essentially useless error-checking, is-even is literally just `(n % 2) === 1`. On one hand, JS desperately needs a standard library, on the other hand, JS devs can be so infuriatingly lazy and obtuse.
- choward 7y ago> is-even is literally just `(n % 2) === 1` Pretty sure that tells you if a number is odd. I guess maybe there is a reason these libraries exist.
- soulofmischief 7y agoThat was just a typo, I meant the source for is-odd. I copy-pasted it. I use that exact syntax all the time in code, you don't need to be patronizing.
- ojosilva 7y agoA year back I dropped a proposal idea at the EcmaScript discussion list, I hope it get's picked up sometime. My idea is that `let`, `var` and `const` return the value(s) being assigned. Basically I miss being able to declare variables in the assertion part of `if` blocks that are scoped only during the `if()` block existence (including `else` blocks). Something along these lines: if( let row = await db.findOne() ) { // row available here } // row does not exist here The current alternative is to declare the variable outside the `if()` block, but I believe that is inelegant and harder to read, and also requires you to start renaming variables (ie. row1, row2...) due them going over their intended scope. As previous art, Golang's: if x:=foo(); x>50 { // x is here } else { // x is here too } // x is not scoped here And Perl's if( ( my $x = foo() ) > 50 ) { print $x }
- cpeterso 7y agoYou can also declare variables in conditional statements in C/C++ like https://godbolt.org/z/h0BR8K https://godbolt.org/z/h0BR8K int foo(int); int bar(int x) { if (int y = foo(x)) return 0; return x; }
- snek 7y agoThis has been discussed a few times on IRC, but no one has made a proposal yet afaik.
- cocoflunchy 7y agoAlso see assignment expressions recently adopted in python 3.8: https://www.python.org/dev/peps/pep-0572/ https://www.python.org/dev/peps/pep-0572/
- bitwize 7y agoUmmm... 25^2 is 625. 15^2 is 225 (see the Object.fromEntries example). I mean, I knew JavaScript math was a bit sloppy due to the use of floating point everywhere, but I hope it's not THAT bad...
- ihuman 7y agoI think it's been changed after you posted this comment. It now shows that 15^2 is 225.
- jonstaab 7y agoIsn't the new function string representation backwards incompatible? Having struggled with javascript's lame error tooling I could see people actually using it in production too.
- jorangreef 7y agoMost of this is sugar, e.g. flat() and flatMap(), out of scope for a language spec. Function.toString being more accurate is helpful. But real progress would be removing dangerous backtracking regular expressions in favor of RE2: https://github.com/google/re2/wiki/Syntax https://github.com/google/re2/wiki/Syntax
- mhd 7y agoSo, what coffeescript features are we still missing after this round?
- la12 7y agoAt this point, I'm convinced that Javascript is basically a jobs creation program. We go on adding fancy new syntax for little or no gain. The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times. Similarly, python which was resistant to the idea of 20 ways to do the same thing, also seems to be going in the direction of crazy things like the "walrus" operator which seems to be increasing the cognitive load by being a little more terse while not solving any fundamental issues. Nothing wrong with functional paradigm, but extra syntax should only be added when it brings something substantial valuable to the table. Also, features should be removed just as aggressively as they are added, otherwise you end up with C++ where you need less of a programmer to be able to tell what a given expression will do and more of a compiler grammar lawyer who can unmangle the legalese.
- shiv86 7y ago>The whole arrow function notation, for example, buys nothing new compared to the old notation of writing "function(....){}" other than appearing to keep up with functional fashion of the times. Incorrect - The main advantage is fat arrow syntax can keep lexical scope of this current context. Hence you dontneed to implement that=this antipattern
- la12 7y agoIn that case, they should have deprecated the "function(){}" notation or at least made it such that arrow function doesn't overlap it. The current scene is that most people don't know what the real difference between arrow and function notations and this leads to a lot more number of bugs than if they weren't this overlapping. Overall, my point is, this just leads to poor ergonomics and you'll have a larger number of avoidable bugs.
- hombre_fatal 7y ago> The current scene is that most people don't know what the real difference between arrow and function notations That's hard to believe unless you're working on the most amateur of teams. There's a point where you have to expect people to understand the most basic concepts of the language/tools they're hired to use. This shouldn't require more than a simple 5min pull-aside of the junior developer. Also, you can't change function(){}'s dynamic scope without breaking the web, which is a major downside for your suggested upside of developers not having to learn the distinction. function(){} was always confusing from day one. ()=>{} is a move back toward intuitiveness.
- bryanrasmussen 7y agoI think the flatMap method is pretty solid evidence for my contention the language is really getting bloated now.
- DonHopkins 7y agoIs that all there is that's new? Maybe it's a good thing that JavaScript is finally slowing down.
- pier25 7y agoI feel after ES6 and async/await in ES7 we're getting pretty meager upgrades. IMO the three features that would make a much more significant impact in front end work are: - optional static types - reactivity - some way to solve data binding with the DOM at the native level
- codenirvana 7y agoYep, waiting for private methods (Stage 3) and private-fields.
- Already__Taken 7y agoWhy does flatmap exist? What's against `sentence.map().flat()`