Hacker News Reader

Comment by iddan | Hacker News Reader

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 felt like match and pipes are just around the corner as well as bigger changes like decorators (and I bet this is why so many libraries rely on decorators right now even though they are still stuck in the review process).

I would love to see the match proposal coming through (especially now that it was added to all the major PLs) also I think a proposal like Type Annotations as comments can really improve the lives of engineers right now. Still, kudos to everyone involved with it.

View on HN

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.

For reference.

Pattern matching: https://github.com/tc39/proposal-pattern-matching

Do expression: https://github.com/tc39/proposal-do-expressions

Pipe operator: https://github.com/tc39/proposal-pipeline-operator

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?

> 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
    }

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.

Chrome has done an IE 5 move, hence the slowdown.

I just want record+tuples to land.

Reply on news.ycombinator.com