8 ms·

It is strange to me to see so much talk about all of the places WebAssembly could live, like IoT devices and edge lambdas and cross-architecture binaries, place

It is strange to me to see so much talk about all of the places WebAssembly could live, like IoT devices and edge lambdas and cross-architecture binaries, places that don't really need these problems to be solved, and yet so little talk about whether or not it can finally unshackle the web from the mess that is JavaScript. As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity.

danielvaughn 3y ago
It can perform a lot of computational work, but yeah it can't yet interface directly with the DOM. I'm not sure about whether it can access the network or other things, but I don't believe that it can.
- deleted 3y ago
  [deleted]
- edgyquant 3y ago
  Are there plans to add DOM support? That seems pretty critical for what I had thought wasm was supposed to be myself.
  - danielvaughn 3y ago
    I'm not sure. All I know is that there are some hurdles to get past. One of them is that several DOM APIs were created specifically for JavaScript, which is...really disheartening.
  - davexunit 3y ago
    Wasm allows for importing host functions. Those host functions could provide DOM access. With Wasm GC it is possible to pass external references (DOM nodes, promises, etc.) to and from Wasm. What this looks like in practice is that a thin JS bootstrap script instantiates the Wasm module, passing along a set of JS functions that map to the declared Wasm imports and then the program is effectively driven from Wasm at that point.
- ryukafalz 3y ago
  > but yeah it can't yet interface directly with the DOM The Spritely folks are doing DOM manipulation from Scheme in Wasm, is there something beyond this that you're referring to? https://spritely.institute/news/building-interactive-web-pages-with-guile-hoot.html https://spritely.institute/news/building-interactive-web-pag...
  - steveklabnik 3y ago
    When people say "can't yet interface directly with the DOM," the "directly" is the key bit. Projects in webassembly have been able to interact with the DOM forever, but they need to do it via JavaScript shims. I am not intimately familiar with Spritely, but from reading the post briefly, it appears this is exactly what they're doing: Scheme.load_main("hello.wasm", {}, { document: { body() { return document.body; }, createTextNode: Document.prototype.createTextNode.bind(document) This requires boilerplate and adds overhead that would not exist if it were able to be done "directly."
    - davexunit 3y ago
      I suspect as time goes on we'll see more and more of this become direct through optimization. My understanding is that this already happens for certain well-known methods, like if you import Math.sin or something V8 is going to optimize it to a direct call when it compiles the Wasm module that imports it. And maybe a non-JS interface will emerge, but there needs to be some kind of layer that preserves capability security. You wouldn't want any and every Wasm module to have access to the entire browser API. You will still want the ability to omit capabilities, attenuate them, etc. and for that a full programming language seems necessary and well... JS is already there.
- 0x457 3y ago
  WASM in the browser can do exactly one thing aside from what is in WASM spec - interface with JavaScript. It's not even that slow to interface with JS from WASM if you do it right (i.e. you aren't passing strings back and forth).
jauntywundrkind 3y ago
While I don't necessarily agree with the unnecessary, unsupported, casual, & cheap (provided with zero substantiating/contestable support) contempt culture here ("unshackle the web from the mess that is JavaScript", "places that don't really need these problems to be solved")... WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements. Long running effort, but it's hard work and there's just not that many hands available for this deep work. Some assorted links with more: https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model https://www.fermyon.com/blog/webassembly-component-model https://www.fermyon.com/blog/webassembly-component-model https://thenewstack.io/can-webassembly-get-its-act-together-for-a-component-model/ https://thenewstack.io/can-webassembly-get-its-act-together-... A preview-2 should be arriving sometime somewhat soon. It's just hard work. It's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.
- davexunit 3y ago
  The type system introduced in Wasm GC allows sharing data between the host and other modules and is usable right now. DOM access is possible and being demonstrated in several language implementations.
  - singularity2001 3y ago
    are you sure? the last time I checked JavaScript was NOT able to access Wasm/GC objects
    - paroneayea 3y ago
      Yes, we have made use of JS invoking WASM-GC managed Scheme objects in our Hoot demos at Spritely.
