6 ms·

There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes de

There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, "now get Records and Tuples going too! You can skip that silly Pipe-syntax war if you want!"

noduerme 2y ago
Records.. Wasn't Dictionary an ECMA5 proposal or was that just a novel touch in AS3? [edit: For those who don't know, Dictionary was a type in AS3 that let you use any object reference or string or number as a unique key, with any type of value attached. Garbage collection worked around this so it wasn't a weak reference as long as the dictionary object itself was alive. Think of a Javascript Set except with strongly typed keys of any kind you specified. Errors thrown at compile time. God..I miss that language.]
- jitl 2y ago
  We’ve had Map with those semantics since 2014, came out in Chrome a few months before Set. Record/Tuple objects are immutable primitives with structural equality, not object reference equality. So little relation to AS3 Dictionary/ES6 Map, besides being possible keys for Map/Set.
  - klabb3 2y ago
    > Record/Tuple objects are immutable primitives with structural equality TIL and also god that would be amazing, almost to the point of making JS/TS actually nice if done right (what’s next, pattern matching?). The number one footgun in JS imo is the combination of mutability and reference copying. Immutable or at least easy-to-copy plain old data is fantastic when it is well supported in the language.
    - for1nner 2y ago
      > what’s next, pattern matching? Oh boy do I have news for you... https://tc39.es/proposal-pattern-matching/ https://tc39.es/proposal-pattern-matching/ :P
k__ 2y ago
I had the impression the implementation happens first, then the ratification later when things worked out well.
z3t4 2y ago
It's not just the major browser makers. I was working on a JavaScript inference engine around when ES6 started to roll out, I had decent ES5 support but when all the syntatic updates came I had to give up. They basically killed the JavaScript ecosystem with all the updates. We only have complile to JS languages now. Those that still writes in vanilla JS are like those who still build apps in assembly langauge.
- bolognafairy 2y ago
  > Those that still writes in vanilla JS are like those who still build apps in assembly langauge. …Huh? Are you referring to transpilation?
- fiala__ 2y ago
  > We only have complile to JS languages now. Those that still writes in vanilla JS are like those who still build apps in assembly langauge. I strongly disagree, it's never been easier and more pleasant to write modern JS without transpilers. I've only rarely had to reach for a framework or transpiler in the last few years.
- andrewmcwatters 2y ago
  Come now, this is silly. There are plenty of us that are explicitly avoiding build phases because, for us, what needs to be built adds very little benefit. Working with assembly is comparatively expert work that few professionals are good at. JavaScript can be written by kids.
- stevage 2y ago
  The main reason people don't write much vanilla JS is because they're writing TypeScript instead.
