Hacker News Reader

Comment by prmph | Hacker News Reader

This whole webassembly thing does not seems like it will solve real problems, The more I learn about it, the more it seems like another kludge built on top of the kludges we have now.

Why doesn't HTML get an overhaul, with a massive set of new and actually useful and styleable components (e.g., data table with sorting/paging/filtering capabilities built right into the browser), ability to scope CSS, and things like that? That's how the shittiness of web dev can actually be solved so that reliance of client side code can be drastically reduced

View on HN

WebAssembly is "just another ISA" for a "software CPU" that happens to work well for traditional compiled languages, it doesn't really have to do much with high level web development centered around HTML+CSS.

For instance, personally I really appreciate that I can bundle an assembler written in C89 in the mid-90's and last updated in 2008, and a home computer emulator written in C and C++ into a VSCode extension without having to worry about platform compatibility or security issues (https://marketplace.visualstudio.com/items?itemName=floooh.v...). Stuff like this wasn't really possible until asm.js and then WebAssembly.

> that happens to work well for traditional compiled languages,

It doesn't, though, which is a big problem. WASM starts the heap at 0x0 which breaks the null handling of 99% of traditional AOT languages _and also_ breaks the null handling of optimized higher level runtimes that rely on page faults to identify that a null deref happened before backtracking and converting that into an exception.

The MVP priority for WASM was to protect the host and make it simple to be the host. The guest features, security, and general sanity is very poor as a result.

Traditional AOT languages don't make promises about what happens if you try to dereference null. And they don't depend on a page fault happening.

For higher level runtimes, can you name some common ones that use page faults that way? I've never heard of that technique.

> Traditional AOT languages don't make promises about what happens if you try to dereference null. And they don't depend on a page fault happening.

The language doesn't make any promise yet on every major platform for the last 40 years a null deref resulted in a segfault because the lower address space is marked invalid.

This is absolutely, 100% baked into the practical expectations of every traditional AOT language at this point.

> For higher level runtimes, can you name some common ones that use page faults that way?

Android's ART does. I'd be shocked if OpenJDK doesn't for the same reason. Same with .NET or any other mature JIT runtime. It's obviously ridiculously expensive to insert null checks before every object access, and since the CPU & some page protections can do it for free why would you pay that?

> The language doesn't make any promise yet on every major platform for the last 40 years a null deref resulted in a segfault because the lower address space is marked invalid.

If you're using an offset that's not super reliable, and some major platforms of the past 40 years do give you memory at or near zero, and of course with a language like C the compiler is allowed to assume it won't be null and that can cause all sorts of weird program corruption even when a page fault would be safe-ish.

> It's obviously ridiculously expensive to insert null checks before every object access

This is actually the other way around. Both .NET and JVM do it the same way - they inject the smallest instruction that dereferences a pointer (e.g. cmp byte ptr [rax], al or ldr xzr, [x2]) and when it throws a hardware exception, it is then caught by the registered runtime handler, which then subsequently resumes the execution of managed code from the hardware exception location and raises corresponding Null Reference/Pointer exception there.

The only expensive part is when the exception does get raised, which costs roughly 4us in .NET and 11us in OpenJDK hotspot (Java has cheaper exceptions when you throw them out of Java, costing about 700ns at throughput, but much more expensive NPEs).

As a result, null-checks are almost always cheap, or free by being implicit (reading array length can be a null-check itself since it will be dereferencing nullptr + 0x08 or so depending on the implementation detail), and the compilers are pretty good at eliding them as well where possible.

Yes, but this doesn't work in webassembly because 0x0 is a valid address. That's my point. To do .NET & JVM in webassembly requires doing an actual null comparison and branch as you no longer get to just deref and catch the resulting segfault as there won't be a segfault. So you have to do an actual branch everywhere, which makes null checks way way more expensive.

> on every major platform for the last 40 years a null deref resulted in a segfault

Not on the Amiga ;)

Any embedded platform without MMU would have that same problem though.

Programming languages and their runtimes should not depend on such hardware features IMHO (at most use them optionally for performance optimization).

Also, my guess is that WASM engines outside the browser would absolutely be able to trap on "zero page" accesses.

AFAIK the limitation of address zero being a regular memory location when running WASM in browsers is just a side effect of the WASM heap being a regular Javascript ArrayBuffer object, which cannot start at an index greater than zero (and adding an offset for every heap access would be prohibitively expensive). A WASM runtime which doesn't require to interoperate with Javascript could map the WASM heap to regular virtual memory with the first page being read/write protected.

It doesn’t look like you know what webassembly is supposed to solve. It has nothing to do with styling. It’s about deploying native code in a safe sandboxed way. It’s not just about web pages. My use of wasm is web games that perform a lot better than anyone could achieve with JavaScript.

What are you writing the games in?

C++ with a little bit of JS glue to interact with web APIs, https://florr.io

Wouldn't code written in JS be just as fast after being turned into wasm?

You can't really turn Javascript into WASM without also compiling the whole Javascript runtime to WASM because of Javascript's highly dynamic nature.

You could use a more restrictive Typescript subset like https://www.assemblyscript.org/ though.

