331–340 of 411 posts
That 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.
flatMap is always so unituitive (not a word) for me for some reason. I messed with it a bunch in C#'s LINQ and RxJS and I already forgot the purpose. Not sure what it is that makes it so unnatural for me.
JS flatMap = C# SelectMany
A 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() ) {…
Nice. I like use of the let/var/const keyword to disambiguate from the accidental `if (x = y)` when intending to use `==`.
Earlier quoted context omitted.
That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it. If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm s…
> Regarding transpilation surely it's not as standard as you make it out to be? The impression I got from working on various projects over the past couple of years was that if the build doesn't include Babel/Webpack/Packet/etc then you're not doing a 'professional' job. > ... handwritten javascript is not that rare nowadays, is it? I love handwriting vanilla javascript, though I only really get the opportunity to do…
If you have alternative recommendation that's not these tools, I'd be curious to hear it.
Now 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 [2] https://github.com/tc39/proposal-optional-chaining
Waiting for Optional Chaining. It's in Stage 3 already.
Honest 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…
Also about the “subset” thing: the last 10 years or so I have been moving away from OOP, and more towards FP, so stuff like class support or Typescript have been a big yawn, anyway.
We had “C with classes” (I.e. C++ as it was known at the time) shoved down our throats in Uni back in the 80s, since garbage collection was impractical. That “wisdom” turned out to be short lived, and thus my migration towards FP (beyond the Lisp I had in an AI class back in the 80s)
The 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.
What's a good example of this sort of language?
Earlier quoted context omitted.
It 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.
Agreed. 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.
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.
I 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
Honest 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…
That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it. If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm s…