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.

> Those that still writes in vanilla JS are like those who still build apps in assembly langauge.

…Huh? Are you referring to transpilation?

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

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.

The main reason people don't write much vanilla JS is because they're writing TypeScript instead.

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.]

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.

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

> what’s next, pattern matching?

Oh boy do I have news for you... https://tc39.es/proposal-pattern-matching/

:P

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

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

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.

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-ref...

[1] https://timdeschryver.dev/blog/pattern-matching-examples-in-...

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.

Assignment is already an expression, no?

    console.log(x = "hello");

Now try it with a constant:

    console.log(const x = "hello");

Doesn't work.

That's a declaration. That would be cool. Doesn't currently work with let or var either.

I think this is basically assigning values to the window object, similar to updating values in any object.

e.g.

    const a = { b: 1 }
    console.log(a.b = 2); // logs 2

Only if you haven't already declared the variable. e.g.

    let x;
    console.log(x = 'hello');

My point is that the `x = 'hello'` part is an assignment, and an expression, and has the exact same semantics regardless of whether you use that expression as a statement. So, assignments would seem to be expressions.

I also REALLY want records and tuples.

Unfortunately that proposal seems to be kinda dead.

React is a fundamentally flawed framework because of the lack of this feature. It inverts the responsibility of any non-primitive prop by putting the burden on the parent element instead of the child to decide when to rerender things. So elements are no longer self-contained if they receive any non-primitive values (besides react elements).

The React compiler auto-memoization that facebook is pushing also addresses this issue through build-time magic. I not fond of this approach.

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.

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

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.

To be honest, this reads kind of insane, and reminds me of how wasm was at least partially designed around V8 idiosyncrasies and limitations.

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

BigInt shipped because financial organizations needed it for certain applications.

I know why people needed it. It’s obviously useful. However, it’s still a relatively niche use case and rarely encounter people using it, especially compared to how many people I encounter asking about dealing with compound keys in maps or how to deeply compare two static blobs of JSON-style data. I understand why the implementers felt burned by its lack of adoption given its burden of implementation, but I’m also a bit surprised they expected more use.

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!

are there polyfills for those proposals?