5 ms·

It's simple. JavaScript is the right abstraction for running untrusted apps in a browser. WebAssembly is the wrong abstraction for running untrusted apps in a

It's simple. JavaScript is the right abstraction for running untrusted apps in a browser. WebAssembly is the wrong abstraction for running untrusted apps in a browser. Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented. WebAssembly is statically typed and its most fundamental abstraction is linear memory. It's a poor fit for the web. Sure, modern WebAssembly has GC'd objects, but that breaks WebAssembly's main feature: the ability to have native compilers target it. I think WebAssembly is doomed to be a second-class citizen on the web indefinitely.

flohofwoe 8mo ago
That's just like your opinion man ;) (I'm not a fan of the WASM component model either, but your generalized points are mostly just wrong)
- pizlonator 8mo ago
  Then give me a counterargument instead of just saying that I'm wrong. My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.
  - flohofwoe 8mo ago
    I created and maintain a couple of WASM projects and have not experienced the problems you describe: - https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/ - https://floooh.github.io/sokol-webgpu/ https://floooh.github.io/sokol-webgpu/ - https://floooh.github.io/visualz80remix/ https://floooh.github.io/visualz80remix/ - https://floooh.github.io/doom-sokol/ https://floooh.github.io/doom-sokol/ All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web browsers is the most painless way to get this stuff to users. Dealing with minor differences of web APIs in different browsers is a rare thing and can be dealt with in WASM just the same as in JS: a simple if-else will do the job, no dynamic type system needed (apart from that, WASM doesn't have a "type system" in the first place, just like CPU instruction sets don't have one - unless you count integer and float types as type system"). Alternatively it's trivial to call out into Javascript. In Emscripten you can even mix C/C++ and Javascript in the same source file. E.g. for me, WASM is already a '1st class citizen of the web' no WASM component model needed.
    - pizlonator 8mo ago
      The fact that you made some webassembly things isn't an answer to the question of why webassembly is not used by the overwhelming majority of websites.
      - flohofwoe 8mo ago
        > why webassembly is not used by the overwhelming majority of websites This is such a bizarre take that I don't know whether it's just a trolling attempt or serious... Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? The two technologies live side by side, each with specific advantages and disadvantages, they are not competing with each other.
        pizlonator 8mo ago
        > This is such a bizarre take that I don't know whether it's just a trolling attempt or serious... I'm being serious. > Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? They mostly shouldn't. There are very few problems where wasm is better. If you want to understand why wasm is not better, see my other posts in this thread.
      - saghm 8mo ago
        That's a fairly arbitrary metric. The overwhelming majority of code running outside of the browser on my laptop isn't in Python, but it's hard to argue that's evidence of it being "doomed to being a second-class citizen on my desktop indefinitely".
    - skybrian 8mo ago
      What toolchain do you use to build your apps?
      - flohofwoe 8mo ago
        Vanilla Emscripten. Most of the higher level platform abstraction (e.g. window system glue, 3D APIs or audio APIs) happens via the sokol headers though: https://github.com/floooh/sokol https://github.com/floooh/sokol
eqrion 8mo ago
I'm not sure I follow this. > WebAssembly is the wrong abstraction for running untrusted apps in a browser WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. > Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. There are dynamic languages, like JS/Python that can compile to wasm. Also I don't see how dynamic typing is required to have API evolution and compt. Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways. > Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented The first major language for WebAssembly was C++, which is object oriented. To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.
- pizlonator 8mo ago
  > WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssembly, you'd have an even harder time than exposing those APIs to JS, because: - You'd still have all of the security troubles. The security troubles come from having to expose API that can be called adversarially and can pass you adversarial data. - You'd also have the impedence mismatch that the browser is reasoning in terms of objects in a DOM, and WebAssembly is a bunch of integers. > There are dynamic languages, like JS/Python that can compile to wasm. If you compile them to linear memory wasm instead of just running directly in JS then you lose the ability to do coordinated garbage collection with the DOM. If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside. > Also I don't see how dynamic typing is required to have API evolution and compt. Because for example if a browser changes the type of something that happens to be unused, or removes something that happens to be unused, it only breaks actual users at time of use, not potential users at time of load. > Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways. We're talking about the browser, which is a particular platform. Not all platforms are the same. The largest comparable platform is OSes based on C ABI, which rely on a "kind" of dynamic typing (stringly typed, basically - function names in a global namespace plus argument passing ABIs that allow you to mismatch function signature and get away with it. > The first major language for WebAssembly was C++, which is object oriented. But the object orientation is lost once you compile to wasm. Wasm's object model when you compile C++ to it is an array of bytes. > To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem. Then what's your excuse for why wasm, despite years of investment, is a dud on the web?
saghm 8mo ago
I'm not convinced JavaScript is a great abstraction for the browser as much as we've forced the web into a shape that fits JavaScript because of a lack of viable alternatives. I'd argue that the popularity of TypeScript implies that dynamic typing is not a universal ideal. Browser engines deal in objects because they're currently all built on top of JavaScript only; that doesn't demonstrate anything fundamental about the web that implies object oriented is the only reasonable representation. If it gets stuck as a second-class citizen like you're predicting, it sounds a lot more like it's due to inflexibility to consider alternatives than anything objectively better about JavaScript.
hrmtst93837 8mo ago
[flagged]
hrmtst93837 8mo ago
[flagged]