Also languages like C, C++ or Rust let you exactly define the layout of data on the heap, which is crucial for performance (look up data-oriented-design), and WASM preserves this in-memory layout (since it uses a simple linear heap, like C, C++, Rust, etc... but unlike Javascript, C# or Java). Achieving something similar in a high level language like Javascript would involve mapping all application data into a single ArrayBuffer "pseudo heap", and at that point, it's easier and more maintainable to do the same thing in C (or C++ or Rust).

Having said all that: modern Javascript engines can perform surprisingly well (in general I'm seeing that Javascript performance is underrated, and WASM performance is often overrated - sane Javascript, WASM and native code can all be in the same performance ballpark, but native code usually has the most "optimization potential").

Assemblyscript is unfortunately not that fast (yet?), same as javascript in most cases, also because it uses a garbage collector.

"in general I'm seeing that Javascript performance is underrated, and WASM performance is often overrated - sane Javascript, WASM and native code can all be in the same performance ballpark, but native code usually has the most "optimization potential""

And strong disagree. Javascript is indeed quite fast, but if you use a native compiled wasm libary in the right way (avoiding too many calls to wasm and back) - you will get a worlds difference in performance.

> avoiding too many calls to wasm and back

Well yeah, that because each call is basically an "optimization barrier" for the compiler (on both sides of the call), and of course the call itself also adds overhead, although that has been drastically reduced over the years.

No, because the semantics of JS aren't amenable to producing fast wasm.

I know what webassembly is. In addition to whatever else it is used for, I hear a lot about it allowing devs to avoid JS and just write browsers apps in whatever language they want to use. That there is a clamor for that is borne out of the massive pain that is the current HTML/CSS/JS based web dev.

So what I'm saying is, instead of wasting innovation effort focusing on the use of to improve the experience of writing web apps, let's use that to solve the actual problems with web dev.

"In addition to whatever else it's used for" is pulling a lot of weight there. People excited about it just for not writing JavaScript just aren't aware of what's out there. There's so many ways to avoid using JS these days. The value add of web assembly has always been portability and sandboxing. This is a big deal for software preservation.

making web apps is the least exciting thing wasm could be used for. plugin systems, embedded, serverless use cases are much more interesting off the top of my head.

i think we live in a world where we can do both: we can do wasm and we can continue making improvements to the big three webdev tools.

Honestly I don't get why so much software gets access to the entire filesystem just by running it. They should have made it so an .exe can only modify its own directory, a temp directory, and any file or directory passed to it by the user through the system's file picker or command line. That would solve 99% of the use cases.

Every time I program something that deletes files I get worried about accidentally deleting the entire filesystem by mistyping something. I shouldn't have to worry about that.

One of the reasons that webapps get as much trust as they do is simply because they don't have unrestricted file access. I wish there was an application format that promised the same on the desktop.

Webassembly doesn't solve the same problems as styleable components, scoped CSS, and things like that though. Webassembly solves the problem of "how do I deploy this software that isn't written in Javascript to the browser client?".

Sure, it also is sorta about performance, but JS interpreters are actually shockingly fast in the modern world. Mostly wasm is about moving your existing C++ code (or whatever) for your existing formats or algorithms or tools into a web/mobile client without having to hire someone to recode it all in TypeScript or whatever. That's not sexy, but it's valuable.

I think webassembly actually acts as a reliable target when building software. Every platform will have a fast web assembly runtime. So you just build for it and you can deploy for any platform mobile or desktop.

WebAssembly is like an openly designed Java virtual machine that's intended to run on all systems. You're completely confused. WebAssembly is extremely exciting and I believe it'll soon be the thing in the tech industry. With Wasm you can write one app and run it in the following platforms TODAY:

1. Desktop: Linux + Windows + OSX

2. Browsers: Chrome + Firefox

3. Phone: Android (no iOS)

4. Embedded

it's absolutely amazing. The biggest problem nowadays is packaging and various runtime things, but what I listed above 100% works, you just need to do the work to package it in N different platforms. How is this not appealing?

Imagine you write Google Sheets, it works on your browser, on OSX, on Linux, on Windows and on Android. It's the same binary.

WebAssembly is solving a completing different problem than better webpage UI.

It's about much more than web browsers at this point, in fact I think its biggest impact will end up being outside of them

I mean, just because it's not solving problems relevant to what you're working on, doesn't mean it's not solving problems. The implications of a relatively fast universal runtime that can safely sandbox untrusted code are quite far-reaching, and it will probably take a while to see the end-game. Docker and containers have been around for a fairly long time, and while the uptake of containers to solve problems has gradually increased over time, it's still nowhere near the peak. I think this is likewise true for WebAssembly, which has more potential than we currently know what to do with.

Personally I think the focus for web technologies should be deprecating old things and being very judicial about adding new things. New things that get added have to be maintained by all browser engines effectively forever, and this is part of why every browser engine is a huge multi-million dollar per year endeavor just to maintain. Meanwhile, a lot of features being added to browsers don't necessarily justify all of this cost. Layout engines are unmanageably complex already. CSS is unmanageably complex already. I think adding even more stuff is hardly the solution, but rather, we need to figure out how to actually utilize what's here better before we can actually come up with successors. Rather than adding more scoped CSS and CSS modules junk, I'd rather just have improvements to CSS-in-JS. Maybe some targeted new APIs that make it easier to implement these features in the browser, not entire new paradigms that require implementing hundreds of thousands of new lines of code that will have to be maintained indefinitely. Likewise for web components: the concept is fine, but every browser has to maintain all of this forever, and all of the edge cases that come from it; will it yield so much benefit from what exists today? Will it actually stop people from shipping megabytes of Javascript, or could they have already stopped doing that if they really wanted to, and all this will do is mop it around a bit? A large node_modules folder disappears when a web app disappears. A large Chromium source code checkout only continues to grow larger effectively forever.

WebAssembly though, gets a pass from me, because it's far more than "Web", but the Web part adds a lot to the overall package. It's just a win all around.

The unmanageable complexity is exactly the result of the current architecture of browsers. My proposal is to rip off all that cruft and actually address the pain points of web dev in a modern way.

For example, CSS is a disaster. That browsers need to be very complex to implement it correctly is the more reason why it should be replaced.

you'd break the web and that is worse overall

Reply on news.ycombinator.com