Should JavaScript be split into two languages?

Posted by em-bee 10/26/2024

Should JavaScript be split into two languages?(devclass.com)

142 points | 312 commentspage 2

ninetyninenine 10/26/2024|

No. Javascript should be split into 3 languages and html and css should be split into 20 languages.

Seriously frontend is already the most fragmented and fast changing area of web there is. Don’t split the language.

ttoinou 10/26/2024||

You wouldn’t see much difference as a user of those tools. And if you’re writing vanilla JS, you’d have less features creeping in over time. So it seems like you would benefit from this kind of change.

ninetyninenine 10/26/2024||

Yeah but if I change jobs or work on another project then I’d have to learn two standards.

loftyal 10/27/2024||

Did you read the article? The sugared JS would be a superset of the target JS. So you would only need to learn the sugared.

ninetyninenine 10/27/2024||

Need to learn both because I still need to know what is sugar in order to use the subset.

akira2501 10/26/2024|||

> and fast changing area

Who cares? If backwards compatability is maintained then this fails to have any impact on my experience as a developer. It sounds like the VM maintainers are busy making their own lives hell. Not my problem.

wiseowise 10/26/2024||

> Who cares?

I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.

akira2501 10/26/2024||

I use the language. The existence of new language features has not forced me to adopt them. The standard library for browsers is a different story but it is always going to be.

Thankfully.. both maintain reasonable backwards compatability where security is not otherwise implicated.

wiseowise 10/27/2024||

> The existence of new language features has not forced me to adopt them.

You still need to be aware of them when you encounter unfamiliar syntax.

bitwarrior 10/26/2024||

You didn't read the article.

tgv 10/24/2024||

Fuck, no. Everyone's free to make better tooling, but don't standardize it. There's no point. It'll only lead to further fragmentation. Libraries and frameworks will be split between plain JS and whatever this new version will be called. Just freeze the language and be done.

odyssey7 10/26/2024||

Imagine Google not having the resources to maintain their V8 engine after the hiring downturn, and telling us they want to change JavaScript because their V8 engine has become challenging to maintain.

A proposal rooted in attempts to improve the language would be one thing. This appears to be about Google struggling with technical competencies and not having the budget to do the right thing.

“A Google engineer presented … JavaScript VMs (virtual machines), they say, are “already very complex because of pressure to be fast,” which compromises security, and “feels especially bad” when new features do not get adoption.“

“The foundational technology of JavaScript should be simple, according to the proposal, because security flaws and the “complexity cost” of the runtimes affects billions of uses, whereas the benefits are restricted to developers and applications that actually use that complexity to advantage.”

Maybe try something besides c++ for V8 if you are having security issues?

The apathy towards proper tail calls in V8 leads me to distrust Google’s language proposals. But now that abdication appears to possibly have been a canary? Perhaps even prior to the pandemic they couldn’t keep up with maintaining the V8 C++ codebase, and that’s why PTCs got skipped?

By the way, what happened to Golang and Dart?

kmeisthax 10/26/2024||

Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? i.e. if implementing them directly as new language features doesn't make sense, then preprocess them away before executing the scripts. You could even do this for past features that made it into ECMAScript but haven't turned out to be useful, instead of ossifying a specific moment in time's tooling.

gary_0 10/26/2024||

> Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself?

I think if it was that simple, it would be done that way already (maybe it is, for some features). Two big arguments for doing the "desugaring" offline are the (1) speed, and (2) security of the browser. Those two things also conflict somewhat if addressed on the client, since faster but more complex compiler code increases the surface area for potential exploits.

But if you do this compile step offline, you don't need to worry about compromising the performance or security of the browser.

3np 10/26/2024|||

Why wouldn't you take the complexity and performance hit involved once at buildtime rather than offloading it to the client at runtime?

If you read the original slides from the proposers, they're presenting a framing where there is an inherent tension between "serving the user" and "helping the developer". They argue that there is too much of the latter, and that a formalized splitting should push more to the former.

From an end-user perspective, it definitely makes more sense that the js doesn't have to be transformed locally before it can interpreted. I think your suggestion is not compatible with the motivations of the proposal.

wrs 10/26/2024|||

