Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times.
WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its architecture Java allowed as a) reflection (JS to Java calls) as b) exposure of DOM model into Java execution space - DOM API even now is defined in terms of Java interfaces by the way.
WebAssembly is a step in right direction but the evolution looks as Waltz - two steps forward two steps back with the twist.
Now we are able to run ray tracers compiled to WA on browser side but we've lost an option to apply the results to DOM elements directly.
JVM is seriously more complex and heavier-weight. It does too much, and is shaped by Java the language too much (no functions, only objects!). It brings in mandatory GC. It's built around shared mutable data.
WA is much smaller, assumes way less, is isolated from DOM and JS code way better, communicates with them via message-passing. It has a smaller attack surface, and less room to screw up in the implementation.
Yes, I think not having WA married to DOM is a good idea from many angles. One of them is security, of course. Another is wider applicability: a WA VM could be useful outside the browser, and it already is.
Does anyone have any good success stories with WebAssembly in the actual context of using it on the web? That list of testimonials doesn't seem very inspiring as to whether or not the standard has seen actual production usage to justify being a recommended standard...
That looks awesome! I noticed that you don't have Game Boy on there, not sure if it's useful to you but I started to make a WebAssembly port of GBDK: https://github.com/chrismaltby/gbdk-emscripten which I was planning to use in my Game Boy game maker eventually https://www.gbstudio.dev/
Thanks -- we use Emscripten/WASM mainly for running command-line compilers/assemblers (like cc65 and SDCC).
Right now the emulators are all in JavaScript (except for MAME) which makes integrating with the IDE's debugging tools a little easier. It's performant enough for now, since we only have 8-bit platforms at low clock speeds.
Integrating a C emulation library like https://github.com/floooh/chips should be doable, since it doesn't have any dependencies.
MESS/MAME can be compiled to WebAssembly now. You can emulate arcade games and whole computer systems in the browser. E.g. https://archive.org/details/win3_TemIM3x (Press the big play button)
There are some very cool demos, such as running Doom 3 in the browser [0], but as for actual good success stories, I'd be willing to bet that many teams just haven't seriously considered it for large or involved projects due to it not yet being fully supported everywhere, not an official W3C recommendation (at the time), etc.
We use it for the end-to-end encryption implementation in Riot.im on Web; from memory it sped up the asm.js emscripten based implementation by a factor of about 3x, and also is a (slight) improvement in terms of risk of timing attacks.
I've been developing a WebAssembly image processing library, and its performance has greatly surpassed JavaScript's, allowing for much faster and more performant image processing on the web.
I'm excited to see how I can improve upon it in the future, and make it even faster! It's on GitHub here, any feature requests or suggested improvements would be greatly appreciated too: https://github.com/silvia-odwyer/photon
We currently use wasm on the Adobe XD team for rendering shared prototypes in the browser. It allows us to share C++ rendering code across desktop and web and has been a massive success for us.
The browser support is good enough for our customer base, as it works across all operating systems and mobile devices, and we can fall back for asm.js for IE11.
I think this speaks of huge potential, not actual success. I'm really, really hopeful that blazor becomes something real with long-term committment but not fully convinced yet it's not the new silverlight. I hope these fears are unfounded but hesitant to go all-in as a first mover. W3C support is a positive step.
Some more detail: Emscripten has defaulted to emit wasm even earlier, in May 2018. The change this year was to switch how that wasm is emitted, from the old fastcomp+asm2wasm path to the new LLVM wasm backend.
Not sure if this is what you’re looking for but I’m using it to embed SQLite in an app that’s both desktop (electron) and web-kinda-sorta. I say kinda-sorta because really what we’re doing is embed SQLite (and other dependencies) in an html page so our users can just open it straight up in a browser without having to be online or connected to any other systems, and still able to work (albeit read only for now.) The download time doesn’t matter to our users (and more often than not the file is loaded from a local file: url anyway) and the startup time is not spectacular but sub-second at most currently, so we’re happy so far.
Except for some noob mistakes when implementing the PoC it’s worked remarkably well, much better than I though it would.
The decision to embed SQLite had more to do with query capabilities than storage. We need to expose a query interface that is both flexible and powerful, and ideally it’s not something esoteric. We need something BAs can pick up without much or any additional training. With SQLite we both get the query engine and storage, but really it’s the former that’s important. While it may have started as a “what if” kind of PoC I think it’s gonna stick, unless we can find something that essentially gives us SQL the query language (superset is fine, subset not so much) and whatever storage backend is available, be it IndexedDB or something else. We tried various options, like AlaSQL and others, but embedding SQLite was pretty painless and gives a lot of bang for the buck.
The only downside so far is that the embedded size is quite large, so we do take a small hit in startup latency (sub second still) and if we ever end up having a requirement to work across the internet (I doubt it) it’s going to hurt because we’d be looking at a 3mb+ download (quite cacheable though.)
Anyway, point is our need was mainly SQL the language and not so much the storage, that’s kind of secondary, though SQLite really makes that part easy too.
The thing is, I can't/don't disagree with you, in terms of arguing for SQLite over alternatives. Hearing the practical specifics of your edge case is (depressingly) insightful.
Potentially interestingly, I re-found the link above via hn.algola.com, which also found me the comments (for the only time the above link was posted), at https://news.ycombinator.com/item?id=7661236. The top comment thread there points to https://github.com/kripken/sql.js, which was started pre-WebAssembly but now builds for WASM, and the network tab in devtools is telling me it's a 497KB download. It says it takes the position of providing a first-class JavaScript API instead of C bindings, and that you have to implement your own save/load<->import/export layer. You may have already discovered and discarded this possibility.
FWIW, if using SQLite does stick, I reckon that an article (even a small one) about the journey/decision process/implementation gotchas/etc - and particularly details about the use cases, and why SQLite shines for your scenario - would probably be received very positively.
Thanks for replying! (My fast response time was due to fun timing: I literally just opened my laptop this morning, checked HN, and saw your comment posted "0 minutes ago" :D)
Still working on this myself, but I'm using wasm to allow usage of a Rust library for parsing Rocket League replay files. I already had a binary utility that I could share with people who needed it, but it's a lot easily to just send them to a webpage where they upload their files and get a downloadable csv output.
I work on a project that has used it in a few places such as: running graphviz in the browser, and using various cryptography libraries cross compiled from C in the browser. In my experience it's early days still. Tooling is fragile and runtime memory management rudimentary.
Good questions. WASM at this point seems more a locus of JS hate than anything practical. To create something cool, novel, and useful should be the goal, not avoid or use a certain language.
There's a pretty stark difference between those working in and with WASM, and people commenting on the sidelines. Almost everyone involved with WASM itself sees it as complimentary, and explicitly is not trying to "kill javascript." Random commenters on the internet do say this a lot though.
WASM isn’t very practical yet because it isn’t fully formed. There isn’t support for DOM access or parallelism, never mind the ecosystem. It’s a really ambitious project, and writing it off as “locus of JS hate” because it hasn’t completely changed the game in such a short time frame is really short sighted. It would be a fairer test to give it 5 years.
I'm not writing it off. I think it's a good idea to bring more options to the web. I tried it last year, but as you state and I agree, it's not ready yet.
In my experience in SF I encounter many never-JSers. Being a JS fan, for certain things, I don't get the hate. So maybe I feel threatened in a way, but I'm not going around wishing for the death of python or Haskell. That's all. I am reading random internet commenters and getting slightly upset. That's on me.
I think you get that with any language. People are very attached to how they’ve learned to solve problems and the set of tradeoffs they tend to value. I like Go and I can’t tell you how often I see even outlandish criticism (for a long time on r/programming, commenting “it is impossible to build a software product in Go because the type system is too weak” was a great way to get upvotes, especially if you followed it with “but I really like <fully dynamic language>”). You just have to try to understand which parts of the criticism are valid and improve your own understanding.
I wouldn't say it's hate towards JS but I think the evolution of JS vs the evolution of web and its use cases have not increased at the same velocity, latter being faster. JS has had to have a lot of scaffolding added to increase its use but WASM now comes in with the understanding of the modern requirements. However, I don't think it's either one or the other, it'll depend on the use-case.
I can't imagine JS will go anywhere anytime soon, especially since it still needs to be called from DOM manipulation,but the ability to code a full stack in a single non-JS language and run it at near-native performance is going to be very useful as more apps become web based and complex. Even from a skills point of view, you can now have backend and front-end developers skillsets are slightly more merged so easier to swap around resources.
You’ll be happy next time you npm import something time sensitive that requires computation, and that you can just use from js for free.
Think about how you would do ML with just python. That’d be insane. And thankfully the packages you need are implemented in c or cuda with python bindings. 99% of ml people never see the insides of np, sklearn or tf. But you’re glad these aren’t implemented in python.
Similarly, you’re glad for webgl if you need to do lots of parallelizable computations (cfd, ml, 3d). But glsl was never bashing at js. Just that using js for these task isnt feasible.
Similarly, now you can use fast code from js. Essentially, you have a bunch of matrices use webgl, otherwise wasm. And orchestrate everything from js. Like ml peeps do with python, c and cuda.
Is this the same case as with HTML5 that W3C takes what WHATWG creates, stamps their "approval" and then it's the W3C that "brings new language to the Web"?
Could someone in the know shed some light in this matter?
Not really; the WebAssembly work is all done within the W3C.
Specifically, it is done within the WebAssembly Community Group (open to all), then shuffled through the WebAssembly Working Group (open to paying member companies only) for advancement through the official W3C processes. This is a reasonable process hack for getting openness within the W3C structure.
That said, the "Recommendation" stamp of approval is indeed being overblown in this article. What it practically means is:
- (Con) now there is a static "dead standard" at some https://w3.org/TR/ URL which people will treat as more official than the actual living drafts at https://webassembly.github.io/spec/, despite the living drafts being actually up to date with implementations and the dead standard existing only for patent purposes.
Developer reference documentation for Wasm can be found on MDN's WebAssembly pages. The open standards for WebAssembly are developed in a W3C Community Group (that includes representatives from all major browsers) as well as a W3C Working Group.
Off-topic, but I wish Markdown had a proper "multi line" block quote syntax like this. The current standard of ">" is open to too much interpretation around paragraph breaks. Similar to how fenced code blocks with ``` are a major improvement over prefixing the line with 4 spaces.
> because if you have multiple lines not separated by an empty line,
>
> even with a "quoted" extra line, it's not formatted on hn as such, and everything collapses into a single line.
The difference between code blocks and block quotes is that you can nest the latter. On the one hand that makes multi-line syntax even more useful. On the other it would make reading block quotes hard to follow when reading MD in plain text (then again, who still does that these days?)
The way that coding language and deployment/executable language have been tied together (JS for both) has served as a force that pushed everyone toward that single language.
Now that WebAssembly promises to remove that force, will it be a free-for-all, or will other forces push toward standardization on a few languages? And if so, what will those forces be?
To be even more specific, in the early days now, the main allure of wasm is performance. So the focus will be on languages and toolchains capable of generating optimized native code. Out of those, look at which ones are easy for the developer to set up (both in general, and for wasm) on all popular developer OSes.
So, I'd say that Rust will probably be the biggest beneficiary.
The performance angle is interesting. Right now JS has lots of mindshare and momentum for obvious reasons, so maybe the things that will take off at first are the ones that help web developers in specific areas where JS performance is not good enough, perhaps graphics for example.
There are always few languages that dominate a niche.
I imagine binary size would be a concern for web development, what is a negative for complex runtimes... But then, if I carefully set the compiler to trim dead code, my Haskell email server is smaller than any modern JS framework (still larger than a new version Jquery), so the runtime may not actually make much of a difference.
I think "native" web-tech like JavaScript & HTML will still have a lot of momentum in it. WASM is about other languages getting access to browser as a delivery platform. I wonder if language JavaScript that was originally designed to run on the web should have a competitive edge here?
The drawback of JavaScript has so far been its low execution speed, maybe WASM will make it run faster.
In other words maybe WASM will not be the downfall of JavaScript but its uplift.
It seems to me that, given the incredible number of person-years put into making Javascript fast, it's probably approaching its max speed of execution already without modifying the language itself. I'd expect the C/C++ interpreters are already using so many tricks to speed it up that remaining gains would be difficult without adding more information to the language itself (e.g. stricter typing) or modifying the way it works (fewer things represented as objects, more types of collections).
In short, I suspect the actual instructions executed when JS runs on a modern interpreter are already pretty damn close to what a fairly well-optimized JS-to-WASM compiler would provide. If you want more major gains I think you'd have to start looking at locking down (or at least providing the option to lock down, in performance-critical code) the ability of Javascript to do all kinds of wacky stuff at runtime.
It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled. Currently, JS is used as a mediator between the two - so you do need some JS (but it could well be JS that you never have to write yourself).
I recall one of the spec authors saying in an HN thread that a GC would be added eventually, back in the infancy of WA. I'm not sure if that's still on the cards or if there have been any updates on the subject.
I’m not sure I understand the advantage of having a GC in WASM. I wouldn’t expect any languages to use it (because GCs tend to be tightly coupled to a particular language—for example, go’s GC requires careful coordination between the GC and the scheduler—and any sufficiently general GC would presumably give up too much performance).
LLVM has an interface for GCs such that the host language can provide LLVM with information about what kind of code to generate at the boundary between the application and the GC, but that’s just shim code; not a full GC implementation, and even then I’m not sure of any languages that make use of it.
Even still, it’s cool to see the WASM folks trying to tackle these big tricky problems!
GC in wasm is proposed for two purposes: (1) DOM objects are garbage collected and so first-class support for them in wasm requires a GC; (2) optimal moving GC requires runtime support. A garbage collector needs to be able to walk stacks to find the root set of pointers, but the stack is hidden from the program in wasm.
I'm a web dev and I don't know much about WASM. I've been wondering - will it be possible to render something to the screen without first going through the DOM? Or is the DOM literally the only way to display content?
It's enticing to imagine being able to open a wasm file and seeing an application on the page. Kinda like how you can just open an image or a video in the browser, without rendering it via an html document.
You can take a Canvas element and draw anything you like on it - even hardware accelerated 3d using webGL. I think there are some projects trying to (re) implement a 2d user interface, rendered onto canvas.
However the issue id that you will need to reimplement a lot of things the browser already does for you: rendering text, scaling, zoom, input methods, highlighting text, accessibility features, etc...
Unless you use case is very different from normal browser usage (e.g. 3d graphics) the advantages seem dubious to me.
Mostly I was just curious, although I could see one argument for it. HTML/DOM was meant to display interactive documents, which is far smaller in scope than what browsers are used for today.
A lot of the web today (web applications in particular) are therefore hacks of HTML. I know that the standard has responded to these uses by incorporating more application-level features, but IMO this has become burdensome and bloated.
There are lots of issues coming from the fact that we're attempting to write application-level code on top of a platform that has historically been designed for documents.
You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications.
React and friends solves that problem for you. It was designed to be a UI layer for web apps. It does use the DOM at the end, but you are not managing it anymore.
I don't think the downplay of HTML/CSS (referring to it as hacks) is valid just because 30 years ago it was about document delivery. You have to start somewhere. It took a while and it made some people fed up with it, I've seen that. I still have some PTSD from hacking IE6, those were the real hacky days. Nowadays most stuff just works.
What we have as a spec is the lowest common denominator that passed the test of tons of communities and companies, and from this perspective it's incredibly successful.
It seems probable to me that some actual application GUI toolkits will target WASM+Canvas and finally give us good-looking, capable, better-performing, easy-to-work-with GUI application development in the browser, yes.
HTML's pretty bad at the use case it's been smushed into, and hacking a semi-reasonable GUI toolkit on top of it in Javascript is bound, no matter how good the effort, to be slower and less pleasant than something designed from the beginning to be used for heavily interactive application GUIs.
The two big risks I see are: 1) the tinkerer-friendliness of the Web is, very likely, going to take a big step backwards as WASM use spreads, and 2) there's a chance we'll end up with 100 different WASM GUI toolkits and they'll be super-trendy and all the job ads will demand familiarity with at least one of them, but not a single goddamn one of them will handle accessibility and various edge cases half as well as plain HTML or actual native development does (to be fair, Javascript that writes around limitations in HTML by re-implementing parts of it often has the same problem)
> You could argue for an alternative to html/DOM - some kind of rendering format that is meant specifically for full-featured applications.
Well, there are three ways to do that. You can use a 2D canvas, you can use a WebGL canvas, or you can use a bitmap canvas. This is roughly equivalent to what you get when you’re programming a desktop application anyway. This is a cornucopia of alternatives here! I’m having a hard time understanding what is missing.
These “use the DOM” in the same sense that desktop applications use the window manager. You’re just drawing into an element in some compositing system. This is fine, there’s no real benefit to bypassing the DOM—like window managers, you can bypass the compositor when possible and go through the compositor when unavoidable. This is transparent to the application programmer.
What is missing is a way for one's wasm code to make WebGL or 2D canvas calls (or even write directly into a bitmap canvas), without writing a bunch of Javascript trampoline / thunk / whatever code. If I'm mistaken, a pointer to some C / C++ / Rust code that compiles down to wasm that actually touches a canvas that's being displayed in the browser would be most appreciated.
There is currently no path for any of that. No rendering without a DOM, and no opening WASM files by themselves. The same is true for JavaScript... if you open a JavaScript file, you just see the source code.
Of course, why not just use a small HTML+JS shim for your WASM?
HTML isn't legacy cruft, it's an essential part of the web that will never go away. If you want to ship an app with no HTML, then use a different platform.
This is a generic argument that can be used against any sort of proposed improvement. “If you don’t like the status quo, use something else”. It also comes off as defensive; I’m not sure if that’s what you intended or not.
I don't think WASM is proposed as an improvement over either HTML or JS. It's proposed as an addition that fills out certain shortcomings for particular niches. WASM is not (currently) envisioned as the "new" way to write for the web, but as a handy capability to reach for if you need it.
I don't think anyone is suggesting that WASM is the new way to write for the web, but I think it's certainly an aspiration that WASM will allow more languages to be used for everyday web development in addition to solving other more niche problems.
It has not been my perception that that's an aspiration or a goal of WASM, but there's much I haven't read. Can you point me to where this is stated as one of WASM's goals?
That’s a short-term view. There’s going to be legacy cruft either way. Either we have the existing HTML + JS with WASM alongside it, or we introduce a ton of new APIs to let WASM function by itself.
Using the existing HTML + JS avoids creating as much future legacy cruft.
It's interesting that the web standardized on one programming language.
In hindsight I feel like this isn't surprising. How many platforms (that aren't themselves operating systems) support scripting in more than one language? Vim/Neovim is the only one I can think of off the top of my head.
It's easy forget these days, but Windows had this thing called Active Scripting, that was basically a set of COM-based interfaces for scripting languages to expose their functionality OS-wide, and for apps to use any scripting language available on the system. And Internet Explorer, at the peak of its popularity, used that interface to implement the <script> tag - so long as the user had some language installed on their machine, it could be used to script web pages in IE. Active Scripting came with JavaScript and VBScript supported out of the box, which is why both were available in IE. But there were quite a few third-party ones - I recall seeing Perl, Python, Tcl, and REXX.
But, of course, other browsers didn't have that. And even at the time when some websites really only cared about IE, they couldn't assume that people had any third-party runtimes installed - so you very occasionally saw VBScript, but pretty never anything else.
It doesn't seem to be in fashion these days, but some years ago language-agnostic object models for extensibility were common: Microsoft's COM, Mozilla's XPCOM, LibreOffice's UNO, IBM's SOM, etc.
Even back inn the 90s, people were thinking of the browser as a potential OS-like platform. Netscape certainly did, and that's why MS was so worried about them.
> It would be hard (maybe not impossible) to access the DOM in WA without a GC making sure everything is sound, because the DOM and JS (meaning the GC) are very coupled.
AFAIK, the reason the DOM and JS GC are very coupled is because there can be loops between the DOM and JavaScript: the DOM can hold JavaScript resources, which themselves can hold DOM resources. As long as these loops are avoided (by not allowing the DOM to hold resources within the WASM heap), this is not an issue.
Wsam has similar ideas like flash and silverlight but its more powerful and more open. At this point I think wsam and JS has their own place...will have to see how this plays out.
WASM is like the exact opposite of Flash. Flash was successful because of its ability to put things on screen. The ability to write code in it was secondary to the powerful vector graphics & animation system and the tooling around that.
Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed arrays and relying on fast JITs).
That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it).
If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surprising about the development of wasm. It's been 10+ years in the making.
And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a VM and were really unsafe and unportable). Making a portable, sandboxed bytecode solves an obvious problem with that.
I think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights.
The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it.
Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages compile to, but rather a bytecode perhaps inspired by JavaScript that will be the language of the future. Also, importantly this bytecode will win; that is most languages will the ability to directly compile to or have a VM in this bytecode.
Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance.
At least to me, neither of those were obvious insights even though I knew of these plugins and JSLinux.
First off, those plugins died. Silverlight, ActiveX, Java on the web, Flash, all of these died out and were replaced by JavaScript before wasm really took off. It might've looked like the end state would be a version of JavaScript "winning."
Second, things like PNacl, Emscripten, etc. still seemed like curiosities (as the talk refers to when showing Repl.it). It wasn't clear that they or the ideas they championed would get widespread adoption.
These days it is looking more and more likely that wasm is going to become a target for all sorts of different compilers. The fact that it's a major compilation target of Rust, a language that's about as far away from what I would've thought of as a language for the web as possible, is striking.
And though we're still a long ways away from running everything on WebAssembly, it no longer seems as exotic an idea as it once did to me.
And because of that, as well as the fantastic presentation, I still return to this talk every so often awed at how much closer we are to realizing Metal.
There's still a lot of room for the talk to go very wrong, but it's not as far-fetched as when I first watched it.
EDIT: Put another way; the talk is interesting to me because it emphasizes the birth and death of JavaScript. It talks about a world where the same forces that propelled JavaScript to towering heights of popularity ultimately cast it aside and create a world not possible without JavaScript, but in which JavaScript itself essentially no longer exists.
> Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance.
I interpreted that part of the talk as hyperbole and sarcasm. It was saying that programmers will be so far removed from how computers work that they'll happily program against a model that has five layers of abstraction that simply serve to provide the original interface of the bottom layer.
Bytecode, by its nature, has to be translated into native code -- the way for it to be 'faster' than native code is to be native code. In software, you can do this with static or JIT compilation. The hardware people do this by changing their CPUs to make the things that people do in the bytecode faster. (Apple introduced new floating point CPU instructions in their iPhones just to make JavaScript faster.)
There's also a lot of sticky points at the bottom of the stack that lead towards native solutions, starting with memory management and basic I/O functionality. Nobody wants to code directly against the hardware for very long, so you end up with a driver, and then driver and resource management, and then an operating system of some kind. Even on the early microcomputers it was the case that you have a boot ROM of some sort and would code against that for most tasks.
With WASM you have the same kind of thing but the added wrinkle of the browser-based I/O being a different set of "basic abstractions" from what you get in libc, and every solution that bridges the gap being a bit of a hack. Being bytecode doesn't really change the fact that you still have to deal with the resulting dependencies at some level.
Around 1999, HP had a project called Dynamo where they implemented a JIT PA-RISC virtual machine on actual PA-RISC hardware. In some cases, they got better performance than native because the JIT would recognize hot paths at run time. I only bring it up to show that it's not 100% certain VMs can't win over conventional native. When I compile with GCC or CLang, I don't think my executable is tracing the hot paths and rewriting itself as it runs.
I don't think this was entirely sarcasm, it's mostly hyperbole. I am sure there will be some generally used configuration that will do basically that, and for a good reason. I just have no idea what the reason may be.
About speed, JIT optimized bytecode can be faster than what is possible to static binaries. The JIT has more information than the compiler to optimize your code. Currently I don't know of any that is that fast, but there is no inherent limitation here.
I didn't get that understanding at all. The insight is that by going bytecode only you can rethink your security model. You can do things that you can't do safely if you allow native code to run.
It's swapping out one abstract model for another, just that we are so used to the current abstract model that we don't perceive it as one.
OK, yeah the "metal" part is fair. He showed asm.js and then posited that there would be something called "metal" that causes JavaScript to die and enables application written in more languages. And major apps could be ported to it.
Originally my conception of the video was more like this commenter below: It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly language.
I guess a lot of people are saying "he predicted this" without referring what specifically he is predicting.
FWIW it's not clear to me that WASM is going to do that. Everything I've heard from the team says that WASM and JS are complementary. Not that WASM will cause JavaScript to die.
I think there's some possibility of that happening in the distant future, but it's far from obvious. I think JS VMs will always be better at running JS than WASM VMs running JS engines, and all the JS out there will exist for a long time.
Also, JS is at a pretty good level of abstraction to manipulate the DOM, whereas C, C++ and Rust aren't. And it has some good syntactic shortcuts. Despite being a Python person, I would probably even argue that JS is better to manipulate the DOM, despite JS and Python being very similar otherwise. Function literals might be one reason.
So when people say "he predicted this", it would be nice to be specific about what the prediction was. WASM is a step in that direction but I would argue it's also fairly clear given that asm.js existed and he showed it. The real question is if WASM can handle all these use cases. Working on a language has made me appreciate many reasons that it's hard to make a polyglot VM. Tiny changes can bias your VM towards one compilation source vs. another.
> Also, JS is at a pretty good level of abstraction to manipulate the DOM
I agree with your point in general, but surely the fact that there are 10 million js frameworks invented every week is proof that the native DOM APIs are not a good abstraction? As a mostly front end dev, most of my UI logic these days target _React_, not the dom APIs. To the extent that I write JavaScript, it’s pure data manipulation, which can be written in any language.
That's true, although for another example, React is also commonly used with JSX to express DOM fragments. And JS has that syntax but Python, C, Rust, etc. don't.
In other words, the particulars of the language matters. I wouldn't underestimate 20+ years of JS evolution toward expressing the problem better.
I'm working on my own language and all those details are hard. When they work, they're invisible to users. You only notice when it's not there or doesn't work! I would agree that Python is a better language than JS in most respects, but it's not clear to me that it's a better language for writing web front ends.
e.g. the async abstractions and promises are different and I believe that matters.
The video creator is on HN so if the gods of internet attention shine upon us he may be able to comment here.
In lieu of that, I'll offer my one-line take of the prediction of the video. JavaScript will fade from popularity, but its (original) popularity will inspire a low-level assembly-like language (looking more and more like WebAssembly these days) that will provide a new substrate for most application development, web-based or otherwise, replacing traditional binaries.
As you point out it's not at all clear, even five years on from this talk, that this prediction will be correct. WebAssembly is currently complementary to JS and cannot fully replace it. The vast majority of websites these days use JS but not WebAssembly. Use of WebAssembly for applications that traditionally have not been run inside a web browser (e.g. GIMP, LibreOffice, etc.) is still nascent and it's nowhere near a sure bet that it'll take off there.
The sheer number of big corporate backers, and standardization, is what will make it happen. That's really what is different here versus Java applets, Silverlight, NaCl etc. Those all failed because nobody was big enough to single-handedly push something like that onto the ecosystem. Now that they're acting in concert, things are very different.
Everything else is "just engineering". E.g. as far as being complementary to JS, and not being able to replace it - they are already working on access to DOM.
> If you knew about [x], there's nothing surprising about [y]
You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
"The future will be just like the past, but with a different name".
I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
It’s not just executing code in the browser. It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly language. I think at least that aspect is wrong because Wasm came into existence. But ignoring that detail and subbing in Wasm for JS, it’s uncanny.
I personally see WASM as a natural descendant of ASM.js, so in that sense I'd say its not really wrong, just missing a step.
I don't know that it's necessarily uncanny though either; ASM.js was already a thing back when that presentation was given, so the existence of WASM isn't really surprising. The real central "prediction" of that talk wasn't WASM, it was METAL, which hasn't quite taken off yet. (The idea is out there[0], but so far mostly just as a self-fulfilling prophecy).
It's even more uncanny than that. The talk hypothesized that JavaScript will not be the universal assembly language but rather a lower level language (or more accurately an OS-like system I suppose as the talk presents it), "Metal," would be. In that respect it predicted WebAssembly on the nose.
In December that same year, the Internet Archive started letting people boot and run MS-DOS emulators in the browser. And this was well after binfmt_misc has been (ab)used with JS engines to execute JS like a native program.
A couple years earlier, NetBSD device drivers were running in the browser, and JS-engine-as-hypervisor was an explicit, if distant, goal. https://news.ycombinator.com/item?id=4757581
Completely! WebAssembly has a great potential outside of the browser. Mozilla has been doing a great work on their posts showcasing this new possibility.
Check out Wasmer! https://wasmer.io/ : along with other runtimes we are enabling the use case of WebAssembly programs as standalone applications that can run in any platform, or as libraries to be usable in any programming languages (disclaimer: I work at Wasmer!)
Yup. In addition to JavaScript runtimes that have added WebAssembly support, such as Node, there are dedicated WebAssembly runtimes, like wasmtime: https://github.com/bytecodealliance/wasmtime
If you want to provide a plugin or extension interface, and want to give those plugins a limited interface rather than making them all-powerful, embedding a WebAssembly runtime gives you all of that plus the ability for people to easily write plugins in any language.
If you export functions to WebAssembly, any language that can run in WebAssembly can call those functions.
And if you define WebAssembly Interface Types for your exported functions (note: still in development), any language that handles interface types can automatically handle things like "how does this language represent a string safely".
Either way, you don't need to define a new API for every language.
What you are describing is more like __asm__("") in C, not an interface for application developers. Those are still required for every single target language because of the mismatch between the levels of abstractions between those languages, webassembly and actual logic exported.
Interface Types are the mechanism for handling the different abstractions in different languages without having to write language-specific interfaces.
WebAssembly prior to Interface Types is more akin to an exported C function than to inline assembly. That already gives you enough for many kinds of interfaces, most notably the common pattern of obtaining an opaque handle and calling functions on that handle.
WebAssembly with Inteface Types gives you everything needed for high-level interfaces in any language. That lets you define strings, buffers, handles, arbitrary structured types, and pretty much anything you'd expect of a high-level interface.
I have read the article, when it came out actually, it's merely about type mapping rules to an intermediate common representation. And it absolutely doesn't imply that interface types give you everything for high level interfaces in any language. Not that it's even possible, as high level <-> wasm <-> another high level transformation cannot realistically be automated for an arbitrary high level language, what can be is just high level <-> wasm <-> wasm level looking code in another high level language. It's like decompiling, you can't produce high level code automatically, only low level looking code in high level languages.
It isn't just done, it is productized. Both Cloudflare [1] and Fastly [2] have been marketing that they support WASM in their edge networks. Both companies seem to suggest that this is a competitive advantage they could have over other cloud offerings.
Now if only we get a good web-oriented Python with a WASM backend, we'll finally be able to throw Javascript where it belongs: into the dustbin of history.
Not Op, but I'd like to do python/WASM because I don't do want to do C-Like languages. Sometimes you want to do some light web interactivity without major mental context switching.
For me, personally, it's a lot of effort to switch between languages. So when I'm building a web project and most of it is django/flask/python/etc, but I want something more dynamic than a HTML form post/browser reload... I need to do it in Javascript. Not that I can't javascript, I can, it's just hard to change over and I'm slow to write it. It would be a whole bunch nicer if I could just stay in the python mindset for those small pieces of code.
Do I think python is "better" for the web? No. do I think it's faster? Doubt it.
Do I think it's "better" for my use cases? Yes - And that's the power of WASM. It allows people to do what works for them.
For one thing, not being broken. Python doesn't have ("1"+1) and similar design flaws, Python doesn't need a new ECMAscript standard every year, Python has figured out modules and classes much earlier, and frankly, Python is what Javascript is only becoming after years of improvement. Really, I don't understand why we and the browser maintainers have to put up with a broken, insane language when there is a similar but much more mature and "done right" one. And as far as ecosystem, Python can kick Javascript's ass if not in quantity (though it's close) then in quality of its userbase for sure. And Python has been used onе the backend much more than JS, so it makes much more sense to unify the language and just use Python for the front-end.
I feel like almost every one of those points is highly debatable.
- New ECMA standard every year VS. new PEPs every year
- Modules and classes: cyclic dependency hell, obscure multi-import issues, __init__.py ugliness, imperative class declaration. Python only figured these things out much earlier to the extent that it has actually figured these things out.
I think almost any thing is better than js. At least it is popular due to its actual developer's. People use it because they like it and its ecosystem was grown by them, not force of a dumb decision in 90's or company backup. Both performance and ecosystem are not characteristics of language. they are due to being the only language is being supported in browser. (hint: I won't use python for web)
Also comparing languages based on syntax and ecosystem is not very clever idea.
Was going to ask in the main thread but perhaps here is a better place. For someone just starting with programming, but targetting WASM, which would be a good first programming language? Java?
In my particular case, I've been learning Python for Data Analysis for about one year, and a few months of Haskell (love Haskell so far, but my interest/job is related to data analysis and web dev). I've heard bad things about Python as first programming lang (weakly typed and bad OOP implementation).
Since Java relies on the JVM I think I'd avoid it, and any other languages that'd require running another VM on top of the WASM VM. Seems like useless stacking of technology that serves basically the same purpose. Not saying it wouldn't work and that it won't be done, but just seems kinda gross and missing-the-point.
Personally I'd also avoid anything with a fatter runtime than maybe Go or C#. If it doesn't already, I'd expect C# and .net generally to have really good WASM support, actually. And even those, unless it becomes standard to ship their runtimes with a browser, you're talking about a pretty fat package to ship before the program can even start running.
Most interpreted languages (like Python) running on WASM will probably be notably slower than Javascript running outside WASM, for the reason that they'll have similar limitations on optimizability, will have had fewer person-years put into optimization than Javascript (which has seen tons of investment from e.g. Google), and will be running on an interpreter in the WASM VM rather than a C++ (or whatever) native interpreter. And they'll have the problem of needing to ship an interpreter, similar to the runtime problems for the languages above.
For the best experience you want something fast-loading and well-performing. That means small package size and not too deeply nested in terms of abstraction on top of WASM. If you want a better experience on both fronts than JS, which has the benefit of already having its interpreter bundled with the browser and running on a native, highly optimized interpreter—IOW if you want running on WASM to actually be a win in any meaningful UX way—you'll need to look at fairly low-level languages, I think. C++ is a good bet—people are quick to shit on it, but it remains hugely important in GUI application development—or, if you're wanting something hipper, Rust, perhaps. Go or .net-family languages might be OK, future-proof-ish choices if you don't mind sacrificing load time a bit. Toss Swift in that bucket too, I guess.
Thanks! I'm still thinking if I should need to learn a 'learning language' first (Java or Python) and then move on to a low-level language or go directly to C++. I've been on Linux for years and feel quite comfortable with it, BTW. Can C++ be learned/used on Linux?
Just start coding. C++/Java/Python - whatever. The only real consideration you should have is picking something where the tool chain stays out of your way and works for you as opposed to you working for it.
I wouldn't start with C++. I did and then programmed in it for about 15 years. I liked it but looking back you spend a lot of time thinking about things that have nothing to do with the real world problems you are solving. And there are still far too many ways to do one thing. Despite modern guides etc you will still come across all these styles and they will distract you. Python is a great start. Virtually no bs, just programming. If you want static types then java or go or c# it doesn't matter. Stick to gc'd languages at the start.
Very much yes. One of the reasons C++ is a very popular language is its portability. It compiles for most any platform.
C is kinda the "native" language of Linux, if there is such a thing, in that it's the language of its kernel and of maybe (guessing) 2/3 of the popular GUI desktop environments on it measured by usage, but C++ is also big and (another reason it's popular) interoperates very well with C.
C++ is a major language in use at Google (written under a highly restrictive style guide there, though), if that matters to you. It can be used to write modules and libraries for work on lots of other, higher-level platforms (iOS and Android, for example). It's huge to the point of nearly excluding all other players in serious video game development. It is likely to remain very relevant all over the software development field for quite a long time.
As far as a "learning language", if we're talking scripting languages I'd put Python and Javascript at the top of the list. Javascript's weird in some very un-useful ways (it is very much possible for a language to be weird in useful ways—Javascript mostly is not) but is the language of the Web, which is why it's so popular. Python's friendlier and saner despite a couple potentially-irritating quirks, and has one of the best library ecosystems around. It's a leading language in natural language processing and machine learning, mostly on the strength of that library ecosystem—much of which, as is the case with most scripting languages, is actually written in C++ or C under the hood, for performance reasons. It's also got a huge Web framework comparable to Ruby's Rails, in Django.
My considered opinion on Java is that unless you have a special need for it (Android development, for example) or intend to go all-in on the broader JVM ecosystem, it's better avoided. The strengths of the JVM diminish rapidly as one's needs and interests go beyond it—though it can do nearly anything you need, provided you accept that you'll be using some JVM-based solution to all your problems. Working in it just some of the time is kind of a pain, and it doesn't play as well with others as either traditional interpreted languages or non-VM compiled languages usually do.
If you're looking at learning a compiled, statically typed language I'd go for C, C++, or maybe—maybe—Rust these days.
My advice would be to learn how basic data structures and running programs are laid out in memory, how the stack works, and how things like method lookup tables are implemented, early on, no matter which language you're looking at, all of which are much simpler and less intimidating than one might think. It'll demystify and make obvious Object Oriented programming and recursion and some other things that can acquire an (absurd and extremely false) air of the magical in approaches that don't incorporate those things.
I'm not an expert, but my understanding is that with Web Assembly you essentially have to ship the whole language if you're doing dynamic languages, so it greatly inflates the size of the package the user has to download.
The one I've been looking to the most is Rust, as it compiles to a smaller size, doesn't have a GC to ship (by default), and is not C/C++. C/C++ seem to be the other common WASM languages.
Edit: Just saw you're a beginner programmer, I probably would not suggest Rust as a first language. Web Assembly in general may not be a good starting point, but if you're set C++ might be slightly better. (I tend to suggest Python as a starting language)
Python would be a bad choice for the web since it was not designed around events. JS was designed specifically to turn on top of a browser with an event loop to respond to events as they happen. Python would just make a slow non responsive browsing experience. Also WASM wasn't designed for "any languages goes" in mind, it was designed for lower level languages like C/Rust which have manual memory management to run high performance applications like games, and video editing tools etc.
Also as someone who uses Python regularly, Python is by no means a perfect language. I am assuming you only know Python since it's an attitude I often come across for devs who only develop in Python and believe it's the superior to every language in every way.
I think in the end we may have a subset of JavaScript that compiles to WebAssembly. Something like TypeScript. Something that cleans up the mess of JS and keeps the good parts.
What would you prefer then, Lua, with its 1-based arrays? Python is a mature, universal, versatile, insanely popular dynamic language with a nice syntax. It fits the bill perfectly.
If indexing arrays starting at 1 is a big problem, either the language is fantastic or you aren't challenging yourself. Programming gets a lot harder than that.
I'd like that too, but it's not going to work with the web dev populace. They're used to a dynamically-typed sandbox and won't switch to a full statically typed language.
Such hate for JavaScript. To say JS needs to lose for you to win says more about you than it does JS. Just a thought. I see a world where there are many winners and one where WASM and JS and whatever you want can fulfill their need where needed.
This seems like a straw man; I’ve seen relatively little JS hate in this thread. Unless you’re considering WASM’s progress (or existence) to be an attack on JS? I personally don’t see what is wrong with having other choices for web development.
Well, I was already pretty much ignoring the W3C already since HTML5. Now I can really let go, which will put me back to HTML 3.0 with no CSS nonsense.
That struck me as wierd too, then it got me thinking about the 'great wall' and China's ability to insert tracking ( or other ) JavaScript into a user's session... and then how that's going to be different now in the age of web assembly... I can imagine it would make obfuscation of intent easier for one thing.
...really? From my perspective, it's a bunch of companies that are known only for operating within China (360 / Alibaba / Baidu / Tencent), two hardware companies best known for being Chinese (Huawei / Xiaomi), and one I've never heard of (agora.io). Over half of the testimonials are in Chinese.
I'm curious too - was there really no non-Chinese company that would endorse this?
The voting system is roughly: any paying member company can submit a "formal objection", which will be considered by W3C management ("on behalf of" Tim Berners-Lee). If upheld by management then the recommendation doesn't go forward. (This is very rare; I don't know of any instances off the top of my head.)
I think it's just a little shocking as it kind of makes it seem like nobody outside of China supports WebAssembly.
I think having a wide variety of companies from open source "pro web" to Google and Alibaba might be better then having a pile of extremely wealthy firewall supporting companies.
i am not convinced that wasm interpreter will be bug/vulnerability free.
as it was the case for every new piece of software there will be ton of vulnerabilties in the VM itself that will be exploited
Without defining a standard set of abstractions around operating system resources it is pretty far from competitive with Java and more closely related to something like LLVM bitcode.
It is very close and with a standardized ABI it can be (that is how it was slightly modified to be used in Google's Portable Native Client). It is much more similar to WASM than Java byte code.
True, but GraalVM is based on the OpenJDK / OracleJDK JVM:
"GraalVM Community Editions are based on OpenJDK version 1.8.0_232 and on OpenJDK version 11.0.5. GraalVM Enterprise Editions are based on Oracle Java version 1.8.0_231 and on Oracle Java version 11.0.5." Source: https://www.graalvm.org/docs/getting-started/
some of the compute workload still needs to be on a backend because of security concerns.
if you offload too much stuff on a client-side, then any hacker can mess with it and break your system.
for example you can get angular debugger extension for chrome and mess with any online shop that uses this system to "adjust prices" for your cart during checkout
This is only a problem for online services, multiplayer games etc. These shouldn't trust client-provided data, including data that comes from WASM. But there are countless applications that can be entirely local, with no need to interact with any sort of "cloud" services. WASM can potentially be quite helpful there
For me Java is legacy.
A good runtime for the web will have a lot of developers worldwide. I am betting on it not just for the web, but to replace legacy apps as soon as we get a good runtime not just for the web.
I don't know what your experience with the JVM is, but it really isn't legacy. It's actually much more state of the art.
Can you explain a bit more in what way you see it as legacy?
Because the JVM has some of the best GCs, and JIT + AOT compilation of any VM around. And its portability story is quite impressive.
You can argue Java as a language has some legacy hanging around, though they've made great progress there with the latest versions. But the JVM has support for other languages as well, such as Ruby, Python, Scala, Kotlin, Clojure, Common Lisp, JavaScript, Fantom, etc.
Now WASM isn't a runtime. WASM is more akin to Java Bytecode or LLVM bitcode.
Each browser vendor will implement their own WASM VM. Currently, there is no standard for Garbage Collection, which means GCed languages won't be good candidates for WASM. If you want to use Python, Java, C#, Kotlin, TypeScript, Haskell, etc. your resulting program will need to bundle a full runtime for your language compiled to WASM as well. In all cases, this will end up having slower performance, and on the web will cause bigger download sizes.
Hopefully, this gets addressed in the future.
The flip side is portability. For example, Go compiled to WASM could run on all WASM non-web compliant VMs. But it'll run slower than GO compiled for the target machine directly.
That's why a good use case for WASM right now is to allow JavaScript to make use of C/C++ libraries in the browser. As well as Node.js to do the same in non-browser contexts.
This will often mean an HTML/CSS/JS UX with certain section of it in C/C++/Rust.
It does mean that Electron apps will be able to make use of portable C/C++ libraries more easily, as they get compiled to WASM and the V8 runtime will be able to run that WASM and eventually offer interop with the DOM and JS. Though that's not yet supported, as the boundary between GCed JS/DOM and WASM hasn't been fully figured out yet.
Also, WASI is the standard library for WASM, and that'll need to grow as well. Progress is being made there too, but its goal is to remain minimal, and delend more on libraries.
Conclusion, let's say you have WASM, Java Bytecode and LLVM bitcode, and maybe even .net IR. All of them are a form of virtual assembly which need a VM to run them. Any language could build a compiler to any of these. But they have different trade offs.
Java Bytecode is pretty simple, and the VM has a standard memory model and GC with a large accompanying library, and a state of the art JIT. Making it a great target for higher level languages.
.net IR is pretty similar, though the bytecode can be a bit more difficult in its handling of reified generics. That can make it a bit harder to target for higher level languages. Its JIT isn't as sophisticated, same as its GC, but it comes real close, and has good tooling around it and an excellent standard library.
LLVM will remain king for high performance, as it is designed to handle all kind of optimizations, and support multiple's language feature set efficiently. That said, it isn't as portable and isn't optimized for small binaries and fast parse times. It too, is best for low level languages as it doesn't enforce a memory model.
WASM also doesn't enforce a memory model, making it a great target for low level languages. It is optimized for safety and portability. Which means it'll most likely always be slower than LLVM. But it also tries to be as fast as it can, and theoritically could beat out Java Bytecode or .net IR given it can avoid GC overhead. It also is optimized to be streamed over the wire, that means small binaries that can be quickly parsed. So ideal for code that you can't predict where it is going to run, like the web.
The VM landscape overall is looking pretty healthy. But I think there's misconceptions out there, especially around the JVM and .net Core, and also about people's hype for WASM. Specifically, the JVM and .net Core are almost impossible to beat for what they do. So don't expect better from WASM. Similarly, JS is almost impossible to beat for what it does, and WASM doesn't plan to replace it, but enhance it.
> Java Bytecode is pretty simple, and the VM has a standard memory model and GC with a large accompanying library, and a state of the art JIT. Making it a great target for higher level languages.
Not necessarily. The problem is that JVM is too high-level, and imposes not just a memory model, but also an object model, with many constraints to impose memory safety. That can be difficult to work around without performance penalties. So languages that are designed to target JVM from the get go, tend to be designed with those limitations in mind, constraining them.
.NET bytecode is somewhere in the middle between that and wasm. It has things such as raw pointers and pointer arithmetic, dynamic allocation of stack, unions, and other things that aren't memory-safe. This allows languages that don't want to have memory safety imposed on them (like C++), or that have their own ideas about how to impose it properly (like Rust), do whatever they want, and run efficiently on top of CLR. But it still has that high-level object model, much like JVM, which can be used for interop that's higher-level than just a C ABI.
wasm, for the time being at least, is a VM that is limited to a C ABI. Their future plans, such as interface types, can potentially approach the complexity of the JVM and CLR object models, but with more isolation boundaries (because memory isn't shared between modules).
It will bury JS long before it buries Java(/JVM), if it will bury either. I'm not sure there is any convincing reason to use wasm on the backend, where java is prevalent.
As in, JS development for browser? You'll still need JS to run WebAssembly in the browser. It'll bury JS in the sense that you are able to develop in any other language like C++, and compile your program to JS+WebAssembly, so you don't need to develop in JS anymore. But JS itself (under the hood) is probably to stay for longer.
To be clear, absolutely nothing is stopping apps from doing this in JS today. There have been multiple "canvas web frameworks", even one getting funding to the tune of $27m before imploding: http://deprecated.famous.org/
> And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem.
There will also be performance problems. The web is already slow using the heavily optimized DOM. It's going to be so much slower when things try to use a fullscreen Canvas instead. That breaks all sorts of optimization opportunities browsers currently leverage.
But sadly it'll probably happen. We'll all end up downloading forks of browsers in various states on each site we go to as each site decides to re-invent the DOM & all the rendering optimizations that go along with it.
> And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem.
I know nothing about webm beyond the idea that it's supposed to help developers write code in non-Javescript languages which can then be run in a web page via a canvas element. If my scant understanding is correct, then I assume it will be up to those developers to include code (or relevant libraries in each language) that will make the canvas element act responsively, and handle issues like accessibility, user interaction, tracking etc to give the best user experience?
My view is that current Javascript libraries that target the canvas element have largely failed to address canvas-related issues such as accessibility in a decent way - which doesn't give me much hope that future webm libraries which could be used to build user interfaces will do any better ... unless there's strong pressure to make accessibility a core goal for such libraries.
There's no good reason not to include accessibility (and user interaction, tracking etc) into any library - including JS libraries - that target the canvas element. Part of the reason for me recoding my own JS canvas library was to address exactly these issues (results of my work here[1]), and if I can manage to solve a lot of the issues then there's no reason why others library maintainers couldn't do a much better job of it than I did!
"if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem"
As a web-development near illiterate, this equals to me as pages that aren't auditable before they're shown, which would pretty much translate into unblockable ads. Please someone tell me I am wrong.
If you switch off javascript then the WASM files won't be able to be loaded.
Then on top of that I guess you could just filter for all `canvas` elements. That will cripple some [biased edit: worthwhile] uses at the same time, though.
A very valid concern. I wonder if it would be easier at this point to have screenreaders work visually rather than trying to dive into the source to grab the text.
Text recognition is getting pretty good nowadays afterall.
This seems like a really hard problem to me. I actually wish image formats like PNG could have annotations inside them saying "there a is 45px tall 34px wide letter 'a' at position ..." which would be automatically generated by image editing software and screenshot apps. It would make it possible to select text inside an image and allow screen readers to work better.
The modern web already burned that bridge and loudly declared that it doesn't give two shits about accessibility. There are plenty of companies that gladly sacrifice accessibility to have "beautiful" interfaces designed by some self-important jackass.
That argument sucks. Yes there are sites with poor accessibility, but there's also a lot of sites that are fine. It would be a huge step backwards if they switched from DOM to Canvas.
You raised a very valid point here. How much difference will be between a canvas-painted web-app and a native Windows application? The line woll get increasingly blurry.
You mean for accessibility? Maybe but there shouldn't be any fundamental reason why an accessibility tool can read a windows app and not web app, since under the hood Chrome and Firefox can use the same interface this tool interfaces with.
If you meant performance in terms of runtime, I'm not convinced this is the case. Obviously WebAssembly will have some overhead, but I don't think the overhead is critical enough for most applications to matter. Especially if those applications are written in anything other than C/C++, they'll have similar performance characteristics.
I don't think Java is a great language, but killing at this time would destroy a lot of value.
Besides, people mostly do not use Java because of the JVM, so I don't think WA will even make a dent on it. It's more likely that Java gets ported into WA than that WA kills it.
Not to complain about WASM because it's great, but it certainly needs more compilers and toolchains, and it should be possible to make webgl calls directly.
Toolchains like clang and g++ should be able to generate WASM directly, I don't understand why you need so many things like bynaryen to make a WASM file. Having tools is essential if you want a technology to progress towards adoption.
EDIT: actually clang can now generate WASM. I'm not curious how feasible it would be to package python with WASM
Ten years ago browsers were capable to do pretty much the same but with Java on board that they all had at those times.
WebAssembly is conceptually close to JavaVM (JITed bytecodes) but due to its architecture Java allowed as a) reflection (JS to Java calls) as b) exposure of DOM model into Java execution space - DOM API even now is defined in terms of Java interfaces by the way.
WebAssembly is a step in right direction but the evolution looks as Waltz - two steps forward two steps back with the twist.
Now we are able to run ray tracers compiled to WA on browser side but we've lost an option to apply the results to DOM elements directly.
To say in CSS: