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

131–140 of 324 posts

Re: Should JavaScript be split into two languages?

#131

Post by davexunit »

em-bee wrote: post #75
xscott wrote: post #69

Earlier quoted context omitted.

What parts are not available? WebAssembly can call arbitrary JavaScript through imports. You could literally provide an `eval` function if you were motivated to.

direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical

All imports have to come from the host, which in the case of the web means they have to be expressed as JavaScript. Behind the scenes they could be optimized, though, and I've heard that JS/Wasm engines maybe already be doing this with well-known imports (think Math.sin).

Re: Should JavaScript be split into two languages?

#132

Post by davexunit »

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…

Yeah it was really concerning to hear someone from Google saying that BigInt doesn't have a use case. It is both used and important!

Re: Should JavaScript be split into two languages?

#134

Post by davexunit »

peutetre wrote: post #24
bitwize wrote: post #15

JavaScript so wants to be Scheme. Can we just do Eich's original thing and put Scheme in the browser?

WebAssembly enables that: https://www.spritely.institute/hoot/

Heh thanks for dropping the link! The dream of the 90s is alive thanks to Wasm GC.

Re: Should JavaScript be split into two languages?

#136

Post by koito17 »

simonw wrote: post #125
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 m…

"Secure Java" is something I recall hearing decades ago. No idea if it still exists.

The more important thing to consider, however, is the fact that CLR, JVM, etc. provide internal memory safety whereas Wasm runtimes don't.

e.g. a C program that goes sufficiently out of bounds on an array is guaranteed to segfault in the C runtime, but that runtime error does not necessarily occur on a wasm target. That is to say, the program in the sandbox can have totally strange runtime behavior -- still, defined behavior according to wasm -- although the program has undefined behavior in the source language. In the case of JVM languages, this can't really happen.

Re: Should JavaScript be split into two languages?

#137

Post by alpaca128 »

thayne wrote: post #107
hn_throwaway_99 wrote: post #17

I'd argue that other languages did this (or something similar) to great success, most notably Java. That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes. W…

> because the shippable code isn't bytecode, But what if it was? What I would like to see is: - a bytecode "language" that roughly corresponds to Javascript semantics, and that is what the engines interpret (and JIT compile) - browsers still include a compiler to compile JS sourcecode to the bytecode. Possibly wasm could work, although it would need a lot more functionality, like native support for GC, and DOM access…

I am certain this would mainly add problems while not improving performance as websites would just add more stuff on top until it's again on a barely tolerable level, for both the user and the developer who know probably has to manage yet another super simple, blazingly fast tool to keep everything running.

Re: Should JavaScript be split into two languages?

#138

Post by anon7000 »

sshine wrote: post #6

JavaScript is two languages: 1) JavaScript, the original assembly language of the internet, does not need new language features. 2) JavaScript, the front-end web development language is a fractal of infinitely many sub-languages that transpile back to ES5. The proposal, as I read it, is: Let's stop adding front-end web features to the assembly language; it doesn't get easier, better or faster if we change the underly…

This isn’t really true on a practical level any more. ES6 support is very widespread (97% of all web users according to caniuse.) That even includes module import syntax!

There are still some new language features that need to be transpiled, but most projects do not need to worry about transpiling cost/let/arrow functions/etc.

I mean even newer features like nullish coalescing and optional chaining are at 93-94% support.

At the end of the day, I would say tools like babel for transpiling are less and less important. Yes, you still use a bundler because the web has a lot of runtime constraints other native applications don’t have (gotta ship a tiny bundle so the page loads fast), but it’s better for the language features to be implemented in the VM and not just faked with more JS.

Re: Should JavaScript be split into two languages?

#139

Post by pjmlp »

adjav wrote: post #105
pjmlp wrote: post #40

Earlier quoted context omitted.

asm.js came about because Mozzilla refused to adopt PNaCL, which is kind of ironic given the existing Firefox market share a decade later.

PNaCL was essentially "let's shove LLVM into every browser and make it a mandatory part of the web", which somehow seems even worse than "let's shove the JVM into every browser and make it a mandatory part of web"

Given Google's power a decade later, with Safari left as the only non-Chrome clone with market relevance, it hardly makes a difference.

Additionally we already have LLVM all over the place, alongside JVM and CLR, it is the most deployed compiler infrastructure with contributions at the same level as the Linux kernel.

Re: Should JavaScript be split into two languages?

#140

Post by kaba0 »

peutetre wrote: post #81
em-bee wrote: post #75

Earlier quoted context omitted.

direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical

Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo

So throwing out literally 99% of what makes the web actually portable and useful?

A random drawn rectangle is not a UI, it’s not accessible, not inspectable, not part of the de facto OS native toolkit.

If all we wanted is a random cross-platform canvas element to draw onto from a vm, it could be solved in a weekend. There are million examples of that.

Post reply on HN