The TC39 Process
tc39.es
tc39.es
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.
- 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.
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
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?
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
}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.
Weird shit still slips through (I think the whole import() and import.meta is an awful hacky addition that could've been made better), but there are actual discussions on how to make things and most things end up somewhat carefully considered.
It's slow as molasses, and not necessarily the best result wins. But in comparison to "here's this chrome-only badly specified pretense of a spec that chrome is already shipping, and all discussion be damned" it works well
The "keyword followed by a dot?!" aspect that initially felt strange to me isn't that off-the-wall either, because it also exists in the form new.target: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
So import is:
- a keyword that can only exist at top level at the top of the file
- except when it looks like a function, but it's not a function and doesn't behave like one
- and it's also apparently and object because it has what looks like a property on it
IIRC there was a proposal for an Import (or was it System?) that would take care of things like import.meta etc., but it was deemed to complex. Instead we have import()
In JS functions are objects, so this isn't that weird for JS. (For easy example, JQuery alone used this a lot with `$('selector')` and `$.ajax(…)` and all sorts of other things.)
It may still be useful to get the Observables proposal further along for the same reasons it is great to have Promises standardized including in terms of encouraging usage in more native APIs. It is kind of silly that none of the SomethingObserver browser/DOM APIs (ResizeObserver, IntersectionObserver, et al) naturally return things that are duck-typably Observables despite "Observer" in their name and always need Observable wrappers.
As Ben Lesh explains, Observable is a primitive that is very powerful on its own. It can produce multiple values (in which it is similar to async iterables and different from promises); it has a mechanism for cancellation (as opposed to promises, and probably even async iterables); it probably can be both synchronous (if the data it produces finishes synchronously) and asynchronous; it is lazy, which makes it more composable than promises. Multiple values and cancellation are the big things I can remember.
Pipeline libraries (aka "operators") are downstream from that, and can be built in the userland.
My impression has been that TC-39 has had a harder time being convinced they are a primitive that should be codified at the language level, because they are today mostly wrapped in large user space libraries just fine and don't need direct syntax (such as the relationships between Iterables and Generators and Iterables and for/of; or the relationship between Promises and async/await). Even the DOM disconnect here where I personally would love to see the Primitive more actively used is not entirely TC-39's fault because DOM APIs are on "the other side of the fence" from TC-39 in the WHATWG and W3C working groups.
I'd love to see the Observable proposal move further along. I realize it hasn't because my impression is that it isn't a priority from TC-39's perspective.
Again, I personally disagree with that impression. It's just the impression I'm getting when I read through issues and comments on the proposal.
[0] - If I remember correctly, he explains it here: https://youtu.be/IX86lE-skeQ?t=2107
If you can find someone willing to do that, I'm happy to help you find a TC39 delegate to help you with the committee stuff (Either with my Node.js hat with our delegate or with my Microsoft one). I'll also guarantee Ben (who is a friend) would be happy to help he just doesn't have the time to work on the proposal itself.