5 ms·

It feels like there was a short period of time after ES6 that much more proposals were made and things progressed faster. I remember in that period of time it f

• nicoburns 4y ago
  All I really want is for JavaScript to become properly expression oriented. Which I think would mean: - Match expressions - If-else expressions - Do expression (expression blocks that begin the block with the "do" keyword to disambiguate them from object literals) You can almost always write JavaScript in a functional style with mostly immutable variables. But occasionally you need to use a mutable variable just because it can take one of 3 or more possible values and JS doesn't support doing that in an expression-oriented way without using closures, and it's infuriating.
  • gherkinnn 4y ago
    For reference. Pattern matching: https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching Do expression: https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions Pipe operator: https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator
  • davnicwil 4y ago
    Reading the proposal, I'm not sure I get the usecase for the do expression. Could I just achieve the same with a function call? Or if I want to inline the contents of that function in the same code for readability preference, aside from syntax sugar is there a difference from (() => { ... })()? Or have I missed something about some extra features it provides?
    • nicoburns 4y ago
      > aside from syntax sugar is there a difference from (() => { ... })() Well it will be more efficient unless the compiler is smart enough to inline the closure call. If it is, then no, it's just sugar. But as you say, the reason to inline code is for readability, and sugar is useful for that. I tend to find I don't use (() => { ... })() much because all the noise often makes it less readable overall. An example where I would use it: const foo = do { let foo = "bar"; if (complexCondition()) foo = "baz"; if (condition2()) foo = "quz"; foo }
    • WorldMaker 4y ago
      The best arguments for do expressions I've seen are in recent versions of the Pipe Operator proposal which now suggests where do expressions can produce some good simpler looking pipelines with the Pipe operator. Aside from syntax sugar, it's also a tiny spot for some JIT compiler and garbage collector optimization. Arrow functions still create Function objects, which is a tiny bit of administrative overhead and possible garbage to collect. Most JIT engines are somewhat used to "IIFEs" and can optimize common patterns of that, but do notation possibly directly suggests "not a real Function" or "entirely inlinable function" to the JIT in ways that even arrow functions cannot. I don't know if that sort of micro-optimization is a great argument for do expressions, however.
• pjmlp 4y ago
  Chrome has done an IE 5 move, hence the slowdown.
• cphoover 4y ago
  I just want record+tuples to land.