311–320 of 411 posts
Earlier quoted context omitted.
And you need to change 3 lines in total (also you need to make changes mid-lines, too) in order to simply view the data in between, vs only 1 line. And by the way - if you paid attention in the first place my post actually has exactly what you've just written.
Meaningful names? I don't think so.
arr.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.
Earlier quoted context omitted.
IMHO the current state of affairs is actually the best possible scenario. - Experimental language proposals can be tested in the wild - Real non-ivory-tower feedback is raised to TC39 - Everything feeds into the canonical ES spec (~no splintering) - Us regular folk are able to harness new syntax immediately - Users continue to have their old runtimes supported
I find these to be good points, but there is something missing for me that makes this "best possible scenario" only pretty good. JS is a notoriously quirky and inconsistent programming language. Clearly it's sufficiently usable for writing complex, powerful and reliable programs, but it's error-prone for non-experts and encourages programming patterns that make importing accidental complexity the norm. For many progr…
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…
IMHO the current state of affairs is actually the best possible scenario. - Experimental language proposals can be tested in the wild - Real non-ivory-tower feedback is raised to TC39 - Everything feeds into the canonical ES spec (~no splintering) - Us regular folk are able to harness new syntax immediately - Users continue to have their old runtimes supported
Earlier quoted context omitted.
From my perspective, it is less about what we can use in the browser without transpilation, but where the js ecosystem is heading. I personally only want to write JS that is in spec because in 5 years something like decorators might not be a thing. Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are no…
> Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I agree, this is super important. My inclination whenever I did into a JS project has been to use lodash/underscore everywhere for everything, assuming that it is popular enough that…
Personally, I only lodash for the debounce functionality.
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…
1. Node.js greatly benefits from these features. Transpiling is not as prevalent there
2. Some people do exclusively target "evergreen" browsers and don't care about IE support
3. Those that do differential bundling (different bundles per browsers) can see quite a performance boost by not transpiling on newer browsers
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…
Earlier quoted context omitted.
IMHO the current state of affairs is actually the best possible scenario. - Experimental language proposals can be tested in the wild - Real non-ivory-tower feedback is raised to TC39 - Everything feeds into the canonical ES spec (~no splintering) - Us regular folk are able to harness new syntax immediately - Users continue to have their old runtimes supported
I find these to be good points, but there is something missing for me that makes this "best possible scenario" only pretty good. JS is a notoriously quirky and inconsistent programming language. Clearly it's sufficiently usable for writing complex, powerful and reliable programs, but it's error-prone for non-experts and encourages programming patterns that make importing accidental complexity the norm. For many progr…
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() ) {…