14 ms·

WASM: Big deal or little deal?

115 points by elorant 3y ago

goalieca 3y ago
> Does that sound familiar? It should, you could use that same description for containers The reminds me of java but with native web browser support instead of applets.
- coffeebeqn 3y ago
  This has all happened before. Java web things, Flash, etc. they all have the same problem that they don’t fit in with semantic web content
  - zdragnar 3y ago
    That's not why those things died, though. They died because smartphones stopped supporting them, and that combined with advancements in JS engine speed were all it took to get brother vendors to scrap the buggy, security-hole-ridden plugin ecosystem. WASM should hopefully not be bad from a security perspective, but the up-front performance penalty of early demos in downloading megabytes for hello world was painful. More purpose-fit, smaller modules ought to be broadly useful but I'll not be holding my breath. Anything that needs to take over a canvas probably isn't going to be widely adopted outside of some niche things like visual design tools or the occasional game.
    - tcfhgj 3y ago
      Megabytes are certainly an exaggeration, see 285.4 KB for Leptos
      - lelanthran 3y ago
        >> the up-front performance penalty of early demos in downloading megabytes for hello world was painful. > Megabytes are certainly an exaggeration, see 285.4 KB for Leptos Those early demos were certainly quite large. I don't think that I found any early demo of WASM to be under a megabyte, for sometimes quite trivial things.
  - paulgb 3y ago
    Flash and Java Applets both owned a rectangle of the screen. Wasm interacts with the page just like JS does. So in contrast to Flash and Java, Wasm fits in with semantic web content to the same extent that JS does.
    - throwaway847599 3y ago
      Java applets could access the DOM and even run Javascript functions.
      - paulgb 3y ago
        Sure, but presumably the ones that “don’t fit in semantic web content” is a reference to the ones that rendered a portion of the page in Java, otherwise the same could be said about JavaScript.
    - jeroenhd 3y ago
      As you can read in the various comments on here, that's also the model many WASM fans are going for. Google Docs switched to rendering a full screen canvas rather than using the DOM, and Flutter/Compose do the exact same thing. WASM is very much heading in the direction of owning a rectangle on the screen. Plus, Java and Flash embeds could also call Javascript callbacks while leveraging the improved performance of their native plugins.
      - paulgb 3y ago
        Google Docs doesn’t use Wasm, from what I can tell. The move towards using canvas/gl/webgpu over DOM for performance is orthogonal to using Wasm. They go together nicely, but if you’re worried about DOM being replaced, Docs is a good example of how that will happen with or without Wasm. Another pattern I’ve seen is to render DOM on top of a canvas, with UI elements done in the DOM, and high-performance graphics on the canvas. This seems to be a good balance. https://x.com/paulgb/status/1688919428740816896?s=46 https://x.com/paulgb/status/1688919428740816896?s=46
    - troupo 3y ago
- paulddraper 3y ago
  That, but without the proprietary UI
  - lmm 3y ago
    Tclets were fully open source and Java applets were mostly open source. It doesn't seem to have helped.
    - paulddraper 3y ago
      Perhaps I should say non-standard/non-native. Java applets used Java Swing UI
      - lmm 3y ago
        Most WASM applications use extremely non-native UI elements.
      - pvg 3y ago
        Applets pre-dated and didn't depend on Swing. But even native UI in the middle of a web-page looked non-native.
- intrasight 3y ago
  I was sure that "Does that sound familiar" would be followed by the history of Java. There's no VM in Docker.
  - pjmlp 3y ago
    WASM Runtime...
    - intrasight 3y ago
      That new tech. The article quote was referring to Docker pre-WASM.
      - pjmlp 3y ago
        What article? Docker needs a WASM runtime regardless. Some magic incantation has to change those bytecodes into executable code.