dkdbejwi383 2y ago
The one I want is pattern matching (https://tc39.es/proposal-pattern-matching/ https://tc39.es/proposal-pattern-matching/), which is still at stage 1 so many years away, sadly.
- halfmatthalfcat 2y ago
  Pattern matching (and expression based assignment, of which idk if there’s a proposal for or not) are two things that would really drive a ton of value.
  - CharlieDigital 2y ago
    It's going to end up looking a lot like C# [0][1]; these two/three (JS/TS, C#) languages have been converging for a while now. Now just waiting for C# to get official first party discriminated unions! [0] https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/patterns https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... [1] https://timdeschryver.dev/blog/pattern-matching-examples-in-csharp https://timdeschryver.dev/blog/pattern-matching-examples-in-...
    - adabyron 2y ago
      Just an FYI for those unaware TS & C# are both creations of Anders Hejlsberg & his colleagues at Microsoft. Both are some of my favorite languages as well. We would all benefit if JS was more like C# in my opinion.
  - recursive 2y ago
    Assignment is already an expression, no? console.log(x = "hello");
    - 65 2y ago
      Now try it with a constant: console.log(const x = "hello"); Doesn't work.
inbx0 2y ago
It's great that Temporal is coming, and I'm sure there are bunch of other nice things coming up too, but unfortunately I don't share your optimism with the specific proposals that you mention (even though those would be very nice). Pipelines, pattern matching and records+tuples have all been in the works for 4+ years, and are all still in stages 1-2. I don't think any of them has seen any significant progress in the past year, except maybe pattern matching. According to an issue in the records and tuples repo, there's been pushback on the value semantics of it (i.e. whether === can be made to work). Dropping value semantics would significantly reduce the whole proposal's usefulness. I think all of them are at least a year or two away from reaching stage 3, if they ever do. But hey at least we now have array grouping functions.
- deleted 2y ago
  [deleted]
rimunroe 2y ago
Records and tuples are unlikely to ever ship, or at least are extremely unlikely to ship with the semantics around equality people want. My understanding is that browser vendors already have pretty strong opposition to introducing new primitives at this point. Reading this thread[1] will give some explanation as to the hiccups with how equality would behave. It sucks, because while I wouldn't have expected BigInt to have gotten much adoption in the first place, I constantly run into cases where I'd want collections with structural equality. Additionally, my understanding is that the opposition to adding new primitives also affects pattern matching, though I'm not sure why. I'm much less up to date on that proposal. [1] https://github.com/tc39/proposal-record-tuple/issues/387 https://github.com/tc39/proposal-record-tuple/issues/387
- pspeter3 2y ago
  That's a bummer. I wish there was a way to use non primitive objects in Maps & Sets more effectively then. Perhaps a well known Symbol for hashCode or something.
- int_19h 2y ago
  To be honest, this reads kind of insane, and reminds me of how wasm was at least partially designed around V8 idiosyncrasies and limitations.
  - rimunroe 2y ago
    > To be honest, this reads kind of insane Could you clarify which part you’re referring to? I’m disappointed at them feeling trepidation after BigInt, but the thread I linked (and some other discussions I’ve seen) make me understand why they’d choose to focus effort elsewhere. It would be a monumental change and it’s not entirely clear how much of the community outside the React and similar ecosystems would adopt it. It might have significant performance issues for the desired use cases and choices about value semantics would affect usability.
- theplatman 2y ago
  BigInt shipped because financial organizations needed it for certain applications.
culi 2y ago
Even when it does ship it'll probably be another year before enough browsers have updated to safely use it in production. So you'll need a polyfill. Which you can start using today anyways!
- agos 2y ago
  are there polyfills for those proposals?
deleted 2y ago
[deleted]

noduerme 2y ago

Records.. Wasn't Dictionary an ECMA5 proposal or was that just a novel touch in AS3? [edit: For those who don't know, Dictionary was a type in AS3 that let you use any object reference or string or number as a unique key, with any type of value attached. Garbage collection worked around this so it wasn't a weak reference as long as the dictionary object itself was alive. Think of a Javascript Set except with strongly typed keys of any kind you specified. Errors thrown at compile time. God..I miss that language.]

jitl 2y ago
We’ve had Map with those semantics since 2014, came out in Chrome a few months before Set. Record/Tuple objects are immutable primitives with structural equality, not object reference equality. So little relation to AS3 Dictionary/ES6 Map, besides being possible keys for Map/Set.
- klabb3 2y ago
  > Record/Tuple objects are immutable primitives with structural equality TIL and also god that would be amazing, almost to the point of making JS/TS actually nice if done right (what’s next, pattern matching?). The number one footgun in JS imo is the combination of mutability and reference copying. Immutable or at least easy-to-copy plain old data is fantastic when it is well supported in the language.
  - for1nner 2y ago
    > what’s next, pattern matching? Oh boy do I have news for you... https://tc39.es/proposal-pattern-matching/ https://tc39.es/proposal-pattern-matching/ :P

k__ 2y ago

I had the impression the implementation happens first, then the ratification later when things worked out well.

z3t4 2y ago

It's not just the major browser makers. I was working on a JavaScript inference engine around when ES6 started to roll out, I had decent ES5 support but when all the syntatic updates came I had to give up. They basically killed the JavaScript ecosystem with all the updates. We only have complile to JS languages now. Those that still writes in vanilla JS are like those who still build apps in assembly langauge.

bolognafairy 2y ago
> Those that still writes in vanilla JS are like those who still build apps in assembly langauge. …Huh? Are you referring to transpilation?
fiala__ 2y ago
> We only have complile to JS languages now. Those that still writes in vanilla JS are like those who still build apps in assembly langauge. I strongly disagree, it's never been easier and more pleasant to write modern JS without transpilers. I've only rarely had to reach for a framework or transpiler in the last few years.
andrewmcwatters 2y ago
Come now, this is silly. There are plenty of us that are explicitly avoiding build phases because, for us, what needs to be built adds very little benefit. Working with assembly is comparatively expert work that few professionals are good at. JavaScript can be written by kids.
stevage 2y ago
The main reason people don't write much vanilla JS is because they're writing TypeScript instead.

dkdbejwi383 2y ago

The one I want is pattern matching (https://tc39.es/proposal-pattern-matching/ https://tc39.es/proposal-pattern-matching/), which is still at stage 1 so many years away, sadly.

halfmatthalfcat 2y ago
Pattern matching (and expression based assignment, of which idk if there’s a proposal for or not) are two things that would really drive a ton of value.
- CharlieDigital 2y ago
  It's going to end up looking a lot like C# [0][1]; these two/three (JS/TS, C#) languages have been converging for a while now. Now just waiting for C# to get official first party discriminated unions! [0] https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/patterns https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... [1] https://timdeschryver.dev/blog/pattern-matching-examples-in-csharp https://timdeschryver.dev/blog/pattern-matching-examples-in-...
  - adabyron 2y ago
    Just an FYI for those unaware TS & C# are both creations of Anders Hejlsberg & his colleagues at Microsoft. Both are some of my favorite languages as well. We would all benefit if JS was more like C# in my opinion.
- recursive 2y ago
  Assignment is already an expression, no? console.log(x = "hello");
  - 65 2y ago
    Now try it with a constant: console.log(const x = "hello"); Doesn't work.

inbx0 2y ago

It's great that Temporal is coming, and I'm sure there are bunch of other nice things coming up too, but unfortunately I don't share your optimism with the specific proposals that you mention (even though those would be very nice). Pipelines, pattern matching and records+tuples have all been in the works for 4+ years, and are all still in stages 1-2. I don't think any of them has seen any significant progress in the past year, except maybe pattern matching. According to an issue in the records and tuples repo, there's been pushback on the value semantics of it (i.e. whether === can be made to work). Dropping value semantics would significantly reduce the whole proposal's usefulness. I think all of them are at least a year or two away from reaching stage 3, if they ever do. But hey at least we now have array grouping functions.

deleted 2y ago
[deleted]

rimunroe 2y ago

Records and tuples are unlikely to ever ship, or at least are extremely unlikely to ship with the semantics around equality people want. My understanding is that browser vendors already have pretty strong opposition to introducing new primitives at this point. Reading this thread[1] will give some explanation as to the hiccups with how equality would behave. It sucks, because while I wouldn't have expected BigInt to have gotten much adoption in the first place, I constantly run into cases where I'd want collections with structural equality. Additionally, my understanding is that the opposition to adding new primitives also affects pattern matching, though I'm not sure why. I'm much less up to date on that proposal. [1] https://github.com/tc39/proposal-record-tuple/issues/387 https://github.com/tc39/proposal-record-tuple/issues/387

pspeter3 2y ago
That's a bummer. I wish there was a way to use non primitive objects in Maps & Sets more effectively then. Perhaps a well known Symbol for hashCode or something.
int_19h 2y ago
To be honest, this reads kind of insane, and reminds me of how wasm was at least partially designed around V8 idiosyncrasies and limitations.
- rimunroe 2y ago
  > To be honest, this reads kind of insane Could you clarify which part you’re referring to? I’m disappointed at them feeling trepidation after BigInt, but the thread I linked (and some other discussions I’ve seen) make me understand why they’d choose to focus effort elsewhere. It would be a monumental change and it’s not entirely clear how much of the community outside the React and similar ecosystems would adopt it. It might have significant performance issues for the desired use cases and choices about value semantics would affect usability.
theplatman 2y ago
BigInt shipped because financial organizations needed it for certain applications.

culi 2y ago

Even when it does ship it'll probably be another year before enough browsers have updated to safely use it in production. So you'll need a polyfill. Which you can start using today anyways!

agos 2y ago
are there polyfills for those proposals?

deleted 2y ago

[deleted]