evrimoztamur 3y ago
Yep, we are still generating bindings, but I don’t think that’s going to change anytime soon. WebAssembly to JavaScript is what the C ABI is to Python, with an additional bounce back to JavaScript land.
CharlesW 3y ago
Wasm isn't a replacement for JavaScript. I think it's clever to leverage JavaScript as an interface to an ever-changing and extremely broad suite of native browser APIs, and keep Wasm small, fast, and secure.
- josephg 3y ago
  > Wasm isn't a replacement for JavaScript I think a lot of people want it to be a replacement for JavaScript. And I think that makes sense, if for no other reason than learning JavaScript is a hassle. Lots of folks think of themselves as a C# developer, or a Python developer or whatever. A lot of developers would rather make websites in their language of choice than learn JavaScript. (And who can blame them?). Webassembly (with GC bindings) should be able to make that possible.
  - JoshTriplett 3y ago
    Indeed. node.js was popular in part because you can use the same language on the client and the server. All-WebAssembly no-JavaScript sites would allow the same thing with other languages.
  - bmoxb 3y ago
    Learning new languages may be component of it, but I think more generally, different languages are suitable for different problems and different developers. Being free to use the most suitable or preferred tool for a task is undoubtedly desirable, rather than having JavaScript as the only option. And, while more of a personal opinion, JavaScript is not a well designed language - permanently shackling the web to it prevents progress forward.
  - ern 3y ago
    As much as many people want alternatives to JavaScript, there are also people who consider themselves JavaScript experts (or the various related languages like TypeScript). They’ve invested a ton of time and effort into getting to where they are. There’s a balance between disruptive change and keeping these folks on board. Get it wrong and you’ll end up with it strangled in its cradle. My own take is that low-code platforms will continue aggressively moving into this space, especially in the enterprise space. They come with their own problems and are often aggressively overhyped, but they will put pressure on “traditional” developers to move faster and look for better solutions.
holoduke 3y ago
How can a language be a mess? I hear lots of personal frustrations. But saying a language is a mess is too short sighted I believe.
- solardev 3y ago
  Correct me if I'm wrong, but aren't most languages designed and controlled by some relatively centralized organization, whether a company or a nonprofit? Javascript, on the other hand, is a loose standard that different companies kinda sorta adhere to. It was a rushed one man project put out to compete with Java back in the 90s, then every browser tried to do their own somewhat compatible implementation. Javascript became the lowest common denominator, winning out not because it was better than say Java or ActiveX or Flash or whatever. It was just commonly available. Fast forward a couple decades, the situation is both better and worse. We at least have ECMAScript now, and the core language has certainly gotten better and more dev-friendly. Unfortunately, what ECMAScript covers is so limited and the standard lib is still so poor that lodash and similar are common just for basic data manipulation, not to mention the hundred DOM abstractions like React or Vue or Svelte, and occasionally Angular. And client-side state is its own nightmare, and then persisting things into cookies/localstorage/indexedDB is a whole other can of worms, along with different ways to do pub sub. Being tethered to file-based HTTP and HTML means that even basic routing is a hack on top of a hack. There is no standard package manager, and npm is a third party project, which can't agree on which module format to use. Libs from like 2 or 3 years ago will often be incompatible with new code. And that's just assuming you're using a browser. Outside of that there's not even a standard runtime, between Node, Deno, Bun, etc. Typescript is yet another third party add on, not something baked into the language. Eslint, prettier, etc. are all third party things. In the old days a lot of this used to just be baked into the language itself, or at least an official IDE . If you ever had a chance to use Visual Studio (Not VSCode) in the old days, everything was so well designed and integrated, from code organization to the standard libs to the UI editor. Nowadays there's 300 ways from 200 companies to do anything in Javascript, none of it particularly good or secure or performant or easy to read. In a way it's natural selection, I guess, with different implementations all competing for supremacy, but it definitely is messy. Every time I use JS (which is every workday) I can't help but wish some other, more coherent, language won out.
