Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

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.

With an interpreted language like JavaScript, the dividing line is a little grayer, because the shippable code isn't bytecode, it's still just text. But it still seems to make sense to me to target a a "core", directly interpretable language, and then let all the syntactic sugar be precompiled down to that (especially since most JS devs have a compilation step now anyway). Heck, we basically already did this with asm.js, the precursor to WebAssembly.

View on HN

It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.

What's old is new again :)

asm.js came about because it was a very optimizable subset of JavaScript, then it was superseded by WebAssembly, then the proposal in TFA is basically asking for asm.js back, but perhaps the better answer is to make WebAssembly fully support all of what JS could originally do.

This is perhaps why as I get older I sometimes feel like I want to get out of software development and become a goose farmer like that dude on LinkedIn - lots of times feels more like spiraling in circles than actually advancing.

I think it’s much harder to make big leaps as a community with languages and other - relative to the technology stack as a whole - lower level concerns.

Look at the stronghold grip of C/C++ and how long it’s taken Rust to gain a meaningful foothold in those realms for example.

Google wanted to flat replace JS once already, that was the entire origin of Dart. They only pivoted to the cross platform mobile framework as its primary target after it failed to gain traction as a standard

Actually in regards to Dart it is a more subtle.

Dartium was cancelled and AdWords team, having just migrated from GWT to AngularDart, saved the Dart team.

Eventually many left the team.

Somewhere at Google, Flutter started and when they decided to replace JavaScript on their original design, they decided to reach out to the Dart team.

So Dart got a new purpose in life, being Flutter's language.

In this process it was rebooted from dynamic language, into a static type one, having JIT and AOT toolchains.

How long Flutter, and by association Dart, remain relevant remains to be seen.

Dart is a better designed language in many regards.

It’s not just better than JavaScript, I would argue it’s probably the best general purpose modern OOP based language out there right now.

It was actually really fortunate in that for a long time it didn’t have a big community behind it and they just put a lot of very smart language designers on the team where they had ten years to try various approaches and learn from the mistakes of not only themselves but others without a lot of outside noise.

But there’s no other language I would prefer to write applications in. It’s just a really nice mix of ergonomic, expressive and powerful.

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.

>"let's shove the JVM into every browser and make it a mandatory part of web"

Javagator / Jazilla!

https://www.cnet.com/tech/tech-industry/javagator-down-not-o...

I’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?

They wanted to implement a typing system first so they could transfer complex types with a strict contract first, as large parts of DOM management would benefit enormously from that, and it would be far better to design an API around. This system has been stuck in different iterations for years.

The current active proposal for it is the Component Model: https://component-model.bytecodealliance.org/design/why-comp....

Because it's already solved from day one and people keep repeating that it's a problem anyways.

Anything you can do in JavaScript, including access to the DOM, can be put into a JavaScript function. You can import that function into a WebAssembly Module, and you can use WebAssembly Memory to transfer large or complicated data as an efficient side channel. It all works.

Could you link an ergonomic example? I have cemented in my memory that DOM access in WebAssembly is not trivial and I suspect others too.

This is what StackOverflow tells me (2020):

> Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access. The closest manipulation you'll get from WASM is to manipulate state objects that are passed to and rendered by the main thread with state-based UI components like Preact/React.

> JSON serialization is most often used to pass state with postMessage() or Broadcast Channels. Bitpacking or binary objects could be used with Transferrable ArrayBuffers for more performant messages that avoid the JSON serialization/deserialization overhead.

This feels like "we can have DOM access at home" meme.

> This is what StackOverflow tells me (2020)

Web Workers can't directly access the DOM in JavaScript either. This is not a WebAssembly problem. If you want a Web Worker to manipulate your document, you're going to post events back and forth to the main thread, and Web Assembly could call imported functions to do that too.

I don't even know what he's on about with Preact/React...

Save the following as "ergonomic.html" and you'll see that WebAssembly is manipulating the DOM.

    <!doctype html><title>Not that hard</title> 
    <script type="module"> 
     
    document.addEventListener('DOMContentLoaded', () => { 
        /* Compile this module with wat2wasm to make the binary below: 
     
            (module 
                (import "env" "easy" (func $easy (param i32))) 
                (func $run (param) (result) 
                    (call $easy (i32.const 123)) 
                    (call $easy (i32.const 456)) 
                ) 
                (memory $mem 1) 
                (export "run" (func $run)) 
                (export "mem" (memory $mem))  
            ) 
        */ 
     
        const binary = new Uint8Array([ 
              0,   97,  115,  109,    1,    0,    0,    0,   
              1,    8,    2,   96,    1,  127,    0,   96, 
              0,    0,    2,   12,    1,    3,  101,  110,  
            118,    4,  101,   97,  115,  121,    0,    0,  
              3,    2,    1,    1,    5,    3,    1,    0, 
              1,    7,   13,    2,    3,  114,  117,  110, 
              0,    1,    3,  109,  101,  109,    2,    0, 
             10,   14,    1,   12,    0,   65,  251,    0,  
             16,    0,   65,  200,    3,   16,    0,   11,   
        ]); 
     
        const imports = { 
            easy(arg) { 
                const div = document.createElement("div"); 
                div.textContent = "DOM this: " + String(arg); 
                document.body.appendChild(div); 
            } 
        }; 
     
        const module = new WebAssembly.Module(binary);  
        const instance = new WebAssembly.Instance(module, { env: imports });  
        instance.exports.run(); 
    });
    
    </script>

