Web Assembly now supported across all browsers
infoq.com
infoq.com
IE.
Everywhere I've worked, we still have to support it. Unless Microsoft ports Edge to Windows 7/8 and makes it a default browser, I don't see the situation changing anytime soon.
And my comment was about old browsers/OSes not supporting wasm.
I can see two ways of interpreting your answer, and neither looks like it gives the desired performance benefits of a plain asm.js fallback:
One: a WASM interpreter in asm.js. Given what this would imply for performance I'm pretty certain that this wasn't what you meant.
Two: a WASM-to-asm.js compiler, possibly in asm.js, that can take downloaded WASM.js files, turn it into asm.js, then load it through the Function constructor.
Assuming you meant the latter: do browsers even support loading asm.js that way? Assuming they do, this would still introduce extra overhead, having to download the compiler, and adding a compilation phase. Of course, since WASM files are binary, the benefit might be lower bandwidth use, so for slower connections it could be a net gain over plain asm.js...
I also vaguely recall that functions creating with the Function constructor don't enjoy all the JIT-compiled optimisations that normal JS functions have, but a quick visit to jsperf[0] seems to disprove this for modern browsers at least. Or perhaps that had more to do with inlining, since they are always created in the global context - an issue that does not apply to asm.js functions anyway.
[0] https://jsperf.com/function-vs-constructor-vs-eval/7, https://jsperf.com/function-by-constructor
- test for presence of WASM, if absent fetch the pre-compiled asm.js fallback
- test for presence of WASM, if absent fetch an asm.js WASM compiler to runtime-compile WASM to asm.js.
There's a potential a trade-off in both downloaded size (depending on how big the compiles asm.js file would be compared to WASM + asm.js-based compiler) and loading times.
The prototype you linked looks cool though; too bad development on it seems to have stopped in early 2016. I'll copy their outline of how it works for the lazy:
1. On the main thread, the client kicks off a load
of a URL by calling loadWebAssembly and receives
a Promise<Function>.
2. The polyfill library starts up a worker containing
asm.js code compiled from unpack.cpp concatenated
with the glue code in load-wasm-worker.js.
3. The worker glue code fetches the binary via XHR
then copies the result into the asm.js heap.
4. The asm.js code decodes the binary into asm.js
in the form of UTF8 bytes in a separate region
of the asm.js heap.
5. The worker glue code creates a Blob (a read-only
copy) from a view of just the asm.js UTF8 bytes.
6. The Blob is postMessage()ed back to the main
thread (a non-copying operation) where it is
loaded as a script element with
script.src = URL.getObjectURL(blob).
7. When the asm.js script is executed, it passes the
asm.js module function object to a callback which
resolves the promise in step 1.I think it's only relevant for business applications, as employees can't just easily switch browsers on their own. Consumer apps and games have a lot more leeway.
It's not much different than having to ship a runtime for an app written in languages other than C/C++. WASM apps will just require the use of a proper browser. At some point the world has to cut the cord on IE anyway.
It isn't just old IE that can be a problem in corporate environments. I work on a product used by branch and admin staff in larger UK banks, and where an alternative is used it isn't usually an up-to-date one.
For the largest instance of the app, the most common UA in IE11 (in various compatibility modes for extra confusion) but IE8 is still common enough that we have to care. They seem to have skipped IE9 and IE10 completely. Edge is nowhere to be seen but that is expected as I don't think they've moved beyond Windows 7 for the most part (I still see XP in use). Chrome is in use in some parts of the business, but not the latest: the Chrome versions witnessed in the last month range from 40 (released at the start of 2015) to 59 (much better, only four releases back, but still 6 months old).
Though IE is the main problem, if you have commercial clients who use Chrome/Firefox/other you still need to be careful not to rely on enhancements that haven't been common for some time.
Aside: I'd be really interested in whether these browser microclimates ever develop dependencies on old Chrome versions that end up being problematic to carry forward to newer versions.
The slower the adoption of these fancy new features, the more chances for content to remain accessible to those who simply don't want to feed the hedgemony and use other alternative browsers. As it is, the situation is bad enough with developers/designers itching to hide otherwise simple, static, and accessible content behind massive bloated web apps. I feel WebAsm is going to make that even worse, because now they can go even further with obfuscation.
When considering the state of the web as a whole, and one of its goals of wide access to information regardless of user-agent, if the presence of IE can slow the needless appification trend, IMHO that's a good thing.
There's some more detailed discussion on that here: https://news.ycombinator.com/item?id=15836027 and in particular my comment at https://news.ycombinator.com/item?id=15836315
Also related: https://news.ycombinator.com/item?id=9961613
I enjoy writing JS both for frontend and backend but the perspective of being able to write strictly in something like F# looks really appealing.
I would even argue that the ability to execute code on the web is more profound and revolutionary than the ability to only publish text. It's not unnecessary complexity, it's adding a new dimension to what the web will be capable of, and by extension, what users will be capable of.
>. As it is, the situation is bad enough with developers/designers itching to hide otherwise simple, static, and accessible content behind massive bloated web apps.
That bloat isn't a problem with the web itself, or with features added to the web, it's a problem with developers and coding trends, and the need to provide polyfills and shims to support IE.
The guys behind Java applets, Flash, ActiveX, Silver light etc all thought that exact same thing.
But all of those required plugins or proprietary code in a single language, whereas Webassembly is intended serve as a proper bytecode for any supported language, and it's not owned by any particular company.
They'll be able to go just as far: too far for you to be able to make sense of it. WebAssembly or not, that ship has sailed.
See here and click 'usage relative': https://caniuse.com/#search=WebAssembly
If 90% of your users are on IE, it's not enlightening to point out that those 90% only make up a tiny fraction of the global browser users.
Support for Windows 8 ends in a month[1]. There's extended support for some users for a further 5 years, but if you're doing client work rather than writing bespoke software for a specific user then IE, and Windows versions less than 10, are effectively dead and gone.
It's perfectly reasonable to use web technologies that aren't supported by IE. Ideally you should have a bare HTML server-side alternative for those users, but that's true for everything that a user might not have (or have turned off, eg JS).
[1] https://support.microsoft.com/en-gb/help/13853/windows-lifec...
That is not how this works.
https://support.microsoft.com/en-us/help/13853/windows-lifec...
There are different versions/branches of Windows 10 that come out every 6 months or so.
Some of the branches/versions are "Long term servicing branches" (LTSB) for enterprise environments, supported for 10 years. There are already two of those. https://en.wikipedia.org/wiki/Windows_10#Updates_and_support
For everyone else, the branches are supported for 18 months. https://technet.microsoft.com/en-us/windows/release-info.asp...
In reality Microsoft can stop supporting your computer's _hardware_ much earlier than that, if your device maker stops supporting it (reminds me of Andriod phones):
> A device may not be able to receive updates if the device hardware is incompatible, lacking current drivers, or otherwise outside of the Original Equipment Manufacturer’s (“OEM”) support period. https://support.microsoft.com/en-us/help/13853/windows-lifec...
And they've already stopped supporting some devices: https://www.computerworld.com/article/3216005/microsoft-wind...
Ha! Don't we all wish. Here's the marketshare numbers from this month [1].
- Windows 7: 43%
- Windows 10: 30%
- Windows XP: 6%
- Windows 8: 5%
And companies are going to be buying extended support for 7 no different than XP so you'll have to wait out that 5 years.
[1] https://www.netmarketshare.com/operating-system-market-share...
If users with IE6 and users with IE11 get a boring HTML-only-but-still-basically-functional website, and users with Edge 15 get the fancy WASM enhanced website, then that's fine in my opinion.
So even though Windows 10 still ships IE the fact that it's not a default is enough to not support it? Bad news for Firefox and Chrome then.
> If users with IE6...
Sure, albeit a bit extreme, that's more or less progressive enhancement.
Using Firefox or Chrome is a step sideways to use an alternative browser. That's great. The more up-to-date browsers people use the better in my opinion.
Using IE is a step backwards usually to support a specific technology that isn't supported by other browsers (and IE is often used along side another browser if that's the case), or because the user is looking for a particular experience. I don't see either of those reasons to avoid using WASM on a new website so long as there's also a fallback to support browsers without it, even if that's a limited version of the site.
I agree that older browsers can get basically functional while others can get a progressively enhanced experience but a lot developers hate the idea of making something twice. Also, for what WASM is best suited for, I don't know that there's a point to making a basic, HTML-only version.
Edit: I wasn't thinking about WASM support through polyfill, I don't know what the performance difference is typically like.
That's 6 more years. Let that sink in for a bit.
Seriously thinking about switching careers at this point.
But according to Netmarketshare, fully 7% of Windows 10 users use IE.
https://www.netmarketshare.com/browser-market-share.aspx?opt...
Insane.
Someone is porting TypeScript to WASM, named AssemblyScript.
It won't surprise me to see a WebAssembly backend for Flash.
If Adobe was smart, they'd have started working on am asmjs (later WebAssembly) + webgl output for Flash a long time ago.
Alas they're not exactly forward-planning and let the platform die, and its tools fizzle. Today there's already better alternatives that do things more cleanly/natively (like Pixijs). If you use TypeScript with Pixijs, it's like having a much more advanced ActionScript, better development tools (your browser's devtools), and better performance. You lose a "stage" for free drawing, but that was more often than not a misused feature anyway (and one that has good alternatives in the DOM/JS world anyway).
And for a while they even had a C/C++ compiler for the Flash VM.
So if they really cared, it isn't something that should be too hard for them.
Failing that, it might be an interesting project for a compiler hacker without ideas.
In any case, I see it more like preserving many of the games written in Flash.
I am completely fine with asm.js.
Though WebASM is a like a wet dream for big corp with mass of legacy code in C++. We will see Office running on WebASM and other closed binary blobs in near future. It's very contrary to the concept of the open web - do you want to live in AOL-land again, were everything is closed off? No? Anyway great you helped them. I fear WebASM has several downsides that will harm young startups a lot in near future - only unicorns and big corps will benefit, it will be a win-win, less competition, because of harder entry to market, and they can ship their decades old C++ blobs as a service. It's time to wake up, and stop WebASM or severe limit it's functionality. Where is Mozilla foundation? Or is the new Mozilla just another startup, backed 90% by Google money.
Don't count this out; there opens up the opportunity for creating new, good looking toolkits that are faster to use than coping with html + css' limitations.
I can see how C/C++ (and, well, more likely Rust) will become a de-facto solution for when you need performance or some type of robustness to your apps (ie probably the right thing for Figma). But the potential performance improvement might be negligible on most makes, and unlikely to offset the fact that you'd be working off a completely different stack making things like debugging and inspecting much harder.
What I think is likely is that using WebAssembly will allow new types of web apps to become popular. Things like video encoders, image editors, etc. Things that you just wouldn't do with JS anyway, at least not in the heavy parts. Thing of a standard web app that uses ffmpeg on the background.
But in 2017 startup and companies are starting to understand how fast response times (on a website/web-app) are of critical importance for gaining a good user base.
A C solution might make the former faster, but it'd still be a dumb architecture. A cheaper solution than migrating your whole codebase to a separate language and build process is knowing how to deal with events and how to parallelize (or delegate) stuff correctly.
Not only you but many, many programmers out there in other languages, wishing for more performance, or for a higher level of abstraction. I will brace myself for the amazing applications that will be built now for the web.
That's a shitload of code shipped to the user before you even write a single byte of code for your application!
Personally this revolution can't come soon enough.
But as I understand it, it needs a toolchain?
You can see an examples in Rust including the readable Wat output here:
It's funny, I'm the exact opposite. I don't like cloud apps. One day they're there, next day half their features are removed, next day they're gone. And I can't hack them to make them better fits for me when they keep changing. I want the code to run on my machine so I can do anything I want to it and have a stable environment I can rely on.
I don't put anything I care for on machines I don't own. I own many machines in the cloud. They are beautiful. Because they are all the same. They are virtual. They are cheap. I can create them with a click. There are so many vendors. If one of them would go away, it would not tamper with my ability to create new machines.
I was talking about web apps, but w.r.t. VMs... sure, at the price of your pocket though? I can run my home computer all I want and not pay for anything except the electricity and internet.
> They are virtual. They are cheap. I can create them with a click.
If they are virtual, you don't own them. You own an 'I promise really really hard' of some vendor at best.
None of which has anything at all to do with installing a fucking tool chain.
BTW you DON'T need WA if you don't have performance issues with your current web application.
As for performance: I do a lot of machine learning in the browser. So performance is something that I am interested in.
Almost everywhere you look in front-end web today you see a toolchain that includes the node runtime, babel or typescript as a compiler, and some kind of bundler/linker such as webpack or browserify that throws in minification/mangling in as a freebie. That doesn't even cover CSS.
JS/CSS is already a compile target with a build artifact often barely resemble the original source code. WASM is just another compile target that opens up the web as a platform for other languages.
Compiler IR's like WASM or LLVM IR are very laborious to type, they're intended to be produced and consumed by compilers.
You need to write very verbose code with all the type declarations, which aren't automatically propagaged, ie. `(func $foo (param $0 i32) (result i32) ...)` and `(i32.add ...)`. There's very little point in writing code like this by hand, apart from testing and debugging the compiler producing or consuming this code.
It doesn't make much sense to have this "in the cloud" outside of toy tools like this. In any kind of actual work scenario, you'd be running a compiler producing WASM on your development machine and deliver the WASM binaries over HTTP to the client machine. The whole point is to have near-native performance while reducing the compile time on the client side.
But if you want to tinker with it, knock yourself out. Here's the tool:
[0] https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wa...
I think there's at least some value in these "toy tools". Would being able to tinker with WASM not help development of compilers? I place a very high value on understanding as far down the stack as you can, I don't think ignorance of every abstraction layer below the one you're working on is a very noble goal to strive for.
There are tools, even web based ones, that allow you to tinker with WASM, compile C, C++ or Rust code to WASM, print out the WAT representation, turn WAT into WASM, run the WASM blobs through JS, etc.
These tools are probably very useful for the guys developing WASM frontends and backends. E.g. sharing a piece of WASM code with other developers.
Should the average developer use them? Not really. Maybe spend an hour poking at things to get the general idea of how it works. You really don't need to understand the details of LLVM IR, SPIR-V, WASM or GCC's GIMPLE in order to use those compilers.
Is it a good idea to understand what and how are intermediate representations used in compilers but actually writing that by hand is not necessary or productive.
Sounds like a strange duality of criteria to me.
But don't we already have a universal byte code with JVM bytecode?
Why did the wheel need to be reinvented here? Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it?
This isn't a troll question. I'm curious what are the fundamental underlying technical issues that made WebAssembly necessary
(please be nice... c++ developer here.. so I'm really clueless about web stuff. I don't even use the JVM)
Also the reason why the only major revision to the MSIL bytecodes was the support for generics.
> Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it?
Lack of pointers. Lack of true structs. Different memory model. Enforced class/object model.
WebAssembly has a memory model which is very close to a generic CPU.
My understanding of what made WASM necessary -
You don't want a GC? You don't get a GC.
You want full control over your memory layout? You get a raw growable slab of memory with raw pointers.
Never been using C, I guess-coded my way to this little program:
int pow(a)
{
for (int i=0;i<10;i++) a=a*2+1;
return a;
}
int main()
{
return pow(1);
}
(module
(table 0 anyfunc)
(memory $0 1)
(export "memory" (memory $0))
(export "pow" (func $pow))
(export "main" (func $main))
(func $pow (param $0 i32) (result i32)
(i32.or
(i32.shl
(get_local $0)
(i32.const 10)
)
(i32.const 1023)
)
)
(func $main (result i32)
(i32.const 2047)
)
)
Then again, I could just be feeding a troll right now, I really can't tell.
Anyone can implement one and ship it with the statically compiled WASM code, it is no different than targeting an actual machine code, unless we are speaking of CPUs like Intel iAPX 432.
The only issue is having a little bigger download, which is irrelevant in the age where web pages to display static text are bigger than the whole Quake installation.
As for the bigger download, I'm hoping we'll be able to load libraries dynamically through WASM so you can cache things like the C runtime separately
The idea of caching runtimes looks good, but we need some kind of versioning, otherwise it will be yet another WASM.so hell.
Maybe tying them to the origin would be a possible solution.
The popcnt example is nice.
0,97,115,109,1,0,0,0,1,138,128,128,128,0,2,96,1,127,1,127,96,0,1,127,3,131, .... 2047
You can edit this as you see fit, or even write it by hand if you want. What's wrong with it? It's the same with native programs. You get your executable, open it in the hex editor, do your thing and run the program, done.
I'm not being entirely serious, but that's because you seem to conflate the tooling's features with the WA, or you simply don't understand what assembly really is. As a "child of the web" it's not strange, but you should at least accept your own lack of knowledge and understanding.
In short: there are two programs involved in the WasmFiddle: a compiler and an assembler. You're saying you want to play with assembler - fair enough, you can do this. That you have to write a disasm for this or learn the opcodes by heart, doesn't mean it's impossible. The thing is, no one other than you cares (it's a lie - there are people with a justified, practical interest in this, but it's almost certain you're not one of them) because it's hard and the compiler is going to make a better job at it than you anyway.
In other words, you're saying you don't like WebAssembly because it's an assembler. It's not a problem with WA, but with your expectations.
EDIT: shortened assembly output to make the rest of the post readable.
As someone who at one point in his life had a lot of fun writing Z80 for his TI-83+, I do wonder how bit a "market" for a WASM environment oriented towards human editing of the assembly might be. It's probably being built anyway, for the compiler writers. The question is if it might "break out" to other enthusiasts.
It's easy to forget that before higher level languages, assembly was the norm. Assembly at the time was more "human-friendly" to program in too; if you're comfy with C and pointers, going a bit lower really isn't that scary. It's just that the decades of x86 extensions have created hugely complicated beasts that few sane people would dare touch. However, the forty or so z80 opcodes are quick to memorise. I've heard that ARM and 68k is "fun" to work with too (for a certain type of programmer, obviously).
Anyway, the s-expression form of WASM feels like a throwback to the more human friendly CPU days, presumably also because it has to be so platform-independent (and because SIMD isn't in yet). I'm sure there will be enthusiasts playing with it.
I really hope better toolchains will appear.
Emscripten seems to be a collection of weird hacks.
Oh, no, you meant all the official browsers of our corporate masters. Sooner or later they'll all be one.