I kind off don't see the point with Random.Seeded being part of Ecmascript? It's useful for sure, but isn't that something one could implement for themselves if needed? Is it really that sought after feature from the whole community?
Why make people implement their own PRNG (in userspace code that’ll be slower than the built-in routine) for such a basic use case? I don’t know of any other major language in the world that doesn’t support setting the seed.
> I suppose to not break existing code that implements a dispose method
Exactly. This is standard for new "magic" object members - see [Symbol.species], [Symbol.iterator], and so on. Your existing dispose() method might take arguments, or it might return a promise, or maybe you have a field called dispose that isn't a dispose() method at all. This approach is slightly less pretty, but it preserves backwards-compatibility and avoids conflicts with the many weird, decades-old JS libraries still floating around on the web.
(Also see Array#flat(), which had to be called that because some ancient libraries modified the Array prototype to add a #flatten() method... It's a mess out there.)
Looks good but what about Named Parameters? Why on earth is Javascript still missing such an important feature? I know you can kind of fake it with objects, but is clunky in comparison.
That's actually a benefit. It allows the type signature to be used to compose and verify what you're passing to a function, and to use that same interface in other places.
I kind off don't see the point with Random.Seeded being part of Ecmascript? It's useful for sure, but isn't that something one could implement for themselves if needed? Is it really that sought after feature from the whole community?
Why make people implement their own PRNG (in userspace code that’ll be slower than the built-in routine) for such a basic use case? I don’t know of any other major language in the world that doesn’t support setting the seed.
It's needed for Houdini and possibly CSS, which would benefit from being able to copy the JS spec.
Can anyone explain why they chose the [Symbol.dispose] syntax instead of regular .dispose syntax?
I suppose to not break existing code that implements a dispose method, but it is a lot less friendly than regular method syntax.
> I suppose to not break existing code that implements a dispose method
Exactly. This is standard for new "magic" object members - see [Symbol.species], [Symbol.iterator], and so on. Your existing dispose() method might take arguments, or it might return a promise, or maybe you have a field called dispose that isn't a dispose() method at all. This approach is slightly less pretty, but it preserves backwards-compatibility and avoids conflicts with the many weird, decades-old JS libraries still floating around on the web.
(Also see Array#flat(), which had to be called that because some ancient libraries modified the Array prototype to add a #flatten() method... It's a mess out there.)
Pour one out for the Array#smoosh() that could have been.
For anyone looking for context on smooshgate: https://developer.chrome.com/blog/smooshgate
Looks good but what about Named Parameters? Why on earth is Javascript still missing such an important feature? I know you can kind of fake it with objects, but is clunky in comparison.
That's actually a benefit. It allows the type signature to be used to compose and verify what you're passing to a function, and to use that same interface in other places.
Exactly because of that, it would only cut the curly brackets.
Also it is the same approach done in C and C++, another two languages where being clunky is a something we got used to.
Rust has the same issue. In practice it’s just not a big deal, I think about it maybe once every six months or so.
I just want wasm so I can write web applications in Rust
Every major browser supports WASM and has for years.
Missing threads and bindings for the system/DOM interfaces
[dead]