flohofwoe 8mo ago

That's just like your opinion man ;) (I'm not a fan of the WASM component model either, but your generalized points are mostly just wrong)

pizlonator 8mo ago
Then give me a counterargument instead of just saying that I'm wrong. My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.
- flohofwoe 8mo ago
  I created and maintain a couple of WASM projects and have not experienced the problems you describe: - https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/ - https://floooh.github.io/sokol-webgpu/ https://floooh.github.io/sokol-webgpu/ - https://floooh.github.io/visualz80remix/ https://floooh.github.io/visualz80remix/ - https://floooh.github.io/doom-sokol/ https://floooh.github.io/doom-sokol/ All those projects also compile into native Windows/Linux/macOS/Android/iOS executables without any code changes, but compiling to WASM and running in web browsers is the most painless way to get this stuff to users. Dealing with minor differences of web APIs in different browsers is a rare thing and can be dealt with in WASM just the same as in JS: a simple if-else will do the job, no dynamic type system needed (apart from that, WASM doesn't have a "type system" in the first place, just like CPU instruction sets don't have one - unless you count integer and float types as type system"). Alternatively it's trivial to call out into Javascript. In Emscripten you can even mix C/C++ and Javascript in the same source file. E.g. for me, WASM is already a '1st class citizen of the web' no WASM component model needed.
  - pizlonator 8mo ago
    The fact that you made some webassembly things isn't an answer to the question of why webassembly is not used by the overwhelming majority of websites.
    - flohofwoe 8mo ago
      > why webassembly is not used by the overwhelming majority of websites This is such a bizarre take that I don't know whether it's just a trolling attempt or serious... Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? The two technologies live side by side, each with specific advantages and disadvantages, they are not competing with each other.
      - pizlonator 8mo ago
        > This is such a bizarre take that I don't know whether it's just a trolling attempt or serious... I'm being serious. > Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS? They mostly shouldn't. There are very few problems where wasm is better. If you want to understand why wasm is not better, see my other posts in this thread.
    - saghm 8mo ago
      That's a fairly arbitrary metric. The overwhelming majority of code running outside of the browser on my laptop isn't in Python, but it's hard to argue that's evidence of it being "doomed to being a second-class citizen on my desktop indefinitely".
  - skybrian 8mo ago
    What toolchain do you use to build your apps?
    - flohofwoe 8mo ago
      Vanilla Emscripten. Most of the higher level platform abstraction (e.g. window system glue, 3D APIs or audio APIs) happens via the sokol headers though: https://github.com/floooh/sokol https://github.com/floooh/sokol

eqrion 8mo ago

I'm not sure I follow this. > WebAssembly is the wrong abstraction for running untrusted apps in a browser WebAssembly is a better fit for a platform running untrusted apps than JS. WebAssembly has a sandbox and was designed for untrusted code. It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. > Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing. There are dynamic languages, like JS/Python that can compile to wasm. Also I don't see how dynamic typing is required to have API evolution and compt. Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways. > Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented The first major language for WebAssembly was C++, which is object oriented. To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.

pizlonator 8mo ago
> WebAssembly has a sandbox and was designed for untrusted code. So does JavaScript. > It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code. They have that infrastructure because JS has access to the browser's API. If you tried to redesign all of the web APIs in a way that exposes them to WebAssembly, you'd have an even harder time than exposing those APIs to JS, because: - You'd still have all of the security troubles. The security troubles come from having to expose API that can be called adversarially and can pass you adversarial data. - You'd also have the impedence mismatch that the browser is reasoning in terms of objects in a DOM, and WebAssembly is a bunch of integers. > There are dynamic languages, like JS/Python that can compile to wasm. If you compile them to linear memory wasm instead of just running directly in JS then you lose the ability to do coordinated garbage collection with the DOM. If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside. > Also I don't see how dynamic typing is required to have API evolution and compt. Because for example if a browser changes the type of something that happens to be unused, or removes something that happens to be unused, it only breaks actual users at time of use, not potential users at time of load. > Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways. We're talking about the browser, which is a particular platform. Not all platforms are the same. The largest comparable platform is OSes based on C ABI, which rely on a "kind" of dynamic typing (stringly typed, basically - function names in a global namespace plus argument passing ABIs that allow you to mismatch function signature and get away with it. > The first major language for WebAssembly was C++, which is object oriented. But the object orientation is lost once you compile to wasm. Wasm's object model when you compile C++ to it is an array of bytes. > To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem. Then what's your excuse for why wasm, despite years of investment, is a dud on the web?

saghm 8mo ago

I'm not convinced JavaScript is a great abstraction for the browser as much as we've forced the web into a shape that fits JavaScript because of a lack of viable alternatives. I'd argue that the popularity of TypeScript implies that dynamic typing is not a universal ideal. Browser engines deal in objects because they're currently all built on top of JavaScript only; that doesn't demonstrate anything fundamental about the web that implies object oriented is the only reasonable representation. If it gets stuck as a second-class citizen like you're predicting, it sounds a lot more like it's due to inflexibility to consider alternatives than anything objectively better about JavaScript.

hrmtst93837 8mo ago

[flagged]

hrmtst93837 8mo ago

[flagged]