[flagged]
Making WebAssembly a first-class language on the Web
231–240 of 287 posts
Re: Making WebAssembly a first-class language on the Web
#232This was supposed to happen already in the 2000s. JVM in everywhere, especially in the browser. There was Java rings you could wear, Java Card VM (JCVM), Squawk VM, Java ME. "Java the language is almost irrelevant. It's the design of the Java Virtual Machine. And I've seen compilers for ML, compilers for Scheme, compilers for Ada, and they all work. Not many people use them, but it doesn't matter: they all work." --J…
JVM bytecode didn't have support for C and required GC. Even in the early days it was a lot heavier than Wasm.
JCVM did not require GC. It was designed to run on extremely resource-constrained devices-think 16-bit or 32-bit microcontrollers with only a few kilobytes of RAM.
Java Card 2.2 and 3.x specifications added optional GC.
Re: Making WebAssembly a first-class language on the Web
#233Earlier quoted context omitted.
I have to wonder if Apple will allow any of this to move forward in the W3C standards committee since they've been blocking many things that would make web browsers as capable as native apps. Apple perceives web-based applications as chipping away at their app store (which makes them money), and so they cripple their Safari browser and then force all mobile browsers on iOS to use their browser engine, no exceptions,…
This is a nice conspiracy theory but doesn't match facts like Safari implementing the WebGPU standard at a faster pace than Firefox. Safari might not be great in some areas, but their WASM/WebGPU/WebAudio support is in pretty good shape.
Push Notifications, Web Bluetooth, Web NFC, User Idle Detection, the list goes on and on. Not even counting the hundreds of #wontfix bugs in their css engine. Its not a conspiracy theory if you recognize their incentives and consistent anti-consumer behavior for fucking decades.
Re: Making WebAssembly a first-class language on the Web
#234Earlier quoted context omitted.
Oh interesting. In java land the fact that you effectively don't have pointers but rather everything is an object reference, this ends up not being an issue. I wonder if the WASM limitation is related to the fact that JavaScript has pretty similar semantics with no real concept of a "pointer". It means to get that interior pointer, you'd need to also introduce that concept into the GC of browsers which might be a bit…
Object references are pointers. WasmGC only supports pointers which point to the start of an object. However, some languages have features which require pointers that point inside of an object while still keeping that object alive. Limiting WASM to what is capable in JavaScript is quite a silly thing to do. But at the same time there are vastly different GC requirements between runtimes so it's a challenging issue. I…
> Object references are pointers
I know this is pedantic, but they aren't. At least not in the sense of what it means for something to be a pointer.
Object references are an identifier of an object and not a memory pointer. The runtime takes those object references and converts them into actual memory addresses. It has to do that because the position of the object in memory (potentially) changes every time a GC runs.
This does present it's own problems. Different runtimes make different choices around this. Go and python do not move objects in memory. As a result, it's a lot easier for them to support interior and regular pointers being actual pointers. But that also means they are slower to allocate, free, and they have memory fragmentation issues.
I'm not sure about C# (the only other language I saw with interior pointers). I think C# semi-recently switched over to a moving collector. In which case, I'm curious to know how they solved the interior pointer problem.
Re: Making WebAssembly a first-class language on the Web
#235This was supposed to happen already in the 2000s. JVM in everywhere, especially in the browser. There was Java rings you could wear, Java Card VM (JCVM), Squawk VM, Java ME. "Java the language is almost irrelevant. It's the design of the Java Virtual Machine. And I've seen compilers for ML, compilers for Scheme, compilers for Ada, and they all work. Not many people use them, but it doesn't matter: they all work." --J…
Java failed because of its security model - trying to run trusted and untrusted code in the same VM without a hard boundary - a given call is trusted if every call stack entry at the time of the call is in a trusted class. There were too many confused deputies - if you can set up a trusted object to make a call that requires trust later on without your involvement, then you have privilege escalation.
The solution was to sandbox the whole VM but this breaks all the existing code designed for partial sandboxing (e.g. most of the standard library). WASM uses this approach from the start.
Re: Making WebAssembly a first-class language on the Web
#236Not only are they a decade late while everyone expected WASM to liberate us from JS, and it ended up being a useless toy in JS whose improvements would have been crushed by having to send all progress to JS to apply it, but then giving it access to DOM is also something you'll realize wasn't enough a decade later. Flutter doesn't need DOM; it has all of its own engine. The browser should give the whole viewpoint to t…
And it would be 100% inaccessible.
You can't pin requirements on other people who don't have them. If someone doesn't have a requirement to make an accessible product, it's unlikely to be accessible.
Re: Making WebAssembly a first-class language on the Web
#237Earlier quoted context omitted.
That’s not entirely true. Security issues in the JIT of V8 are found every now and then. See https://v8.dev/blog/sandbox
Javascript isn't more insecure than any other language. Any language can have the same or other security issues.
Reality is a bit more nuanced that that. Some languages are easier to interpret and optimize than others, leading to less error-prone interpreter/compiler code. JS is definitely on the “harder to optimize” side of the spectrum, leading to very complex code with a higher chance of subtle errors.
V8 does some crazy stuff that makes JS one of the fastest interpreted language there is. But had JS been designed differently (Dart was an attempt at fixing some of those mistakes), it’s likely there would be less security vulnerabilities in its interpreter.
Re: Making WebAssembly a first-class language on the Web
#238Earlier quoted context omitted.
You seem to be implying that these goals were optional, but I don’t understand how #2 cross-lang interop could ever have been optional. Isn’t running non-JS languages the entire point of WebAssembly? Given that, do you really think goal #1 non-Web APIs really added much additional delay on top of the delay necessitated by goal #2 anyway?
> but I don’t understand how #2 cross-lang interop could ever have been optional This problem hasn't been solved outside the web either (at least not to the satisfaction of Rust fanboys who expect that they can tunnel their high level stdlib types directly to other languages - while conveniently ignoring that other languages have completely different semantics and very little overlap with the Rust stdlib). At the cor…
The cross-language type-mapping problem is where every interop approach eventually runs aground. The component model's challenge is the same one that hit every bridge technology before it: whose type system is "canonical"?
.NET's Common Type System was supposed to be the neutral ground for dozens of languages. In practice, it had strong C# biases — try using unsigned integers from VB or F#'s discriminated unions from C#. The CLR "primitive types" were just as much a random collection as the WIT primitives are being described here.
The practical lesson from two decades of cross-runtime integration: stop trying to tunnel high-level types. The approaches that survive in production define a minimal shared surface (essentially: scalars, byte buffers, and handles) and let each side do its own marshaling. It's less elegant but it doesn't break every time one side's stdlib evolves.
WASM's linear memory model actually gets this right at the low level — the problem is everyone wants the convenience layer on top, and that's where the type-system politics start.
Re: Making WebAssembly a first-class language on the Web
#239The WASM cliff is very real. Every time I go to use it, because of the complexity of the tool chain and process of going from zero to anything at all, I feel like I'm already paying a cognitive tax. I worry that I should update my tooling, look into the latest and greatest, understand the tooling better, etc... It would be incredible to see that improved. The difference in perf without glue is crazy. But not surprisi…
I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web developers won't need to write WIT and can just use Web API's as if they were a library. But it's early days.
What do you mean by churn in this context?
Re: Making WebAssembly a first-class language on the Web
#240Earlier quoted context omitted.
> What are examples of such applications? Honest question - I'm curious to learn more about issues such applications have in production. any application you use today that is written in JavaScript rendering to the DOM, is much harder to write in not-JavaScript Slack, Teams, Outlook, Word, OpenAI, Anthropic, Github, Twitter, Instagram (web), Notion, Google Docs, ...
Sorry, I'll ask my question in a better way: what applications written in wasm that exist today would benefit from this? Now, maybe there aren't many because of performance - maybe they haven't used wasm because it was too slow. But I would appreciate seeing data on that - an application that tried wasm and gave up after seeing the overhead, at the least. But I would also expect to see apps that use wasm even despite…
[dead]