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.
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.
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.
In my opinion TC39 process works okay, and is much better than whatever passes for process at w3c.
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
When I had an opportunity to make use of import.meta, I was pleasantly surprised because it enabled me to write a "userspace" hot-module-reload policy with hardly any code (for a browser game when developing using Vite: https://vitejs.dev/guide/api-hmr.html).
Yes, new.target was cited as a precedent for this decision. Even though new.target itself was such an ugly hack that the spec was specifically coded for new.target alone.
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()
> and it's also apparently and object because it has what looks like a property on it
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.)
I still think that the entire work on all ideas within the TC39 should stop and their efforts should instead focus on shipping a viable JS standard library in all browsers.
My impression was that it stalled out mostly because to make good use of Observables you need a pipeline library like RxJS or xstream anyway, it's not the job of TC-39 to pick a "winner library", and if you are always using libraries anyway it's "easy enough" to just align the libraries themselves for interop with each other through duck typing, which they all sort of did on their own. The syntax that these libraries could benefit the most from is in the separate Pipe Operator proposal, which has been progressing through the stages and doesn't seem to be stalled, and there's intentionally no direct dependency on Observables (as the Pipe Operator also works great for Iterables libraries).
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.
> My impression was that it stalled out mostly because to make good use of Observables you need a pipeline library like RxJS or xstream anyway,
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.
It just sounds like you agree with my full comment if you read the whole thing? I do know what Observables are. I personally do think they are a useful primitive even without the downstream pipeline libraries (though a good pipeline library is indispensable for getting good work done).
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.
Funding is the key, yes. As far as I understand from Ben Lesh [0], a TC39 proposal needs a champion, and a champion can only be a TC39 member, and to become a TC39 member you need a company financially sponsoring your place. So previously, when Netflix was sponsoring Jafar Husain, he was able to prepare and update the Observable proposal; but after he left Netflix, the Observable proposal has lost its champion. Ben isn't on TC39 (he wasn't there even when he was at Google, let alone now), so he can't move the needle forward. He mentioned one person — who I think was involved in the proposal for the pipeline operator — as being sort of interested; but not to the point of becoming a champion. Without a champion — which means without a strong interest by big companies — this proposal is fated to remain stalled. I believe I heard Ben say that he doesn't have high hopes for it anymore.
The blocker isn't TC39 membership or being a champion though. It's blocked on someone actually working on it, writing the docs and editing the spec text, answering the questions brought up etc.
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.
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.