If there’s still going to be a standard JSSugar, yes, seems like it should be desugared in the runtime. On the other hand, if we want to make it easier to fragment the high-level language into incompatible sugared versions, this seems like the way to go. (Hard to believe that would be the TC’s goal.)

sshine 10/26/2024|||

> features to be implemented as a desugaring step in the runtime itself

The problem is distributing the runtime(s). By having developers transpile to a small core, anyone can freely invent new language features without waiting for the rest of the internet to download support for them.

ec109685 10/26/2024|||

If it’s not implemented as a built-in feature of the browser, wouldn’t half the internet break if features were removed that people were counting on?

singularity2001 10/26/2024||

This is a very good at important point:

JS0 should be a subset of current JS

JS1 should be current JS

JsSugar should be current JS plus future features

Aldipower 10/26/2024||

No word about Actionscript 3 (ECMAScript 4) here? It compiled to the ActionScript Virtual Machine 2 as bytecode. Everybody was happy. And then, Steve Jobs came around the corner and damned it with a single magical curse. Too bad.

hoppp 10/26/2024||

I use bigint all the time. Not adopted? Its not true.

senfiaj 10/27/2024|

Yep. Even if it is used on the 1% of websites it's still a usage. Sure, I don't expect it to be used as commonly as a regular number.

mintplant 10/26/2024||

Hell yes. I've been advocating for this for years. From an engine-implementer perspective, full-fledged JavaScript is just too hard to make both fast and secure.

no_wizard 10/26/2024||

One of the examples given makes sense, since Symbol.specie messes with prototypical inheritance and is likely hard to secure as a result because that touches so much of JS as a whole.

BigInt failing to materialize I think has more to do with ergonomics around it, they’re a bit unwieldy and there aren’t able to be used with the built in Math object functions.

They also have zero JSON support out of the box which is a huge miss.

Honestly it should have been roadmapped to replace the built in Number type

ossobuco 10/26/2024|

Can't replace Number with BigInt as BigInt is orders of magnitude slower on certain operations. Try to do bitwise operations with BigInt, you'll see what I mean.

no_wizard 10/26/2024|||

Hence roadmapped. You can’t today, certainly, it also can’t represent floating point numbers or be used with the Math object as noted.

But the idea is that it should have been proposed with a roadmap of what it would look like to have it eventually supplant Number

senfiaj 10/27/2024|||

bigint cannot be replaced by regular number when working with arbitrarily large whole numbers. With regular numbers you will lose precision out of the range [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER]. If you try to implement such functionality via JS, it would be even much slower than the bigint native implementation. So, it's great to have such thing natively implemented.

dimal 10/26/2024||

I think I understand the argument but this sounds like it would make things worse. The argument that new features almost always make the language worse doesn’t hold true from my perspective as a developer. (I could imagine the perspective of a language implementor being very different.)

I like that JavaScript now has modules/imports, destructuring, Proxies, async/await, etc. These were all new features at one point, But yeah, why did Symbol.species get in? Seems like it’s to enable some odd subclassing pattern? I’m an anti-OOP zealot, so my hot take would be that maybe OOP subclassing is unnecessarily complex already, so stuff like that shouldn’t make it in. We got the OOP syntactic sugar, which is enough. Stop there.

How much of the extra complexity is from stuff like that that is rarely used? Maybe we just need to be a lot more conservative about what makes it in, but stopping changes and forcing everything into more tooling complexity is not the direction I’d like to go in. We need to reduce tooling, not increase it.

voidr 10/27/2024|

If we take this logic, we should get rid of JavaScript support entirely and only support WASM, which would be a direction, but it would ignore how developers are using the platform.

It is now becoming rare when I see any serious project that still uses JavaScript, everyone I know is using TypeScript and I don't recall any job posts not requiring TypeScript. What are the standards bodies doing? They are still implementing hacks upon JavaScript instead of seeing the writing on the wall.

Maintaining JS engines is difficult because of the old stuff that few developers actually use, it would make a lot more sense to start deprecating those features and adding the new ones developers actually want.

I started using alternatives to NodeJS because I don't feel like I should subject myself to a compilation step if I don't have to.

More comments...