rdtsc 3y ago
> As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity. That's the underlying messy API it's built on. There are specs to make the API more standardized like https://github.com/WebAssembly/WASI https://github.com/WebAssembly/WASI But overall, yeah, it feels like a shiny new toy everyone is excited about and wants to use. Some toys can be fun to play with, but it doesn't mean we have to rewrite production systems in it. Sometimes, or most of the time, toys don't become useful tools.
- dylan604 3y ago
  Isn't that specifically why they are called toys and not tools?
  - rdtsc 3y ago
    That's the idea! If we can just convince people who make product and technology decisions to see that and not push the next shiny toy as the new tool or library everyone has to use, we'd all be in good shape :-)
    - DonHopkins 3y ago
      Because you think Unity3D should have stuck with its tried and true Flash back-end instead of moving on to shiny toy WebAssembly? https://forum.unity.com/threads/return-flash-deployment-back.231072/ https://forum.unity.com/threads/return-flash-deployment-back... >Flash was not discontinued "because it couldn't provide good graphics". It was discontinued, because we no longer believe that Flash as a platform has any future. That has not changed.
- dmazzoni 3y ago
  You seem to think WebAssembly is a "toy" and nobody's really found a good use for it, but actually it's being used in some really successful and high-profile web apps, but it's so seamless that you probably don't even realize it. Here are some of my favorite examples: Figma Google Earth Photoshop Web Any Unity games you've played on the web: WebAssembly. Everything built using the Blazor framework in C#: runs on WebAssembly on the web. I really don't think all of those sites are using WebAssembly because it's a cool new toy. They're using it because it's actually pretty useful technology that enables you to build really powerful software that runs on the web browser without being limited to JavaScript.
aseipp 3y ago
> As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity. It was always the goal for WebAssembly code living in the browser to have some form of object model/DOM integration, and interaction with JavaScript objects. What form it would take exactly wasn't clear. But that was never a goal for the original 1.0 specification (MVP), and not even in spec for the current 2.0 draft -- which mostly add a bunch more useful instructions and features, but nothing earth shattering. The reality is that whatever solution gets accepted has to be supported and continue working for what is effectively ~infinite time, in multiple major browser engines. For custom runtimes it's sort of "whatever", but webpages can live forever so it's taking a lot of time to get right. But there was clearly a lot of value to be had without that, hence 1.0 was the "MVP."
zengid 3y ago
I think once WasmGC is finished up, that will make shipping a VM inside a VM more viable. Opening up direct access to the DOM would be cool, but if it were up to me, I'd just skip it and render everything inside a <canvas/> and avoid all of the "build an application on top of a document format" crap that makes web apps so weird to make.
- noman-land 3y ago
  Not a very accessible solution.
  - zengid 3y ago
    It can be! I think that's the number 1 response when anyone wants to actually make a better platform. Projects like AccessKit are a really great step in the right direction https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit
    - noman-land 3y ago
      Cool, thanks for the share. I will check it out.