That `easy(arg)` function could do much more elaborate things, and you could pass lots of data in and out using the memory export.

I'd like to believe a simple standalone example like this would be enough to get people to shutup about the DOM thing, but I know better. It'll be the same people who think you need to link with all of SDL in an Emscripten project in order to draw a line on a canvas.

> This feels like "we can have DOM access at home" meme.

And I'm sure somebody (maybe you) will try to move the goal posts and claim some other meme applies.

> I don't even know what he's on about with Preact/React...

Around 10 years ago, I was having lunch in a food court and overheard "Luckily I don't have to use javascript, just jquery".

Around 5 years ago, a co-worker admitted he still had issues distinguishing what functionality was python and what came from Django (web framework), despite having used them both daily for years. He thought it was because he learned both at the same time.

I wouldn't be surprised if this was more of the same, and just getting worse as we pile more and more abstractions on top.

(your example becomes a lot easier to read on a computer instead of a phone) but i'd also like to thank you for patiently answering all the questions (esp here: https://news.ycombinator.com/item?id=41961489 and https://news.ycombinator.com/item?id=41964500 (unfortunately the latter comment has been flagged. turn on showdead to read it)).

but what bothers me a bit is that this example still uses custom javascript code.

i tried to find and answer but essentially what appears to be missing is the ability to access js objects from wasm. to access the document object it looks like i need a wrapper function in js:

    jsdocument(prop, arg){
        document[prop](arg)
    }

so far so good, i can import this jsdocument() function and use it to all any property on the document object, but if document[fun](arg) returns another DOM object, then what?

maybe more elaborate:

    callDOMobj(prop, arg, prop2, arg2){
        document[prop](arg)[prop2](arg2)
    }

i can call this function with the arguments ("getElementById", "foo", "append", "<div>more foo</div>") in any WASM language and it will result in calling document.getElementById("foo").append("<div>more foo</div>"); which allows some basic DOM manipulation already. but then i want to continue with that object so maybe i can do this:

    getDOMobj(prop, arg){
        var len = objlist.push(document[prop](arg))
        return len-1;   
    }

    callDOMobj(pos, prop, arg){
        objlist[pos]["prop"](arg)
    }

can you see what i am getting at here? building up some kind of API that allows me to access and manipulate any DOM object via a set of functions that i can import into WASM to work around the fact that i can't access document and other objects directly. it looks like this is similar to this answer here: https://stackoverflow.com/a/53958939

solving this problem is what i mean when i ask for direct access to the DOM. i believe such an interface should be written only once so that everyone can use it without having to reinvent it like it appears to be necessary at the moment.

> i'd also like to thank you for patiently answering all the questions

It's nice of you to say so. Thank you.

> can you see what i am getting at here?

I mostly can, but I'm not sure we're clear what we're talking about yet.

I see a lot of people who repeat something about "WebAssembly isn't usable because it can't manipulate the DOM". Ok, so I show an example of WebAssembly manipulating the DOM. That should put that to rest, right? If not, I'm curious what they meant.

> building up some kind of API that allows me to access and manipulate any DOM object via a set of functions that i can import into WASM to work around the fact that i can't access document and other objects directly,

This is a shortcoming in the language implementation, or the library for the language. The machinery is already there at the WebAssembly level. If your language is low level (Rust, C, or C++), and doesn't have what you want, you could roll your own. If your language is high level (Python or Lua), you're at the mercy of the person who built your version of Python.

The core of WebAssembly is a lot like a CPU. It's analogous to AMD64 or AArch64. It'd be weird to say you need changes to your CPU just to use a function called `getElementByName()` or `setAttribute()`. Some WebAssembly extensions have added features to make that "CPU" more like a Java style virtual machine. There are (or will be) garbage collected references to strings, arrays, and structs. This might make it better for implementing Go and Java style languages, and it could help with a fresh implementation of Python or Pike too. And maybe some of those changes will give controlled access to JavaScript style objects.

There's a last discussion to be had about performance. Maybe the bridge between WebAssembly imports and exports is too slow for intensive use. That's a debate that should be backed up with benchmarks of creative solutions. Maybe accessing JavaScript strings is so common, so important, and so slow that it really does require an enhancement to the standard.

i am talking about a js library of generic functions that can be imported from wasm to make DOM access easier. handling of string arguments still needs to be solved (i am guessing the shared memory access is the right place for that) and the respective functions on the wasm side need to be implemented for each target language so that DOM access in the target language becomes natural and easy to use.

