The Future of JavaScript: What Awaits Us

https://jsdev.space/future-of-javascript/

by javatuts • 11 months ago

22 14 11 months ago

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.

pjmlp• 11 months ago

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.

Klonoar• 11 months ago

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.

dtagames• 11 months ago

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.

Alifatisk• 11 months ago

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?

rafram3• 11 months ago

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.

spankalee• 11 months ago

It's needed for Houdini and possibly CSS, which would benefit from being able to copy the JS spec.

apatheticonion2• 11 months ago

I just want wasm so I can write web applications in Rust

rafram3• 11 months ago

Every major browser supports WASM and has for years.

apatheticonion2• 11 months ago

Missing threads and bindings for the system/DOM interfaces

idontwantthis2• 11 months ago

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.

rafram3• 11 months ago

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

idontwantthis2• 11 months ago

Pour one out for the Array#smoosh() that could have been.

The Future of JavaScript: What Awaits Us

Related Stories