- munificent 3y ago
  > if it were up to me, I'd just skip it and render everything inside a <canvas/> That's very tempting, but you lose a lot if you do that, especially around text: * Accessibility for screen readers, etc. * The easy ability to select text, copy/paste between other apps, etc. * Line splitting * Support for multiple languages, RTL, and all their other rendering quirks. Canvas has some text APIs, but they are fairly rudimentary. It's a hard problem.
  - zengid 3y ago
    I completely agree, and these are required features for a full app that is planning to reach the world. It requires a lot of extra work, but real world apps like Figma [0] are rendering directly to the canvas, and frameworks like Flutter offer support for canvas rendering (via Skia's CanvasKit) [1] [2]. I guess my point is that if someone is using WASM to ditch JavaScript, why stop there? Ditch the DOM and CSS too! Render all of the graphics with OpenGl or WebGPU! There is a class of applications that I want to explore that would be better suited to by doing just that. I don't believe every app should do that, just that for what I want to build, that's where I'm looking at going (hence my "if it were up to me" comment above). [0] https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/ https://www.figma.com/blog/building-a-professional-design-to... [1] https://docs.flutter.dev/platform-integration/web/renderers https://docs.flutter.dev/platform-integration/web/renderers [2] https://skia.org/docs/user/modules/canvaskit/ https://skia.org/docs/user/modules/canvaskit/
moralestapia 3y ago
>unshackle the web from the mess that is JavaScript well_thats_your_opinion.jpeg Javascript is great and the web became what it is today because of it, not in spite of it.
- deleted 3y ago
  [deleted]
ilaksh 3y ago
A lot of use cases are applications that don't technically require a DOM but maybe just the ability to copy and paste text. The biggest thing is some kind of graphics capability. What I think happened, if you look at the web assembly design discussions, is that they made the initially correct decision to limit the scope to be more manageable, but then over the years that decision became something of a religion and even a strange badge of honor. "Web assembly is not meant to replace JavaScript". It certainly is challenging to try to standardized on anything like device input or graphics APIs, but after say three years, competent and sane designers obviously should have been working on that. Maybe I am a conspiracy theorist (I am) but I sometimes suspect that Google has deliberately limited the scope of web assembly in order to maintain the control that the dominance of Chrome provides them. Because if things like keyboard/mouse and graphics had some type of web assembly standard, then it would be easy for different runtimes to support them. Then before you know it, you don't need the browser for most things, you can just use your favorite web assembly runtime. I will go so far as to suggest that this is an antitrust issue and that a technically competent government (of which maybe non exist so far) would have somehow forced the development of an evolvable shared standard like web assembly that is not missing important pieces like graphics. I see web assembly as the obvious successor to Java. It's been held back by some strange psychology and maybe even intentional sabotage.
camgunz 3y ago
The main problem is that either you compile a WASM binary or you serve a big language runtime (itself compiled to WASM) all the time: this is what you'd have to do if using C# or Java for example (maybe you can use TeaVM, but maybe you can't). For some reason browsers didn't want to "balkanize the web" for the really good reason of supporting multiple languages, they wanted to do it for very petty reasons like WebMIDI or wildly differing implementations of LocalStorage (e.g. how much you can put in there), or non-overlapping support for video codecs, etc etc etc.
raxxorraxor 3y ago
While there is valid criticism of JS, I am not sure if I really want binary blobs executed in my browser. Sure, for applications that really need to strip the overhead of a scripting language, it is very welcome. But for the average website? Not sure about it... And security is another matter, there is a reason the WebAssembly sandbox is so restrictive. Webassembly is awesome, but the solution needs to fit the problem.

danielvaughn 3y ago

It can perform a lot of computational work, but yeah it can't yet interface directly with the DOM. I'm not sure about whether it can access the network or other things, but I don't believe that it can.

deleted 3y ago
[deleted]
edgyquant 3y ago
Are there plans to add DOM support? That seems pretty critical for what I had thought wasm was supposed to be myself.
- danielvaughn 3y ago
  I'm not sure. All I know is that there are some hurdles to get past. One of them is that several DOM APIs were created specifically for JavaScript, which is...really disheartening.
- davexunit 3y ago
  Wasm allows for importing host functions. Those host functions could provide DOM access. With Wasm GC it is possible to pass external references (DOM nodes, promises, etc.) to and from Wasm. What this looks like in practice is that a thin JS bootstrap script instantiates the Wasm module, passing along a set of JS functions that map to the declared Wasm imports and then the program is effectively driven from Wasm at that point.
ryukafalz 3y ago
> but yeah it can't yet interface directly with the DOM The Spritely folks are doing DOM manipulation from Scheme in Wasm, is there something beyond this that you're referring to? https://spritely.institute/news/building-interactive-web-pages-with-guile-hoot.html https://spritely.institute/news/building-interactive-web-pag...
- steveklabnik 3y ago
  When people say "can't yet interface directly with the DOM," the "directly" is the key bit. Projects in webassembly have been able to interact with the DOM forever, but they need to do it via JavaScript shims. I am not intimately familiar with Spritely, but from reading the post briefly, it appears this is exactly what they're doing: Scheme.load_main("hello.wasm", {}, { document: { body() { return document.body; }, createTextNode: Document.prototype.createTextNode.bind(document) This requires boilerplate and adds overhead that would not exist if it were able to be done "directly."
  - davexunit 3y ago
    I suspect as time goes on we'll see more and more of this become direct through optimization. My understanding is that this already happens for certain well-known methods, like if you import Math.sin or something V8 is going to optimize it to a direct call when it compiles the Wasm module that imports it. And maybe a non-JS interface will emerge, but there needs to be some kind of layer that preserves capability security. You wouldn't want any and every Wasm module to have access to the entire browser API. You will still want the ability to omit capabilities, attenuate them, etc. and for that a full programming language seems necessary and well... JS is already there.
