Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should JavaScript be split into two languages?

devclass.com

Post reply on HN
Print view View original

51–60 of 324 posts

Re: Should JavaScript be split into two languages?

#51

Post by nephy »

righthand wrote: post #13

All this championing Javascript as a single language for front and back end work, now to be split for different use cases. Hopefully this is how Javascript dies if that is the route Google pushes it. There is already too much exhaustion around switching frameworks and paradigms in the JS world, but I guess everyone likes getting jerked around by corpos and evangelists these days.

I’m really tired of this discourse. The JavaScript ecosystem is the lingua franca of the web. Furthermore, while a segment of the programming community has sat around complaining, JavaScript has gotten really good and continues to improve every passing year. Incremental progress is the key to making progress, not giant paradigm shifts.

Re: Should JavaScript be split into two languages?

#52

Post by Kwpolska »

> Regarding BigInt, the presentation states that “use cases never materialized.”

Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend).

Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one, e.g. in the browser console. Develop the language instead of tons of incompatible tools.

Re: Should JavaScript be split into two languages?

#53

Post by nephy »

Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

I literally use BigInt on the backend every single day at work lol.

Re: Should JavaScript be split into two languages?

#54

Post by peutetre »

rafaelmn wrote: post #27
peutetre wrote: post #4

Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.

Did they solve GC and DOM access ? It's been years since it was "just about to happen" and I stopped paying attention in the meantime. But if it had that I agree - it would be ideal if JS was a legacy thing and a saner WASM first class language got to replace it. Keep the single threaded event loop approach but kill the JS semantics.

Garbage collection is solved to the extent that host garbage collection is now available via WasmGC:

https://developer.chrome.com/blog/wasmgc/

https://v8.dev/blog/wasm-gc-porting

But languages like C# want more features in WasmGC:

https://github.com/dotnet/runtime/issues/94420

No direct DOM access yet. You still have to use JavaScript glue code to get at the DOM.

Re: Should JavaScript be split into two languages?

#55

Post by ninetyninenine »

ttoinou wrote: post #37
ninetyninenine wrote: post #9

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.

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.

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

Re: Should JavaScript be split into two languages?

#56

Post by 3np »

Kwpolska wrote: post #52

> Regarding BigInt, the presentation states that “use cases never materialized.” Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend). Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one…

This stood out to me as well. Proper decimal type would be my #1 missing language feature, seconded by a standardized runtime implementation of the same.

Re: Should JavaScript be split into two languages?

#57

Post by ossobuco »

no_wizard wrote: post #41

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…

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.

Re: Should JavaScript be split into two languages?

#58

Post by RandomThoughts3 »

peutetre wrote: post #4

Better to focus on WebAssembly instead. Bring every language to the web. JavaScript for some scripting, any other language for bigger applications.

Then you add capability to hide the browser chrome and build close to native user experience and we will have truly looped the loop. Think about that: the browser as an intermediation ensuring resources are properly shared and each application is shielded from the others. Everything that’s old is new again. /s

On a serious note I don’t see the point in turning browsers into an OS on top of the OS. I know it’s some kind of Google wet dream so they can suck up even more data than they already do but still. If you want to ship applications, just do that. The sandboxing should be done at the OS level where it belongs.

Re: Should JavaScript be split into two languages?

#59

Post by 3np »

kmeisthax wrote: post #18

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.

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.

Re: Should JavaScript be split into two languages?

#60

Post by nephy »

zb3 wrote: post #50
nephy wrote: post #49

Earlier quoted context omitted.

WASM is slower than running JavaScript on V8 in almost all scenarios and will likely continue to be for a very long time. Also, many of us don’t want a compile step.

While I don't want any compile step either (js should stay), I'm actually confused by your statement.. are there any benchmarks? Are you saying that for example v86 would run faster without wasm?

I think that would probably fall outside the norm. My information might be outdated, but I was under the impression that JavaScript usually wins in most algorithm benchmarks because the JIT is so good.
Post reply on HN