4 ms·

The TC39 Process

28 points by legrande 4y ago

dmitriid 4y ago
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
- frou_dh 4y ago
  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 https://vitejs.dev/guide/api-hmr.html). 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/Reference/Operators/new.target https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - dmitriid 4y ago
    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()
    - WorldMaker 4y ago
      > 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.)
      - dmitriid 4y ago
        Yes, but import() isn't a function ;)
iddan 4y ago
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.
- 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?
azangru 4y ago
I'm rooting for the Observable proposal that got stuck in 2017 or thereabouts :-(
- inglor 4y ago
  On funding and work and someone willing to spend the time to write and do the research - not because of inherent opposition.
  - WorldMaker 4y ago
    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.
    - azangru 4y ago
      > 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.
cphoover 4y ago
Anyone know the state of the Record+Tuple proposal? I really would like to see the introduction of truly immutable data structures
- WorldMaker 4y ago
  The main tc39/proposals (on Github) Repo lists that proposal as currently Stage 2. Appears to be under active review for Stage 3: https://github.com/tc39/proposal-record-tuple/issues/336 https://github.com/tc39/proposal-record-tuple/issues/336
selfmodruntime 4y ago
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.
cute_boi 4y ago
They forget to mention "Politics".

28 points by legrande 4y ago

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

frou_dh 4y ago
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 https://vitejs.dev/guide/api-hmr.html). 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/Reference/Operators/new.target https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- dmitriid 4y ago
  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()
  - WorldMaker 4y ago
    > 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.)
    - dmitriid 4y ago
      Yes, but import() isn't a function ;)

iddan 4y ago

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.

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?

azangru 4y ago

I'm rooting for the Observable proposal that got stuck in 2017 or thereabouts :-(

inglor 4y ago
On funding and work and someone willing to spend the time to write and do the research - not because of inherent opposition.
- WorldMaker 4y ago
  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.
  - azangru 4y ago
    > 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.

cphoover 4y ago

Anyone know the state of the Record+Tuple proposal? I really would like to see the introduction of truly immutable data structures

WorldMaker 4y ago
The main tc39/proposals (on Github) Repo lists that proposal as currently Stage 2. Appears to be under active review for Stage 3: https://github.com/tc39/proposal-record-tuple/issues/336 https://github.com/tc39/proposal-record-tuple/issues/336

selfmodruntime 4y ago

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.

cute_boi 4y ago

They forget to mention "Politics".