0x457 3y ago
WASM in the browser can do exactly one thing aside from what is in WASM spec - interface with JavaScript. It's not even that slow to interface with JS from WASM if you do it right (i.e. you aren't passing strings back and forth).

jauntywundrkind 3y ago

While I don't necessarily agree with the unnecessary, unsupported, casual, & cheap (provided with zero substantiating/contestable support) contempt culture here ("unshackle the web from the mess that is JavaScript", "places that don't really need these problems to be solved")... WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements. Long running effort, but it's hard work and there's just not that many hands available for this deep work. Some assorted links with more: https://github.com/WebAssembly/component-model https://github.com/WebAssembly/component-model https://www.fermyon.com/blog/webassembly-component-model https://www.fermyon.com/blog/webassembly-component-model https://thenewstack.io/can-webassembly-get-its-act-together-for-a-component-model/ https://thenewstack.io/can-webassembly-get-its-act-together-... A preview-2 should be arriving sometime somewhat soon. It's just hard work. It's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.

davexunit 3y ago
The type system introduced in Wasm GC allows sharing data between the host and other modules and is usable right now. DOM access is possible and being demonstrated in several language implementations.
- singularity2001 3y ago
  are you sure? the last time I checked JavaScript was NOT able to access Wasm/GC objects
  - paroneayea 3y ago
    Yes, we have made use of JS invoking WASM-GC managed Scheme objects in our Hoot demos at Spritely.

evrimoztamur 3y ago

Yep, we are still generating bindings, but I don’t think that’s going to change anytime soon. WebAssembly to JavaScript is what the C ABI is to Python, with an additional bounce back to JavaScript land.

CharlesW 3y ago

Wasm isn't a replacement for JavaScript. I think it's clever to leverage JavaScript as an interface to an ever-changing and extremely broad suite of native browser APIs, and keep Wasm small, fast, and secure.

josephg 3y ago
> Wasm isn't a replacement for JavaScript I think a lot of people want it to be a replacement for JavaScript. And I think that makes sense, if for no other reason than learning JavaScript is a hassle. Lots of folks think of themselves as a C# developer, or a Python developer or whatever. A lot of developers would rather make websites in their language of choice than learn JavaScript. (And who can blame them?). Webassembly (with GC bindings) should be able to make that possible.
- JoshTriplett 3y ago
  Indeed. node.js was popular in part because you can use the same language on the client and the server. All-WebAssembly no-JavaScript sites would allow the same thing with other languages.
- bmoxb 3y ago
  Learning new languages may be component of it, but I think more generally, different languages are suitable for different problems and different developers. Being free to use the most suitable or preferred tool for a task is undoubtedly desirable, rather than having JavaScript as the only option. And, while more of a personal opinion, JavaScript is not a well designed language - permanently shackling the web to it prevents progress forward.
- ern 3y ago
  As much as many people want alternatives to JavaScript, there are also people who consider themselves JavaScript experts (or the various related languages like TypeScript). They’ve invested a ton of time and effort into getting to where they are. There’s a balance between disruptive change and keeping these folks on board. Get it wrong and you’ll end up with it strangled in its cradle. My own take is that low-code platforms will continue aggressively moving into this space, especially in the enterprise space. They come with their own problems and are often aggressively overhyped, but they will put pressure on “traditional” developers to move faster and look for better solutions.

holoduke 3y ago

How can a language be a mess? I hear lots of personal frustrations. But saying a language is a mess is too short sighted I believe.

