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

121–130 of 324 posts

Re: Should JavaScript be split into two languages?

#121

Post by wiseowise »

jefftk wrote: post #33
habosa wrote: post #30

If this happened then JavaScript would be split into 20+ languages, one for each popular compiler. There would be nothing stopping a tool maker from adding their favorite language features even if no other compiler ever adopted them. That would be a disaster.

Outside of browsers this is already how it works. Nothing is stopping LLVM versus GCC from adding their favorite language features, but it's not a disaster.

> Nothing is stopping LLVM versus GCC from adding their favorite language features, but it's not a disaster.

It is a disaster the moment you try to run same code on different platforms.

Re: Should JavaScript be split into two languages?

#122

Post by davexunit »

singularity2001 wrote: post #98
xscott wrote: post #88

Earlier quoted context omitted.

You're two library functions away from having it easy: Copy from JavaScript to WebAssembly: Use TextEncoder to convert a JS String to Uint8Array Copy the bytes from the Uint8Array to WemAssembly.Memory Copy from WebAssembly to JavaScript: Copy the bytes from WebAssembly.Memory into a Uint8Array Use TextDecoder to convert from Uint8Array to JS String JS Strings are pretty much always going to be "rope data structures"…

From the new official WASM proposal: https://github.com/WebAssembly/js-string-builtins/blob/main/... "the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call" I guess the more elegant and universal stringref proposal is DEAD now !? https://gi…

Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-strin...

    We don’t yet have consensus on this proposal in the Wasm standardization group, and we may never reach there, although I think it’s still possible. As I understand them, the objections are two-fold:
 
    WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8).
 
    The requirement to support fast WTF-16 code unit access will mean that we are effectively standardizing JavaScript strings.
I really like stringref and hope the detractors can be convinced of its usefulness. Dealing with strings is not fun right now.

Re: Should JavaScript be split into two languages?

#123

Post by wiseowise »

jas39 wrote: post #11

It's a good idea, but a better idea would be to make the browser a virtual machine running wasm. HTML, SVG and everything else could be implemented in wasm, and loaded from the cloud as needed.

> It's a good idea, but a better idea would be to make the browser a virtual machine running wasm. HTML, SVG and everything else could be implemented in wasm, and loaded from the cloud as needed.

So now a huge swaths of use cases are going to be killed by this change. E.g. AdBlock, NewPipe and yt-dlp - how is that better? All of them (expect maybe AdBlock) rely on parsing incoming JS from YouTube which will be rendered obsolete by WebAssembly blob.

Re: Should JavaScript be split into two languages?

#124

Post by kaba0 »

Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

Java is as open-source as it gets (it’s reference implementation, OpenJDK, has the same license as the linux kernel)

And it was used by some browsers, there was just no consensus between different vendors due to politics. The problem largely solved itself by.. only one vendor remaining, chromium.

Re: Should JavaScript be split into two languages?

#125

Post by simonw »

Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

My guess is that none of those bytecode VMs were designed with the explicit goal of running untrusted code at global scale in a rock-solid sandbox.

If anything, I expect those existing VMs to slowly be replaced by WebAssembly due to how crucial and complicated that very specific sandbox requirement is - and how useful that is once you have it working reliably.

Personally I never want to run untrusted code on any of my computers outside of a robust sandbox. I look forward to a future where every application I might install runs in a sandbox that I can trust.

Re: Should JavaScript be split into two languages?

#126

Post by davexunit »

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.

Wasm GC is shipped in stable releases of all major browsers except for Safari but that will be changing shortly if it hasn't already (my info is a few weeks old.) The important thing to note about Wasm is that all important functionality, such as access to I/O and the DOM, have to arrive in the form of host imports to a Wasm module. With this in mind, thanks to Wasm GC it is possible to do web UIs from Wasm by importing the relevant bits of the DOM API that the module needs. Projects like Hoot (Scheme) and Kotlin port are already demoing such things.

Re: Should JavaScript be split into two languages?

#127

Post by neonsunset »

Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

NIH and CIL is probably an ultra-overkill for browser-based scenarios. It implements a complex type system with all sorts of high-level features that significantly complicate the runtime/compiler. It makes it drastically easier to target but not to write an implementation.

I'm not a huge fan of WASM but it's easy to see that the authors would clearly not want to leave control in the hands of Microsoft or Oracle (and as a result all of us are hostages to Google instead because of evil that is Chromium).

https://ecma-international.org/publications-and-standards/st...

Re: Should JavaScript be split into two languages?

#128

Post by xscott »

the-smug-one wrote: post #109
em-bee wrote: post #79

Earlier quoted context omitted.

one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast. in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.

That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower

Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats.

This is where you say something about "exact" vs "inexact" as though that will hand wave it away.

Re: Should JavaScript be split into two languages?

#129

Post by dboreham »

Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

They were. Lots of reasons why it turned out how it turned out. Basically a local minimum in the gradient descent. Computers were much slower is one reason. JVM wasn't open source at the time is another. NIH is another 100 reasons.

Re: Should JavaScript be split into two languages?

#130

Post by koito17 »

Timwi wrote: post #116

I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't underst…

What disqualifies "the JVM" (usually referring to HotSpot implementations) from being considered open source? Are you talking about OpenJ9 or something else?
Post reply on HN