5 ms·

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 t

by prmph 3y ago

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

ajross 3y ago
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.
- dudus 3y ago
  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.
brundolf 3y ago
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
Matheus28 3y ago
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.
- pjot 3y ago
  What are you writing the games in?
  - Matheus28 3y ago
    C++ with a little bit of JS glue to interact with web APIs, https://florr.io https://florr.io
    - beebeepka 3y ago
      Wouldn't code written in JS be just as fast after being turned into wasm?
      - flohofwoe 3y ago
        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/ 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").
        hutzlibu 3y ago
        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.
jchw 3y ago
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.
- prmph 3y ago
  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.
paulddraper 3y ago
WebAssembly is solving a completing different problem than better webpage UI.
flohofwoe 3y ago
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.vscode-kcide https://marketplace.visualstudio.com/items?itemName=floooh.v...). Stuff like this wasn't really possible until asm.js and then WebAssembly.
- kllrnohj 3y ago
  > 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.
  - Dylan16807 3y ago
    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.
    - kllrnohj 3y ago
      > 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?
gnulinux 3y ago
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.

by prmph 3y ago

ajross 3y ago

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.

dudus 3y ago
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.

brundolf 3y ago

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

Matheus28 3y ago

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.

pjot 3y ago
What are you writing the games in?
- Matheus28 3y ago
  C++ with a little bit of JS glue to interact with web APIs, https://florr.io https://florr.io
  - beebeepka 3y ago
    Wouldn't code written in JS be just as fast after being turned into wasm?
    - flohofwoe 3y ago
      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/ 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").
      - hutzlibu 3y ago
        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.

jchw 3y ago

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.

prmph 3y ago
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.

paulddraper 3y ago

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

flohofwoe 3y ago

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.vscode-kcide https://marketplace.visualstudio.com/items?itemName=floooh.v...). Stuff like this wasn't really possible until asm.js and then WebAssembly.

kllrnohj 3y ago
> 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.
- Dylan16807 3y ago
  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.
  - kllrnohj 3y ago
    > 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?

gnulinux 3y ago

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.