solardev 3y ago
Correct me if I'm wrong, but aren't most languages designed and controlled by some relatively centralized organization, whether a company or a nonprofit? Javascript, on the other hand, is a loose standard that different companies kinda sorta adhere to. It was a rushed one man project put out to compete with Java back in the 90s, then every browser tried to do their own somewhat compatible implementation. Javascript became the lowest common denominator, winning out not because it was better than say Java or ActiveX or Flash or whatever. It was just commonly available. Fast forward a couple decades, the situation is both better and worse. We at least have ECMAScript now, and the core language has certainly gotten better and more dev-friendly. Unfortunately, what ECMAScript covers is so limited and the standard lib is still so poor that lodash and similar are common just for basic data manipulation, not to mention the hundred DOM abstractions like React or Vue or Svelte, and occasionally Angular. And client-side state is its own nightmare, and then persisting things into cookies/localstorage/indexedDB is a whole other can of worms, along with different ways to do pub sub. Being tethered to file-based HTTP and HTML means that even basic routing is a hack on top of a hack. There is no standard package manager, and npm is a third party project, which can't agree on which module format to use. Libs from like 2 or 3 years ago will often be incompatible with new code. And that's just assuming you're using a browser. Outside of that there's not even a standard runtime, between Node, Deno, Bun, etc. Typescript is yet another third party add on, not something baked into the language. Eslint, prettier, etc. are all third party things. In the old days a lot of this used to just be baked into the language itself, or at least an official IDE . If you ever had a chance to use Visual Studio (Not VSCode) in the old days, everything was so well designed and integrated, from code organization to the standard libs to the UI editor. Nowadays there's 300 ways from 200 companies to do anything in Javascript, none of it particularly good or secure or performant or easy to read. In a way it's natural selection, I guess, with different implementations all competing for supremacy, but it definitely is messy. Every time I use JS (which is every workday) I can't help but wish some other, more coherent, language won out.

rdtsc 3y ago

> As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity. That's the underlying messy API it's built on. There are specs to make the API more standardized like https://github.com/WebAssembly/WASI https://github.com/WebAssembly/WASI But overall, yeah, it feels like a shiny new toy everyone is excited about and wants to use. Some toys can be fun to play with, but it doesn't mean we have to rewrite production systems in it. Sometimes, or most of the time, toys don't become useful tools.

dylan604 3y ago
Isn't that specifically why they are called toys and not tools?
- rdtsc 3y ago
  That's the idea! If we can just convince people who make product and technology decisions to see that and not push the next shiny toy as the new tool or library everyone has to use, we'd all be in good shape :-)
  - DonHopkins 3y ago
    Because you think Unity3D should have stuck with its tried and true Flash back-end instead of moving on to shiny toy WebAssembly? https://forum.unity.com/threads/return-flash-deployment-back.231072/ https://forum.unity.com/threads/return-flash-deployment-back... >Flash was not discontinued "because it couldn't provide good graphics". It was discontinued, because we no longer believe that Flash as a platform has any future. That has not changed.
dmazzoni 3y ago
You seem to think WebAssembly is a "toy" and nobody's really found a good use for it, but actually it's being used in some really successful and high-profile web apps, but it's so seamless that you probably don't even realize it. Here are some of my favorite examples: Figma Google Earth Photoshop Web Any Unity games you've played on the web: WebAssembly. Everything built using the Blazor framework in C#: runs on WebAssembly on the web. I really don't think all of those sites are using WebAssembly because it's a cool new toy. They're using it because it's actually pretty useful technology that enables you to build really powerful software that runs on the web browser without being limited to JavaScript.

aseipp 3y ago

> As I understand it, it's not even really possible today to make WebAssembly do anything meaningful in the browser without trampolining back out to JavaScript anyway, which seems like a remarkable missed opportunity. It was always the goal for WebAssembly code living in the browser to have some form of object model/DOM integration, and interaction with JavaScript objects. What form it would take exactly wasn't clear. But that was never a goal for the original 1.0 specification (MVP), and not even in spec for the current 2.0 draft -- which mostly add a bunch more useful instructions and features, but nothing earth shattering. The reality is that whatever solution gets accepted has to be supported and continue working for what is effectively ~infinite time, in multiple major browser engines. For custom runtimes it's sort of "whatever", but webpages can live forever so it's taking a lot of time to get right. But there was clearly a lot of value to be had without that, hence 1.0 was the "MVP."

zengid 3y ago

I think once WasmGC is finished up, that will make shipping a VM inside a VM more viable. Opening up direct access to the DOM would be cool, but if it were up to me, I'd just skip it and render everything inside a <canvas/> and avoid all of the "build an application on top of a document format" crap that makes web apps so weird to make.

noman-land 3y ago
Not a very accessible solution.
- zengid 3y ago
  It can be! I think that's the number 1 response when anyone wants to actually make a better platform. Projects like AccessKit are a really great step in the right direction https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit
  - noman-land 3y ago
    Cool, thanks for the share. I will check it out.
munificent 3y ago
> if it were up to me, I'd just skip it and render everything inside a <canvas/> That's very tempting, but you lose a lot if you do that, especially around text: * Accessibility for screen readers, etc. * The easy ability to select text, copy/paste between other apps, etc. * Line splitting * Support for multiple languages, RTL, and all their other rendering quirks. Canvas has some text APIs, but they are fairly rudimentary. It's a hard problem.
- zengid 3y ago
  I completely agree, and these are required features for a full app that is planning to reach the world. It requires a lot of extra work, but real world apps like Figma [0] are rendering directly to the canvas, and frameworks like Flutter offer support for canvas rendering (via Skia's CanvasKit) [1] [2]. I guess my point is that if someone is using WASM to ditch JavaScript, why stop there? Ditch the DOM and CSS too! Render all of the graphics with OpenGl or WebGPU! There is a class of applications that I want to explore that would be better suited to by doing just that. I don't believe every app should do that, just that for what I want to build, that's where I'm looking at going (hence my "if it were up to me" comment above). [0] https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/ https://www.figma.com/blog/building-a-professional-design-to... [1] https://docs.flutter.dev/platform-integration/web/renderers https://docs.flutter.dev/platform-integration/web/renderers [2] https://skia.org/docs/user/modules/canvaskit/ https://skia.org/docs/user/modules/canvaskit/

moralestapia 3y ago

>unshackle the web from the mess that is JavaScript well_thats_your_opinion.jpeg Javascript is great and the web became what it is today because of it, not in spite of it.

deleted 3y ago
[deleted]

ilaksh 3y ago

A lot of use cases are applications that don't technically require a DOM but maybe just the ability to copy and paste text. The biggest thing is some kind of graphics capability. What I think happened, if you look at the web assembly design discussions, is that they made the initially correct decision to limit the scope to be more manageable, but then over the years that decision became something of a religion and even a strange badge of honor. "Web assembly is not meant to replace JavaScript". It certainly is challenging to try to standardized on anything like device input or graphics APIs, but after say three years, competent and sane designers obviously should have been working on that. Maybe I am a conspiracy theorist (I am) but I sometimes suspect that Google has deliberately limited the scope of web assembly in order to maintain the control that the dominance of Chrome provides them. Because if things like keyboard/mouse and graphics had some type of web assembly standard, then it would be easy for different runtimes to support them. Then before you know it, you don't need the browser for most things, you can just use your favorite web assembly runtime. I will go so far as to suggest that this is an antitrust issue and that a technically competent government (of which maybe non exist so far) would have somehow forced the development of an evolvable shared standard like web assembly that is not missing important pieces like graphics. I see web assembly as the obvious successor to Java. It's been held back by some strange psychology and maybe even intentional sabotage.

camgunz 3y ago

The main problem is that either you compile a WASM binary or you serve a big language runtime (itself compiled to WASM) all the time: this is what you'd have to do if using C# or Java for example (maybe you can use TeaVM, but maybe you can't). For some reason browsers didn't want to "balkanize the web" for the really good reason of supporting multiple languages, they wanted to do it for very petty reasons like WebMIDI or wildly differing implementations of LocalStorage (e.g. how much you can put in there), or non-overlapping support for video codecs, etc etc etc.

raxxorraxor 3y ago

While there is valid criticism of JS, I am not sure if I really want binary blobs executed in my browser. Sure, for applications that really need to strip the overhead of a scripting language, it is very welcome. But for the average website? Not sure about it... And security is another matter, there is a reason the WebAssembly sandbox is so restrictive. Webassembly is awesome, but the solution needs to fit the problem.