If you picked a language that gave you low level control, and if you had strong opinions about what you wanted, you could probably write that JS library in a weekend or two. Strings and arrays through shared memory. Maybe use a JS Map of integers to act as handles mapping to JS Objects.

Is this sarcasm I might be missing?

Thanks for confirming that WebAssembly still cannot manipulate DOM in 2024.

It can only call custom javascript functions that manipulate DOM AND I need to write some arcane function signature language for every DOM manipulating function I want to call.

I'll give another 4 years and see if they fixed this.

> I need to write some arcane function signature language for every DOM manipulating function

You really don't know that you can create WebAssembly in other languages?!? I used WAT to keep the example short, but that's clearly lost on you.

> I'll give another 4 years and see if they fixed this.

In that time, there are lot of things you could be learning. Embracing ignorance and belligerence isn't like to serve you well in the long term.

They’re already moving it that way, it’s not like it isn’t without complexities and such either. WASM isn’t the silver bullet everyone seems to cling to.

I feel like the WASM fervor has more to do with the fact people don’t enjoy using Frontend tools or JavaScript etc. vs looking at the actual utility tradeoffs

   >>  WASM isn’t the silver bullet everyone seems to cling to.

And it isn’t the silver bullet exactly for the reason that it's horribly complicated to access normal JS objects including strings.

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". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.

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://github.com/WebAssembly/stringref/blob/main/proposals...

I don't really mind, as it keeps the wasm bytecode cleaner.

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.

> Dealing with strings is not fun right now.

And dealing with strings isn't fun in many other languages or runtimes or OSes.

e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan<byte> objects" - https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

e.g.2. Erlang/BEAM/Elixir: "The Erlang string type is implemented as a single-linked-list of unicode code points. That is, if we write “Hello” in the language, this is represented as [$H, $e, $l, $l, $o]". The overhead of this representation is massive. Each Cons-cell use 8 bytes for the code point and 8 bytes for the pointer to the next value. This means that the 5-byte ASCII-representation of “Hello” is 5*16 = 80 bytes in the Erlang representation." - https://medium.com/@jlouis666/erlang-string-handling-7588daa...

> The Erlang string type is implemented as a single-linked-list

This refers just to Erlang's string() type, not BEAM strings in general; it's just a bad default. If you're not using binaries, you're doing it wrong, and that's exactly why Elixir's strings are UTF-8 binaries.

Okay? Is this an argument in favor of doing nothing?

Thank you for the links. To the extent I understood it from a quick reading, it all looks like stuff you could get with the existing import/export mechanisms. I would choose (modified) UTF-8, but I understand why UCS16 is always going to be around.

I agree about keeping wasm bytecode cleaner. The core plus simd stuff is such a great generalization of the ARM and X86 CPUs we mostly use. The idea of gunking it all up with DOM related stuff is distasteful.

"trampoline business"?

It supports nearly arbitrary imports of anything you want. How much more flexibility do you need? You could provide an `eval` function to run arbitrary code with a small amount of effort.

Is the problem that Emscripten and/or Rust haven't laid it all out on a platter?

no, people need to be able to program the browser without needing “tooling”

> 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, etc.

- browsers include a disassmbler/decompiler to improve debugging the bytecode

Then simple sites, and development can use plain JS source, but for higher performance you can just deploy the pre-compiled bytecode.

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.

You are getting your history reversed.

Java is a product of the JVM, which was the innovation, not the reverse. A successful language moving post-success to a new byte code format would be as far as I know unprecedented.

The idea that JavaScript is an interpreted language is also fairly shaky. It’s JIT compiled as soon as it arrives to your browser. Honestly, a modern JS engine is not different from any other VM.

The question as you rightfully pointed really is what do you send to the browser and under it lies the fundamental question of what is a browser actually. Is it a way to browse hypertext content or a standardised execution environment?

The problem is within that gray area. For enjoyers of vanilla js, like myself, I'd hate it if "core" js got so small that I now started to require a compiler for my ES6 code. If I was in charge I'd say "fine, but the core must be at least as large as ES6" and I'd reserve the right to tweak browser native modules in minor ways (for example, it would be nice to support a SPA syntax where you could export/import modules from within the same page without either a) hacking the global object or b) generating unnecessary resources).

The vanilla js APIs are so atrocious that we got jquery.

I think you missed a tense. Was atrocious, we got jquery, which got folded back into javascript. If the last time you worked with vanilla js was when jquery was hot, you're views are outdated.

Sibling and parent/child traversal is still a disaster and querySelector, querySelectorAll doesn't solve it.

The BEAM VM (Erlang, Elixir) does this with what’s called "Core Erlang", used as lower-level targets before compiling to the BEAM primitives.

https://blog.stenmans.org/theBeamBook/#_compiler_pass_core_e...

Java doesn't run in browsers so the comparison doesn't make sense.

Splitting the language might make sense from an engineering perspective but what about all the extra energy and bandwidth that will be needed?

Reply on news.ycombinator.com