CottonMcKnight 3y ago
It's pretty objectively a big deal. (Feature-limited) Photoshop was ported to WASM in 2021. https://web.dev/ps-on-the-web/ https://web.dev/ps-on-the-web/ With the deprecation and imminent removal of WebSQL, the official (Google) recommendation for SQL-in-browser is WASM SQLite. https://sqlite.org/wasm/doc/trunk/index.md https://sqlite.org/wasm/doc/trunk/index.md
- Kiuhrly1 3y ago
  For the web and other use cases where it is embedded in another program (e.g. sandboxed plugins, other places where Lua or similar would've gone previously), I think yes. But I really don't see something like WASI or WASM servers sticking around, especially because it still has a noticeable performance penalty compared to native (can't source this right now, need to sleep)
- zdragnar 3y ago
  Say what? WebSQL was an experiment that ended up being replaced by indexeddb- it has been deprecated ever since, and was never part of the web standards.
  - CottonMcKnight 3y ago
    It has been deprecated for a long time but still available in Chromium. It is being removed in Chromium 119 at the end of next month. See the aside about SQLite WASM on this blog post. https://developer.chrome.com/blog/deprecating-web-sql/ https://developer.chrome.com/blog/deprecating-web-sql/
  - afavour 3y ago
    It’s telling that despite IndexedDB being around forever people would still rather download an entire SQLite runtime than use it. A deeply unsatisfying API.
    - smashed 3y ago
      If I remember correctly, the main argument against web sql was that it really was just SQLite disguised as a web standard. I.e. there was a single implementation which defined the spec: SQLite. Every browser implementation relied on it. In retrospect, with the chrome monoculture we have today, this seems like a silly argument but at the time it was a legitimate concern.
irrational 3y ago
I judge things by how they affect me right now. Right now it is not a big deal. As a web developer I haven’t had a need for it and don’t anticipate a need for it any time in the near future. If I need to use it at some point in the future, maybe it will be a big deal.
- crubier 3y ago
  "If it's not a big deal now it's not a big deal now, and if it's a big deal in the future then it will be a big deal in the future" is not adding as much to the conversation as you think it is. The point of HN is in large part about thinking about the future and not just look about how things are just "right now". There is no point discussing the impact that things have right now, we can just measure it.
  - MBCook 3y ago
    But it’s not new. It’s been around for years. And I’m not really aware of any real uses on the web. Other people in these comments have mentioned using it as an extension mechanism to other applications. That’s nice. But what browsers use it internally? What popular JS/TS libraries? What big websites? It seems Figma does, but I had to Google to find that. It’s an interesting idea, but it feels a bit like VRML or something else so far. “It’s going to take off, just give it time.” Some things will. Some won’t. But WASM doesn’t seem to provide enough above JS to overcome the “we can just use JS” hurdle for the vast majority of uses so far.
    - tbrownaw 3y ago
      I believe blazor (dotnet in the browser) is built on it.
- paulgb 3y ago
  Web (site) developers will likely never have to learn Wasm if they don’t want to. But people are increase shipping regular application software to the browser as if it’s an OS. Technically you could say the developers of these apps are “web developers”, but the stack is increasingly diverging from the stack a web (site) developer would need to care about: Wasm, WebGPU, OPFS, etc.
julianeon 3y ago
The tl;dr seems to be it’s a big deal if you need game console like performance in your browser. Want to mock up designs there? You need WASM. But if your answer is “I’m building a SaaS, I don’t need incredible cutting edge performance” - it seems less necessary.
- ajhurliman 3y ago
  Definitely. CAD in the browser? WASM. High-end photographic computation in the browser? WASM. Pretty much everything else… not WASM
refulgentis 3y ago
"For example, Python has become the quick, easy way for people to work with machine learning programs – thank you, PyTorch. But you can't simply drop these programs into WASM in a runtime and expect them to work. The problem is that you also need many third-party dependencies, which aren't there yet." Yes you can, ONNX. Yeah, it's not _literally Pytorch_. But it takes about 10 minutes.
pizzafeelsright 3y ago
Huge. I've been a Chrome OS user for a decade. I no longer worry about the OS, files, or versions. This is great. What we do need is the ability to build the UX locally outside the confines of the browser outside of the existing OS. The idea that files can share user space with other files without explicit permission always felt off.
dhosek 3y ago
Where I see this as a huge deal is for plug-in development. For finl, I was looking at the possibility of incorporating an interpreter for JavaScript or Python or Lua. Instead, I can create bindings for WASM and get a sandboxed environment for people to write their own extensions. There will be some packaging tools that I’ll want to provide (the idea being that a user specifies something like \LoadExtension{yoyodyne:csv-reader:1.0} to bring in an extension and if there isn’t a local copy of the extension, it will fetch it from a repository, and I’ll want to bundle a bunch of stuff into a standard ZIP file layout (so that documentation, etc. will be easily fetched). The list of languages that can compile to WASM increases on a regular basis and it seems by far the best route for plugin handling in a greenfield project.
- bhelx 3y ago
  I work on a project for building such plug-in systems. We have a wide variety of languages supported https://extism.org/ https://extism.org/ > and I’ll want to bundle a bunch of stuff into a standard ZIP file layout (so that documentation, etc. will be easily fetched I've always, thought it would be cool if Wasm runtimes had a generic supported format for this. Kind of like a Java JAR. But of course, you can implement a custom version for application pretty easily.
  - pjmlp 3y ago
    Like CLR plugins....
- flutetornado 3y ago
  Yes, on a related note Neovim just got support for WASM plugins and apparently WASM is 100% faster than Lua (neovim's default plugin language runtime) for this use case according to the author. So now plugins in any language that can be compiled to WASM are possible. Edit: https://github.com/Borwe/wasm_nvim https://github.com/Borwe/wasm_nvim
  - pjmlp 3y ago
    No wonder, since Lua is interpreted and not a fast one at it, unless LuaJIT comes into the picture.
diego_moita 3y ago
It is a reasonable big deal in the niche of computation intensive applications. It would be an huge deal or revolution if it could perform faster on plain DOM manipulation. By now, plain Javascript is faster than WASM [0]. That's because all WASM's DOM manipulation must go through the Javascript engine and many browsers do JIT compilation on Javascript. Edit: be aware that the article has a more interesting discussion on WASM on the server side, as a replacement of technologies such as Docker/containers, Java Virtual Machine and .Net. [0] https://krausest.github.io/js-framework-benchmark/2023/table_chrome_116.0.5845.82.html https://krausest.github.io/js-framework-benchmark/2023/table...
- dclowd9901 3y ago
  A WASM-powered virtual DOM with painting privileges seems all but ascertained given the general direction Mozilla and other interested parties are taking the environment. Include the bubble/capture phases and you’re completely there.
  - satvikpendem 3y ago
    Indeed, I posted this in a sibling comment but this is exactly the future that will arrive: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 The browser will be the unified runtime for WASM apps, native level performance with the linkability and other advantages of the browser.
- satvikpendem 3y ago
  Unless you don't use the DOM at all for UI for web apps: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 It would enable any language to simply render their own UI and handle things like accessibility with their own accessibility based DOM that just handles the accessibility parts rather than the entire logic of the app. I believe this is what Flutter does.
  - pavlov 3y ago
    This means shipping an entire UI framework as part of the web app onto a computer that already is running multiple UI frameworks. For example on macOS with Chrome, you’ll have Flutter running on Chromium running on AppKit. All of these provide text layout engines, compositors, 2D and 3D graphics, widget hierarchies, scripting languages… Hundreds of megabytes of redundant stuff loaded in memory to run some typically basic Flutter app. I know, we can’t magically have native binaries delivered on the web (that was ActiveX and it was bad). But it somehow boggles the mind that this is what we ended up with.
singularity2001 3y ago
WASM may live up to its promise when they finally fix js/dom interop. Looks like it's indefinitely postponed though. so we are stuck with ungodly glue calling between it and JavaScript (which is unavoidable if you want to do much with it), incredibly hacky.
- tcfhgj 3y ago
  Frameworks like Leptos and Dioxus abstract that glue calling away and you still get better performance than most JS frameworks
mikewarot 3y ago
In the beginning, there were incompatible microprocessors, so p-code was widely deployed to avoid having to write the same Pascal compiler over and over on every platform, but it was slow because it was interpreted, but even worse was that it tended to crash. Later, the Java VM was created, to avoid rewriting the same code over on every platform, but it was slow because it was interpreted, but thanks to JIT, that was pretty much taken care of. The main problem then became the fact that it, like ActiveX before it (which wasn't cross-platform), got general access to the file system, and could never really be safely used. It remains to be seen if WASM/WASI retain their commitment to capability based security, which is at this point the main selling point. There have now been fast cross platform systems, but this is the first that builds in capabilities, and doesn't give general access to the file system. Analogy #1 - We need such a system... it's like power in a home... with a circuit breaker, and the promise that you're only going to get 15 amps, not all of the power of the grid, flowing to anything you plug in. Analogy #2 - It's like cash in a wallet, you decide how much to hand over to an untrusted partner in a transaction. You should be able to decide what files/folders to hand to a program, and know it won't get anything more than that. Analogy #3 - The IBM PC XT with twin floppy disks was the most secure general purpose computer of its time, and still is. You had control over your data, full and transparent control, because you decided what the allowable side effects were when you decided what disks to let it access, and also if they were read-only or writeable. You can't do that today.
- pjmlp 3y ago
  You missed the history before Pascal came to be, P-Code wasn't the first. Burroughs in 1961 was already bytecode based, all Xerox PARC systems used bytecode, as did several other systems. Pascal P-Code might be one of the most famous ones, however there plenty others to learn from.
  - mikewarot 3y ago
    I also deliberately left out the phase change that was caused by IBM including 1401 Emulation in System 360. Before that, everyone rewrote their programs every time a new machine came out, because it was expected it would be incompatible with the old one, so we have a ton of code still running that wasn't expected to last more than 10 years when it was written, in the late 1950s, early 1960s.
eternityforest 3y ago
I'm kind of afraid of this. When it gets DOM and drawing abilities, People are gonna build SO many things of varying levels of quality, from scratch, that probably could have been done with existing JS frameworks, don't work well with browser features, require learning 583 languages to work on anything, etc. It will be amazing for compute heavy stuff in the browser I'd imagine. Cross platform assembly is a super cool idea. If they can get it right at least we might have something besides a container that runs anywhere. I'm just not sure I want them to mess with JS/HTML based UI just when it was really getting awesome and declarative was becoming standard... And since web devs like. Making stuff harder than it needs to be they might...
pjmlp 3y ago
Little deal. Plenty of WASM advocates act ad if we haven't had endless attempts at since the 1960's. Also doing kubernetes with WASM containers must be a bad joke, when comparing how managing Websphere 5 in 2005 was so much easier. On the browser side, it is a convoluted experience versus using Flash/Code Alchemy, Java Applets, Silverlight, with Blazor/Flutter being the only ones that somehow come close to how it used to be 15 years ago.
- DarkNova6 3y ago
  You are comparing an open, non-proprietary compile target to a closed ecosystem. Admittedly, WASM is making slow progress (much to it due to Google actively/passively sabotaging it) but it is the closest we have got to a universal compile target. In particular, the combination with Rust could be a game changer and make whole categories of DSLs obsolete. It also has the potential to open FE work for people which categorically refuse to work with the mess that is the JS ecosystem.
  - giancarlostoro 3y ago
    Got any examples of Google sabotaging WASM? First I have heard of this. I thought Apple was kind of since they seem to adopt some things somewhat slow or not at all.
    - jamil7 3y ago
      WebKit has had a WASM implementation since 2017, the same as Chrome and Firefox as far as I know.
      - callahad 3y ago
        We all (Mozilla/Google/Microsoft/Apple) announced consensus for the WebAssembly MVP on February 28, 2017. Mozilla and Google shipped on-by-default in March, Apple in September, and Microsoft in October.
    - brabel 3y ago
meindnoch 3y ago
As usual, webdevs reinvent the wheel, except - as usual - it's actually less versatile than previous wheels from decades ago.
- andybak 3y ago
  The wheel in this case being? I'm not a web dev (particularly) and I'm watching wasm keenly.
- DarkNova6 3y ago
  If a wheel is square, it is in dire need to be reinvented.
  - doublerabbit 3y ago
    But if that square wheel hovers, does it need reinventing?
- gumballindie 3y ago
  I'm sorry, are you telling me there will be more work needed for achieving the same thing that could have been achieved using plain HTML, CSS and JS? Are you telling me I will need to print more invoices and sell more training? Don't threaten me with a good time. I'll fork a wasm lib make a few changes rename it and put it on my CV. That's how the webdev world has been working for over a decade now. Oh I'l also misuse some design patterns and other plausible sounding "engineering" practices to make it look cool.
  - ivanmontillam 3y ago
    > Are you telling me I will need to print more invoices and sell more training? Push the boundary too hard (as an industry) and I'm pretty sure we'll go back to the dark ages of desktop apps. I miss Delphi so much sometimes! > I'm sorry, are you telling me there will be more work needed for achieving the same thing that could have been achieved using plain HTML, CSS and JS? I also never understood why junior Web Devs prefer to write a ton of React code, when there are obscure frameworks that have a Qt-like API. Consider this Qooxdoo[0] code: var win = new qx.ui.window.Window("First Window"); win.setWidth(300); win.setHeight(200); win.setShowMinimize(false); this.getRoot().add(win, {left:20, top:20}); win.open(); I don't quite understand the JSX hype. -- [0]: https://qooxdoo.org/qxl.playground/#Window-ria https://qooxdoo.org/qxl.playground/#Window-ria
troupo 3y ago
It's a meh deal. They should've stuck with "this is crossplatform bytecode for the web", and it would've flourished there. Instead, now it's "designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." [1] Servers! Applications! Tigers! Lions! Oh my! And it's not particularly good, or effective, or performant at any of those. [1] https://webassembly.org https://webassembly.org
ivanmontillam 3y ago
I'm rooting for WASM to win. One of the things that discouraged me from Front-end Web Development is JavaScript weirdness. It just has too many pitfalls and it's very hard to debug for a newcomer unless you study a proper JS course that tells you precisely all of these traps before you get burned. I've never found a programming language that didn't behave like I expected it on first touch, except for JS. I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS. I know transpilers avoid many of these pitfalls, but I cannot avoid feeling like I'm building a skyscraper in quicksand. The hard thing about talking about this exact topic it's that I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Let me be clear this is not my intention. I come from the static-typed programming languages world, so I have a preference for my programming to be the most correct. WASM to me provides this solid foundation, if only (big IF) we manage to create a browser where the main execution virtual machine is not a JS one. I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly. For instance, why'd be too hard to think about something like HTML/CSS/Python?[0] JS has been a discourager to me career-wise, and I'm doing great in Back-end Web Dev, but I'm pretty sure I'm not the only one feeling this way about it. The web should be more accessible in this sense. -- [0]: I am aware of the existence of Brython: https://brython.info/ https://brython.info/, but it's not my point, that is still Python-over-JS.
- Tade0 3y ago
  > I've never found a programming language that didn't behave like I expected it on first touch, except for JS. Can you share some examples?
  - ivanmontillam 3y ago
    Happy to! - https://jsisweird.com/ https://jsisweird.com/
    - rantallion 3y ago
jalapenos 3y ago
In my company we're using wasm to accomplish some powerful things that would otherwise need the server to handle. I think for that reason wasm will win. Outsource your compute to your users.
euroderf 3y ago
Doesn't it make sense (for control freaks, at least) to load a WASM kickstarter into the browser and then get a handle to the DOM and go to work creating the UI ? Or is this already being done ?
greybox 3y ago
I worry that WASM will make it a LOT easier to DRM web content, even making things like copying text difficult. This will have a detrimental effect on third party tools and plugins like accessibility tools and ad blockers. True, you can already do this with canvas & plain JS, but more obfuscation will make everything worse. Eventually we won't be able to browse even the simplest websites without executing JS(wasm). That being said, I'm all for making things run faster. But I doubt it will actually benefit users in the long run. Web companies will just run more ads/tracking/AI Learning on peoples machines, making things slow again.
tlh 3y ago
At first it will feel like it doesn't matter. Then it will feel like it's all that matters. Then it will feel like it sometimes matters.
dmytroi 3y ago
WASM itself is likely to be successful in some niches, the industry has a know-how for bytecode VM's and integration with LLVM will make it stick for a long while. My bet are computation kernels for web, and porting whole native apps to web browsers via emscripten. WASI is probably doomed to fail, so far it was proven to be challenging to make "write once run everywhere" API, for example it's difficult to abstract over epoll vs IOCP vs io_uring without reinventing libuv, but making a standard out of libuv API will make adopting any platform changes too slow, because of losing control over the implementation of the API. Having a single standard implementation where the industry is collaborating might be a better way, similar to how .NET is an abstraction over platform API.
posix86 3y ago
Is WASM really incresing efficiency in the browser? Apart from avoiding garbage collection, I think in terms of performance there's little advantage. JS is incredibly fast nowadays. But I also don't think it diminishes WASM's value on the web. It will allow us to drop JS for good, at last.
thecosmicfrog 3y ago
WASM is used to package add-ons for Microsoft Flight Simulator, which I've always found an interesting example of WASM in a non-web context. https://docs.flightsimulator.com/html/Programming_Tools/WASM/WebAssembly.htm https://docs.flightsimulator.com/html/Programming_Tools/WASM...
- gte525u 3y ago
  This is the killer use-case outside of the web. Embedding untrusted/semi-trusted code into a bigger application or runtime and exposing a specific API to it.
vgchh 3y ago
Does anyone know where is official golang in its support for WASM? Last time I checked you had to use a fork of Go called TinyGo.
iainctduncan 3y ago
I do music programming and it's a huge deal. I am able to run my domain model in a WASM embedded Scheme interpreter, enabling me to reuse code from other computer music projects (Scheme for Max, Common Music, etc). I have a C++ worklet running regular C++ DSP code so i can use anything from that world. And I've made a sample accurate scheduler that can drive the main thread from a worklet (of course like any block rendering system, it has a vector of samples of jitter, but long term it stays as accurate as the sample clock). Getting all this to work was ... laborious. The debugging situation for worklets is pretty painful at the moment... it's more like writing microcontroller code than normal desktop. But that will improve, and being able to do it all in the browser such that the guts of my work can be reused across browsers, Max, or stand alone C++ is huge for me. I think WASM will really take off when we get proper browser API access direct from WASM. Right now the passing back and forth to the JS host adds a lot of work.
JustLurking2022 3y ago
While it's definitely interesting, I do wonder to what extent WASM threatens the open web even more than the DRM battles of the past, perhaps in non-obvious ways. I'm the past, one of the ways many a frontend dev has picked up tricks was simply by reading the JavaScript for a site they liked. That can be made harder by obfuscation but, even then, a prettyfier can make things generally intelligible. That exchange of knowledge was possible because a) for all it's warts, JavaScript became the standard for everyone in the field and b) the only way to publish your work was to publish the source (at least a derivative). WASM blows away both of those assumptions and takes us in a direction more similar to desktop software, where you may have a copy of the binary but may not even (easily) determine which language it was written in.
turbo_fart 3y ago
Lots of people commenting here who worked on JavaScript projects years ago and still think that Typescript is optional and that Babel/webpack needed. This stuff has been fixed with ts and, ESM in the browser.
Kiuhrly 3y ago
Another point I haven't seen mentioned much: WASM (in theory, and not including some modern extensions) has perfect, cross-platform, cross-architecture determinism. It's niche but I think it's very interesting. For example, I've toyed with the idea of creating a game which runs its logic/simulation entirely in WASM with the only input being the controller/keyboard inputs. That way you can create perfectly reproducable replays which could be used for racing games or timed platform games similar to Mario Maker. Then your leaderboard of best times can be properly verified (not accounting for manufactured/edited replays similar to TASs, Tool Assisted Speedruns). You could take it a step further and include previous versions of the game simulation WASM to get backwards replay compatibility, which is also uncommon in games.

115 points by elorant 3y ago

> Does that sound familiar? It should, you could use that same description for containers The reminds me of java but with native web browser support instead of applets.

coffeebeqn 3y ago
This has all happened before. Java web things, Flash, etc. they all have the same problem that they don’t fit in with semantic web content
- zdragnar 3y ago
  That's not why those things died, though. They died because smartphones stopped supporting them, and that combined with advancements in JS engine speed were all it took to get brother vendors to scrap the buggy, security-hole-ridden plugin ecosystem. WASM should hopefully not be bad from a security perspective, but the up-front performance penalty of early demos in downloading megabytes for hello world was painful. More purpose-fit, smaller modules ought to be broadly useful but I'll not be holding my breath. Anything that needs to take over a canvas probably isn't going to be widely adopted outside of some niche things like visual design tools or the occasional game.
  - tcfhgj 3y ago
    Megabytes are certainly an exaggeration, see 285.4 KB for Leptos
    - lelanthran 3y ago
      >> the up-front performance penalty of early demos in downloading megabytes for hello world was painful. > Megabytes are certainly an exaggeration, see 285.4 KB for Leptos Those early demos were certainly quite large. I don't think that I found any early demo of WASM to be under a megabyte, for sometimes quite trivial things.
- paulgb 3y ago
  Flash and Java Applets both owned a rectangle of the screen. Wasm interacts with the page just like JS does. So in contrast to Flash and Java, Wasm fits in with semantic web content to the same extent that JS does.
  - throwaway847599 3y ago
    Java applets could access the DOM and even run Javascript functions.
    - paulgb 3y ago
      Sure, but presumably the ones that “don’t fit in semantic web content” is a reference to the ones that rendered a portion of the page in Java, otherwise the same could be said about JavaScript.
  - jeroenhd 3y ago
    As you can read in the various comments on here, that's also the model many WASM fans are going for. Google Docs switched to rendering a full screen canvas rather than using the DOM, and Flutter/Compose do the exact same thing. WASM is very much heading in the direction of owning a rectangle on the screen. Plus, Java and Flash embeds could also call Javascript callbacks while leveraging the improved performance of their native plugins.
    - paulgb 3y ago
      Google Docs doesn’t use Wasm, from what I can tell. The move towards using canvas/gl/webgpu over DOM for performance is orthogonal to using Wasm. They go together nicely, but if you’re worried about DOM being replaced, Docs is a good example of how that will happen with or without Wasm. Another pattern I’ve seen is to render DOM on top of a canvas, with UI elements done in the DOM, and high-performance graphics on the canvas. This seems to be a good balance. https://x.com/paulgb/status/1688919428740816896?s=46 https://x.com/paulgb/status/1688919428740816896?s=46
  - troupo 3y ago
paulddraper 3y ago
That, but without the proprietary UI
- lmm 3y ago
  Tclets were fully open source and Java applets were mostly open source. It doesn't seem to have helped.
  - paulddraper 3y ago
    Perhaps I should say non-standard/non-native. Java applets used Java Swing UI
    - lmm 3y ago
      Most WASM applications use extremely non-native UI elements.
    - pvg 3y ago
      Applets pre-dated and didn't depend on Swing. But even native UI in the middle of a web-page looked non-native.
intrasight 3y ago
I was sure that "Does that sound familiar" would be followed by the history of Java. There's no VM in Docker.
- pjmlp 3y ago
  WASM Runtime...
  - intrasight 3y ago
    That new tech. The article quote was referring to Docker pre-WASM.
    - pjmlp 3y ago
      What article? Docker needs a WASM runtime regardless. Some magic incantation has to change those bytecodes into executable code.

CottonMcKnight 3y ago

It's pretty objectively a big deal. (Feature-limited) Photoshop was ported to WASM in 2021. https://web.dev/ps-on-the-web/ https://web.dev/ps-on-the-web/ With the deprecation and imminent removal of WebSQL, the official (Google) recommendation for SQL-in-browser is WASM SQLite. https://sqlite.org/wasm/doc/trunk/index.md https://sqlite.org/wasm/doc/trunk/index.md

Kiuhrly1 3y ago
For the web and other use cases where it is embedded in another program (e.g. sandboxed plugins, other places where Lua or similar would've gone previously), I think yes. But I really don't see something like WASI or WASM servers sticking around, especially because it still has a noticeable performance penalty compared to native (can't source this right now, need to sleep)
zdragnar 3y ago
Say what? WebSQL was an experiment that ended up being replaced by indexeddb- it has been deprecated ever since, and was never part of the web standards.
- CottonMcKnight 3y ago
  It has been deprecated for a long time but still available in Chromium. It is being removed in Chromium 119 at the end of next month. See the aside about SQLite WASM on this blog post. https://developer.chrome.com/blog/deprecating-web-sql/ https://developer.chrome.com/blog/deprecating-web-sql/
- afavour 3y ago
  It’s telling that despite IndexedDB being around forever people would still rather download an entire SQLite runtime than use it. A deeply unsatisfying API.
  - smashed 3y ago
    If I remember correctly, the main argument against web sql was that it really was just SQLite disguised as a web standard. I.e. there was a single implementation which defined the spec: SQLite. Every browser implementation relied on it. In retrospect, with the chrome monoculture we have today, this seems like a silly argument but at the time it was a legitimate concern.

irrational 3y ago

I judge things by how they affect me right now. Right now it is not a big deal. As a web developer I haven’t had a need for it and don’t anticipate a need for it any time in the near future. If I need to use it at some point in the future, maybe it will be a big deal.

crubier 3y ago
"If it's not a big deal now it's not a big deal now, and if it's a big deal in the future then it will be a big deal in the future" is not adding as much to the conversation as you think it is. The point of HN is in large part about thinking about the future and not just look about how things are just "right now". There is no point discussing the impact that things have right now, we can just measure it.
- MBCook 3y ago
  But it’s not new. It’s been around for years. And I’m not really aware of any real uses on the web. Other people in these comments have mentioned using it as an extension mechanism to other applications. That’s nice. But what browsers use it internally? What popular JS/TS libraries? What big websites? It seems Figma does, but I had to Google to find that. It’s an interesting idea, but it feels a bit like VRML or something else so far. “It’s going to take off, just give it time.” Some things will. Some won’t. But WASM doesn’t seem to provide enough above JS to overcome the “we can just use JS” hurdle for the vast majority of uses so far.
  - tbrownaw 3y ago
    I believe blazor (dotnet in the browser) is built on it.
paulgb 3y ago
Web (site) developers will likely never have to learn Wasm if they don’t want to. But people are increase shipping regular application software to the browser as if it’s an OS. Technically you could say the developers of these apps are “web developers”, but the stack is increasingly diverging from the stack a web (site) developer would need to care about: Wasm, WebGPU, OPFS, etc.

julianeon 3y ago

The tl;dr seems to be it’s a big deal if you need game console like performance in your browser. Want to mock up designs there? You need WASM. But if your answer is “I’m building a SaaS, I don’t need incredible cutting edge performance” - it seems less necessary.

ajhurliman 3y ago
Definitely. CAD in the browser? WASM. High-end photographic computation in the browser? WASM. Pretty much everything else… not WASM

refulgentis 3y ago

"For example, Python has become the quick, easy way for people to work with machine learning programs – thank you, PyTorch. But you can't simply drop these programs into WASM in a runtime and expect them to work. The problem is that you also need many third-party dependencies, which aren't there yet." Yes you can, ONNX. Yeah, it's not _literally Pytorch_. But it takes about 10 minutes.

pizzafeelsright 3y ago

Huge. I've been a Chrome OS user for a decade. I no longer worry about the OS, files, or versions. This is great. What we do need is the ability to build the UX locally outside the confines of the browser outside of the existing OS. The idea that files can share user space with other files without explicit permission always felt off.

dhosek 3y ago

Where I see this as a huge deal is for plug-in development. For finl, I was looking at the possibility of incorporating an interpreter for JavaScript or Python or Lua. Instead, I can create bindings for WASM and get a sandboxed environment for people to write their own extensions. There will be some packaging tools that I’ll want to provide (the idea being that a user specifies something like \LoadExtension{yoyodyne:csv-reader:1.0} to bring in an extension and if there isn’t a local copy of the extension, it will fetch it from a repository, and I’ll want to bundle a bunch of stuff into a standard ZIP file layout (so that documentation, etc. will be easily fetched). The list of languages that can compile to WASM increases on a regular basis and it seems by far the best route for plugin handling in a greenfield project.

bhelx 3y ago
I work on a project for building such plug-in systems. We have a wide variety of languages supported https://extism.org/ https://extism.org/ > and I’ll want to bundle a bunch of stuff into a standard ZIP file layout (so that documentation, etc. will be easily fetched I've always, thought it would be cool if Wasm runtimes had a generic supported format for this. Kind of like a Java JAR. But of course, you can implement a custom version for application pretty easily.
- pjmlp 3y ago
  Like CLR plugins....
flutetornado 3y ago
Yes, on a related note Neovim just got support for WASM plugins and apparently WASM is 100% faster than Lua (neovim's default plugin language runtime) for this use case according to the author. So now plugins in any language that can be compiled to WASM are possible. Edit: https://github.com/Borwe/wasm_nvim https://github.com/Borwe/wasm_nvim
- pjmlp 3y ago
  No wonder, since Lua is interpreted and not a fast one at it, unless LuaJIT comes into the picture.

diego_moita 3y ago

It is a reasonable big deal in the niche of computation intensive applications. It would be an huge deal or revolution if it could perform faster on plain DOM manipulation. By now, plain Javascript is faster than WASM [0]. That's because all WASM's DOM manipulation must go through the Javascript engine and many browsers do JIT compilation on Javascript. Edit: be aware that the article has a more interesting discussion on WASM on the server side, as a replacement of technologies such as Docker/containers, Java Virtual Machine and .Net. [0] https://krausest.github.io/js-framework-benchmark/2023/table_chrome_116.0.5845.82.html https://krausest.github.io/js-framework-benchmark/2023/table...

dclowd9901 3y ago
A WASM-powered virtual DOM with painting privileges seems all but ascertained given the general direction Mozilla and other interested parties are taking the environment. Include the bubble/capture phases and you’re completely there.
- satvikpendem 3y ago
  Indeed, I posted this in a sibling comment but this is exactly the future that will arrive: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 The browser will be the unified runtime for WASM apps, native level performance with the linkability and other advantages of the browser.
satvikpendem 3y ago
Unless you don't use the DOM at all for UI for web apps: https://news.ycombinator.com/item?id=34612696 https://news.ycombinator.com/item?id=34612696 It would enable any language to simply render their own UI and handle things like accessibility with their own accessibility based DOM that just handles the accessibility parts rather than the entire logic of the app. I believe this is what Flutter does.
- pavlov 3y ago
  This means shipping an entire UI framework as part of the web app onto a computer that already is running multiple UI frameworks. For example on macOS with Chrome, you’ll have Flutter running on Chromium running on AppKit. All of these provide text layout engines, compositors, 2D and 3D graphics, widget hierarchies, scripting languages… Hundreds of megabytes of redundant stuff loaded in memory to run some typically basic Flutter app. I know, we can’t magically have native binaries delivered on the web (that was ActiveX and it was bad). But it somehow boggles the mind that this is what we ended up with.

singularity2001 3y ago

WASM may live up to its promise when they finally fix js/dom interop. Looks like it's indefinitely postponed though. so we are stuck with ungodly glue calling between it and JavaScript (which is unavoidable if you want to do much with it), incredibly hacky.

tcfhgj 3y ago
Frameworks like Leptos and Dioxus abstract that glue calling away and you still get better performance than most JS frameworks

mikewarot 3y ago

In the beginning, there were incompatible microprocessors, so p-code was widely deployed to avoid having to write the same Pascal compiler over and over on every platform, but it was slow because it was interpreted, but even worse was that it tended to crash. Later, the Java VM was created, to avoid rewriting the same code over on every platform, but it was slow because it was interpreted, but thanks to JIT, that was pretty much taken care of. The main problem then became the fact that it, like ActiveX before it (which wasn't cross-platform), got general access to the file system, and could never really be safely used. It remains to be seen if WASM/WASI retain their commitment to capability based security, which is at this point the main selling point. There have now been fast cross platform systems, but this is the first that builds in capabilities, and doesn't give general access to the file system. Analogy #1 - We need such a system... it's like power in a home... with a circuit breaker, and the promise that you're only going to get 15 amps, not all of the power of the grid, flowing to anything you plug in. Analogy #2 - It's like cash in a wallet, you decide how much to hand over to an untrusted partner in a transaction. You should be able to decide what files/folders to hand to a program, and know it won't get anything more than that. Analogy #3 - The IBM PC XT with twin floppy disks was the most secure general purpose computer of its time, and still is. You had control over your data, full and transparent control, because you decided what the allowable side effects were when you decided what disks to let it access, and also if they were read-only or writeable. You can't do that today.

pjmlp 3y ago
You missed the history before Pascal came to be, P-Code wasn't the first. Burroughs in 1961 was already bytecode based, all Xerox PARC systems used bytecode, as did several other systems. Pascal P-Code might be one of the most famous ones, however there plenty others to learn from.
- mikewarot 3y ago
  I also deliberately left out the phase change that was caused by IBM including 1401 Emulation in System 360. Before that, everyone rewrote their programs every time a new machine came out, because it was expected it would be incompatible with the old one, so we have a ton of code still running that wasn't expected to last more than 10 years when it was written, in the late 1950s, early 1960s.

eternityforest 3y ago

I'm kind of afraid of this. When it gets DOM and drawing abilities, People are gonna build SO many things of varying levels of quality, from scratch, that probably could have been done with existing JS frameworks, don't work well with browser features, require learning 583 languages to work on anything, etc. It will be amazing for compute heavy stuff in the browser I'd imagine. Cross platform assembly is a super cool idea. If they can get it right at least we might have something besides a container that runs anywhere. I'm just not sure I want them to mess with JS/HTML based UI just when it was really getting awesome and declarative was becoming standard... And since web devs like. Making stuff harder than it needs to be they might...

pjmlp 3y ago

Little deal. Plenty of WASM advocates act ad if we haven't had endless attempts at since the 1960's. Also doing kubernetes with WASM containers must be a bad joke, when comparing how managing Websphere 5 in 2005 was so much easier. On the browser side, it is a convoluted experience versus using Flash/Code Alchemy, Java Applets, Silverlight, with Blazor/Flutter being the only ones that somehow come close to how it used to be 15 years ago.

DarkNova6 3y ago
You are comparing an open, non-proprietary compile target to a closed ecosystem. Admittedly, WASM is making slow progress (much to it due to Google actively/passively sabotaging it) but it is the closest we have got to a universal compile target. In particular, the combination with Rust could be a game changer and make whole categories of DSLs obsolete. It also has the potential to open FE work for people which categorically refuse to work with the mess that is the JS ecosystem.
- giancarlostoro 3y ago
  Got any examples of Google sabotaging WASM? First I have heard of this. I thought Apple was kind of since they seem to adopt some things somewhat slow or not at all.
  - jamil7 3y ago
    WebKit has had a WASM implementation since 2017, the same as Chrome and Firefox as far as I know.
    - callahad 3y ago
      We all (Mozilla/Google/Microsoft/Apple) announced consensus for the WebAssembly MVP on February 28, 2017. Mozilla and Google shipped on-by-default in March, Apple in September, and Microsoft in October.
  - brabel 3y ago

meindnoch 3y ago

As usual, webdevs reinvent the wheel, except - as usual - it's actually less versatile than previous wheels from decades ago.

andybak 3y ago
The wheel in this case being? I'm not a web dev (particularly) and I'm watching wasm keenly.
DarkNova6 3y ago
If a wheel is square, it is in dire need to be reinvented.
- doublerabbit 3y ago
  But if that square wheel hovers, does it need reinventing?
gumballindie 3y ago
I'm sorry, are you telling me there will be more work needed for achieving the same thing that could have been achieved using plain HTML, CSS and JS? Are you telling me I will need to print more invoices and sell more training? Don't threaten me with a good time. I'll fork a wasm lib make a few changes rename it and put it on my CV. That's how the webdev world has been working for over a decade now. Oh I'l also misuse some design patterns and other plausible sounding "engineering" practices to make it look cool.
- ivanmontillam 3y ago
  > Are you telling me I will need to print more invoices and sell more training? Push the boundary too hard (as an industry) and I'm pretty sure we'll go back to the dark ages of desktop apps. I miss Delphi so much sometimes! > I'm sorry, are you telling me there will be more work needed for achieving the same thing that could have been achieved using plain HTML, CSS and JS? I also never understood why junior Web Devs prefer to write a ton of React code, when there are obscure frameworks that have a Qt-like API. Consider this Qooxdoo[0] code: var win = new qx.ui.window.Window("First Window"); win.setWidth(300); win.setHeight(200); win.setShowMinimize(false); this.getRoot().add(win, {left:20, top:20}); win.open(); I don't quite understand the JSX hype. -- [0]: https://qooxdoo.org/qxl.playground/#Window-ria https://qooxdoo.org/qxl.playground/#Window-ria

troupo 3y ago

It's a meh deal. They should've stuck with "this is crossplatform bytecode for the web", and it would've flourished there. Instead, now it's "designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." [1] Servers! Applications! Tigers! Lions! Oh my! And it's not particularly good, or effective, or performant at any of those. [1] https://webassembly.org https://webassembly.org

ivanmontillam 3y ago

I'm rooting for WASM to win. One of the things that discouraged me from Front-end Web Development is JavaScript weirdness. It just has too many pitfalls and it's very hard to debug for a newcomer unless you study a proper JS course that tells you precisely all of these traps before you get burned. I've never found a programming language that didn't behave like I expected it on first touch, except for JS. I am fully aware TypeScript exists, and there are transpilers where the syntax (modern ECMAScript) and rules are more appropriate to current times, but these aren't "native" of the browser. You must still transpile to the hazardous old JS. I know transpilers avoid many of these pitfalls, but I cannot avoid feeling like I'm building a skyscraper in quicksand. The hard thing about talking about this exact topic it's that I'm sure my comment will trigger negatively a ton of developers, because talking about JS like this it's going to feel like I've insulted a cult. Let me be clear this is not my intention. I come from the static-typed programming languages world, so I have a preference for my programming to be the most correct. WASM to me provides this solid foundation, if only (big IF) we manage to create a browser where the main execution virtual machine is not a JS one. I've dreamed of a browser that supports multiple stacks, instead of the HTML/CSS/JS monopoly. For instance, why'd be too hard to think about something like HTML/CSS/Python?[0] JS has been a discourager to me career-wise, and I'm doing great in Back-end Web Dev, but I'm pretty sure I'm not the only one feeling this way about it. The web should be more accessible in this sense. -- [0]: I am aware of the existence of Brython: https://brython.info/ https://brython.info/, but it's not my point, that is still Python-over-JS.

Tade0 3y ago
> I've never found a programming language that didn't behave like I expected it on first touch, except for JS. Can you share some examples?
- ivanmontillam 3y ago
  Happy to! - https://jsisweird.com/ https://jsisweird.com/
  - rantallion 3y ago

jalapenos 3y ago

In my company we're using wasm to accomplish some powerful things that would otherwise need the server to handle. I think for that reason wasm will win. Outsource your compute to your users.

euroderf 3y ago

Doesn't it make sense (for control freaks, at least) to load a WASM kickstarter into the browser and then get a handle to the DOM and go to work creating the UI ? Or is this already being done ?

greybox 3y ago

I worry that WASM will make it a LOT easier to DRM web content, even making things like copying text difficult. This will have a detrimental effect on third party tools and plugins like accessibility tools and ad blockers. True, you can already do this with canvas & plain JS, but more obfuscation will make everything worse. Eventually we won't be able to browse even the simplest websites without executing JS(wasm). That being said, I'm all for making things run faster. But I doubt it will actually benefit users in the long run. Web companies will just run more ads/tracking/AI Learning on peoples machines, making things slow again.

tlh 3y ago

At first it will feel like it doesn't matter. Then it will feel like it's all that matters. Then it will feel like it sometimes matters.

dmytroi 3y ago

WASM itself is likely to be successful in some niches, the industry has a know-how for bytecode VM's and integration with LLVM will make it stick for a long while. My bet are computation kernels for web, and porting whole native apps to web browsers via emscripten. WASI is probably doomed to fail, so far it was proven to be challenging to make "write once run everywhere" API, for example it's difficult to abstract over epoll vs IOCP vs io_uring without reinventing libuv, but making a standard out of libuv API will make adopting any platform changes too slow, because of losing control over the implementation of the API. Having a single standard implementation where the industry is collaborating might be a better way, similar to how .NET is an abstraction over platform API.

posix86 3y ago

Is WASM really incresing efficiency in the browser? Apart from avoiding garbage collection, I think in terms of performance there's little advantage. JS is incredibly fast nowadays. But I also don't think it diminishes WASM's value on the web. It will allow us to drop JS for good, at last.

thecosmicfrog 3y ago

WASM is used to package add-ons for Microsoft Flight Simulator, which I've always found an interesting example of WASM in a non-web context. https://docs.flightsimulator.com/html/Programming_Tools/WASM/WebAssembly.htm https://docs.flightsimulator.com/html/Programming_Tools/WASM...

gte525u 3y ago
This is the killer use-case outside of the web. Embedding untrusted/semi-trusted code into a bigger application or runtime and exposing a specific API to it.

vgchh 3y ago

Does anyone know where is official golang in its support for WASM? Last time I checked you had to use a fork of Go called TinyGo.

iainctduncan 3y ago

I do music programming and it's a huge deal. I am able to run my domain model in a WASM embedded Scheme interpreter, enabling me to reuse code from other computer music projects (Scheme for Max, Common Music, etc). I have a C++ worklet running regular C++ DSP code so i can use anything from that world. And I've made a sample accurate scheduler that can drive the main thread from a worklet (of course like any block rendering system, it has a vector of samples of jitter, but long term it stays as accurate as the sample clock). Getting all this to work was ... laborious. The debugging situation for worklets is pretty painful at the moment... it's more like writing microcontroller code than normal desktop. But that will improve, and being able to do it all in the browser such that the guts of my work can be reused across browsers, Max, or stand alone C++ is huge for me. I think WASM will really take off when we get proper browser API access direct from WASM. Right now the passing back and forth to the JS host adds a lot of work.

JustLurking2022 3y ago

While it's definitely interesting, I do wonder to what extent WASM threatens the open web even more than the DRM battles of the past, perhaps in non-obvious ways. I'm the past, one of the ways many a frontend dev has picked up tricks was simply by reading the JavaScript for a site they liked. That can be made harder by obfuscation but, even then, a prettyfier can make things generally intelligible. That exchange of knowledge was possible because a) for all it's warts, JavaScript became the standard for everyone in the field and b) the only way to publish your work was to publish the source (at least a derivative). WASM blows away both of those assumptions and takes us in a direction more similar to desktop software, where you may have a copy of the binary but may not even (easily) determine which language it was written in.

turbo_fart 3y ago

Lots of people commenting here who worked on JavaScript projects years ago and still think that Typescript is optional and that Babel/webpack needed. This stuff has been fixed with ts and, ESM in the browser.

Kiuhrly 3y ago

Another point I haven't seen mentioned much: WASM (in theory, and not including some modern extensions) has perfect, cross-platform, cross-architecture determinism. It's niche but I think it's very interesting. For example, I've toyed with the idea of creating a game which runs its logic/simulation entirely in WASM with the only input being the controller/keyboard inputs. That way you can create perfectly reproducable replays which could be used for racing games or timed platform games similar to Mario Maker. Then your leaderboard of best times can be properly verified (not accounting for manufactured/edited replays similar to TASs, Tool Assisted Speedruns). You could take it a step further and include previous versions of the game simulation WASM to get backwards replay compatibility, which is also uncommon in games.