WebAssembly becomes a W3C Recommendation
w3.org
w3.org
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:
my-component {
behavior: my-native-event-handler url(controllers/my-controller.class);
flow: my-native-layout-manager;
}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.
I was using asm.js in the past, but WASM gives a noticeable and necessary performance boost.
Which specific CPUs or applications that you emulate really take advantage of the performance boost that WASM provides?
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.
[1] https://tech.ebayinc.com/engineering/webassembly-at-ebay-a-r...
Edit: here's the PR for switching from asm.js to WASM, in case anyone's interested: https://github.com/vector-im/riot-web/pull/7385/files apparently it merged in Oct 2018.
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
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.
Using the whole .NET ecosystem from browser, yea I think there's some good success stories ;)
PSPDFKit uses it for their pdf editor.
Unreal Engine/Unity uses it for their browser support.
It's used in production in many places either as modules or entire apps.
Except for some noob mistakes when implementing the PoC it’s worked remarkably well, much better than I though it would.
Pretty sure Electron provides IndexedDB though.
(Ref: https://nolanlawson.com/2015/09/29/indexeddb-websql-localsto..., vaguely https://nolanlawson.github.io/offlinefirst-2016-03/)
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.
I just realized the links I posted didn't include the article I had in mind when I went link-digging (and didn't properly check the results, woops). I found it: https://nolanlawson.com/2014/04/26/web-sql-database-in-memor...
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)
You can jump to 47 minutes in to catch a little bit of the web animation in action, but as it was over conference WiFi, it was a bit wonky.
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 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.
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.
For the better or the worse...
https://www.forcepoint.com/blog/x-labs/browser-mining-coinhi...
Could someone in the know shed some light in this matter?
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:
- (Pro) now all of the member companies of the WebAssembly working group (https://www.w3.org/2000/09/dbwg/details?group=101196&order=o...) have pledged not to use their patents to sue anyone who implements the WebAssembly specification.
- (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.
--- quote ---
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.
--- end quote ---
> Paragraph 1
>
> Paragraph 2
> Quote 1
> Quote 2> 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.
You can't get quote blocks here either.
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.
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.
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.
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.
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.
DOM access will be possible through the interface-types extension [0], but no host supports it yet AFAIK. Also still a very tricky problem.
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!
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.
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.
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.
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)
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.
> You can take a Canvas element and draw anything you like on it
Don't you need to first go through the DOM to get the canvas element?
Of course, why not just use a small HTML+JS shim for your WASM?
> 3. Design to execute within and integrate well with the existing Web platform:
> * execute in the same semantic universe as JavaScript
> * access browser functionality through the same Web APIs that are accessible to JavaScript
Lawyering aside, I would say that this is pretty much the same thing as "enabling the development in web apps in other languages".
Using the existing HTML + JS avoids creating as much future legacy cruft.
I don't think changing this is even desirable. It's much easier and cleaner to standardize a stdlib of accessors.
This wasn't the intention when the script tag was introduced. 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.
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.
But now, it's pretty much just JS.
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.
There are many things to be done in the standard, in the implementations, in the frameworks...
[0] https://www.destroyallsoftware.com/talks/the-birth-and-death...
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.
Also the JVM ran in the browser, etc.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
But maybe, just maybe, it'll happen.
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.
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.
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.
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).
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
EDIT: some quick googling shows it's already being done
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...
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!)
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.
Also see https://hacks.mozilla.org/2019/08/webassembly-interface-type... for an illustrated description of how that'll work smoothly across languages.
No, you would still have to provide an application programming interface for every target language you want to support.
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.
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.
1. https://blog.cloudflare.com/webassembly-on-cloudflare-worker...
2. https://www.fastly.com/blog/announcing-lucet-fastly-native-w...
EDIT: here it is: https://medium.com/wasmer/running-webassembly-on-the-kernel-...
syntax? subjective, and it would also mean all C-likes belong in the dustbin.
performance? Why would python, as a language, be significantly more performant? It's just as dynamic.
ecosystem? JS community is huge, JS package managers are huge (even though not flawless, but nothing their python counterparts do better)
I mean I can surely imagine there's better alternatives for JS, as a language. But python...?
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.
- 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.
...
You expect that to carry over to WASM environments?
Also comparing languages based on syntax and ecosystem is not very clever idea.
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).
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.
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.
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)
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.
https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scien...
I think it's really great but it would be better to have company from all around the world
I'm curious too - was there really no non-Chinese company that would endorse this?
W3C members are visible here: https://www.w3.org/Consortium/Member/List
Those are the members that decided that WebAssembly is now an official web standard, not the testimonials.
I'm investigating more about the voting system here, https://www.w3.org/Consortium/Process/ERB.html.
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.
A bunch of Chinese companies is essentially the viewpoint of the current dictator of China, should he choose to weigh in.
For instance, they are two countries, whose names end with the letter "A"... dare I continue?
the concept of wasm doesn't really fly with zero-trust internet
Any website can already do that with asm.js. WASM does not change the security model of browsers.
That part is called WASI.
https://www.chromium.org/nativeclient/pnacl/introduction-to-...
Until such a creation comes to be, the OpenJDK JVM will continue to thrive.
"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/
So, it's still the OpenJDK JVM underneath.
Though V8 is more likely to be what WASM first targets.
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
e.g. https://www.cloudflare.com/products/cloudflare-workers/
advantages: sandbox, portability
disadvantages: performance, platform integration
nobody's saying that server-side wasm will be universally the right choice.
Probably Electron can be one of such new runtimes
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.
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).
Unless screen readers can now dive down into the canvas layer?
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.
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!
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.
Text recognition is getting pretty good nowadays afterall.
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.
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.
Obviously, for such a wide prediction I can only speak theoretically...
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.
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