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.
I'll take the contrarian opinion here, and say that that is a good thing, if only for the fact that it "keeps the target from moving too quickly", as the saying goes.
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.
I take issue with the inference that all attempts at expanding the types of content on the web are needless and "hegemonic," particularly as you're defending the greatest hegemon the web has ever known in making it.
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.
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.
Information is one use case for the web. Apps are another. We agree that if people make apps where a static HTML file would suffice, that's a bad thing. However, for writing apps I think webassembly is going to greatly improve things for developers and users.
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.
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).
My point is that once Microsoft no longer supports any version of Windows that runs IE as it's default there's a very valid reason to stop supporting it as a 'mainstream browser', and using it to avoid technologies that aren't supported by it is somewhat dubious reasoning.
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.
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.
Windows 7 support doesn't end until 2020 and as someone pointed out on HN this a few days ago, Windows 10 IoT and LTSB don't come with Edge, they do come with IE11. Those aren't meant for desktop use but some people do use LTSB there and they could be used for browser-based digital signage, kiosks, etc.
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.
https://www.netmarketshare.com is biased towards US corporate market but doesn't represents the real world. Check wikipedia stats for more generic stats worldwide. What really matters though is the stats of your web site, not the rest. eg. debian.org does not have the same stats as msdn.com.
Having worked for the federal government, let me assure you, Windows 7 will be around for a long time. But let me give a better example: Samsung mobile devices. Since Samsung was so clever in naming their default browser "The Internet", there are a metric ton of folks who will be using that browser on their Galaxy S5s for a few more years. I think many underestimate those two groups, the ones that won't upgrade due to simply misunderstanding the whole mechanism, and the ones that are locked in by government infrastructure.
Those are reasons to offer fallbacks and alternatives for users who don't have access to an up-to-date browser. They're not reasons to ignore modern web technologies that are a good fit for the problem you're solving.
End of patch support of Windows 7 is 2020, of Windows 8 is 2023, of Windows 10 Mobile is 2020, of rest of Windows 10 is 2025. No one cares about your PR speak.
So, is Windows 10 not really the last major release? Or do they have an end of service date for it just as a formality, and it'll probably get extended repeatedly?
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...
I swear “supports all browsers” always means “supports all modern browsers”. No one seems to realize what Enterpriss deployments means anymore. Windows 7 deployments just finished for a bunch of those users and there is a huge cost to move to windows 10 or even adding a modern browser to your deployment.
Wow, I was about to dismiss your comment because one would have to be some sort of sadomasochist to actually seek out IE 11 on a Windows 10 machine and use it on purpose.
But according to Netmarketshare, fully 7% of Windows 10 users use IE.
I'm sure you could, but wouldn't the added overhead defeat the purpose of using either WASM or asm.js? Serious question, because if this could work it's a fun example of "turtles all the way down" in programming.
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.
well it's supposed to be a fallback...you are aware that a fallback is just something better than nothing, right? There are several prototypes already (i.e. https://github.com/lukewagner/polyfill-prototype-1 )
Of course, but I'm basically asking which of the two possible fallbacks would be better:
- 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 seems like we're never going to get away from the paradigm of developing for the web, then doing something else to cater to Microsoft's backwards problem child.
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.
> doing something else to cater to Microsoft's backwards problem child
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.
This confirms that the root problem is distribution. Even when you have an "evergreen" platform like Chrome, you can hobble it by requiring deployment through a central IT team. This also opens up attack vectors against the organisation.
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.
> 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).
We should sometimes pause, and think about the disadvantages a new technique will bring to the web.
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.
I am a C coder, and I cannot wait to have my code on the web, decimating inferior languages like JavaScript. If a startup relies on JavaScript to keep out competition from C coders, well, too bad. They will be decimated in terms of performance. The web will be ruled by the best performing apps written in the language of the Linux kernel.
Performance in web apps is not a goalpost for everybody. While there's certainly web apps that are problematic in terms of performance, you're unlikely to be running at 100% CPU the whole time, so it's not like using C will be the right solution.
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.
>Performance in web apps is not a goalpost for everybody.
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.
True, but in my experience bad UI response times are more related to something goddamned dumb like running a series of super expensive scroll events or watching DOM changes for some idiotic reason, more than about raw processing power.
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.
>I am a C coder, and I cannot wait to have my code on the web, decimating inferior languages like JavaScript.
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.
afaik you can not just take a C++ blob, compile to WebASM and be done. Your business logic can be there, but the User Interface would still need to be JS and HTML in the end, unless you want your app to just draw to a canvas, but even that would only work if you rewrote the rendering as webasm has no access to OS level libraries
>unless you want your app to just draw to a canvas,
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.
not sure if that's a viable alternative for the web. It will most likely consume more computing resources which makes it hard on mobile and the responsive web goes out of the window.
It can make sense for certain interactive elements though.
The rendering of (html+css) to the screen already uses resources on regular web browsing. This wouldn't be needed (if using a GUI toolkit under Webassembly) and could probably run much faster.
Native DOM support might come later, but there's nothing stopping you from importing/exporting Javascript functions to WASM. Cheerp does this for example [1].
Unless you have a good reason, I urge you to never do that. Even ignoring accessibility (which is pretty much completely ruined in this situation no matter what), you'll need to reinvent every single primitive widget you need yourself and have it work the same as it does on all platforms.
That's a shitload of code shipped to the user before you even write a single byte of code for your application!
If you write all the rendering yourself, you can just output to a canvas but that kind of defeats the purpose. Having a JS layer for WebGL that calls into WEBASM for calculations etc should work fine though.
The amount of vigor you espouse an opinion with is astounding relative to how little you know. The point of WASM isn't for you to hand-edit things. It's to provide a unified IR that many lanugages can target (C, C++, Rust being just the beginning). Any language that compiles to LLVM bytecode today can theoretically target the browser now. One thing those languages I mention have in common? They don't use a garbage collector. AKA, you can now write code that will run in the browser with predictable latency semantics.
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.
But you can, of course! In the WasmFiddle, which I see for the first time in my life, if you put a `log(wasmCode)` on the right side, you'll see something like this printed:
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.
> or you simply don't understand what assembly really is
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.
Yes, WebAssembly is bytecode that is a IR compile target for other languages, which right now is limited to C and C++ via Emscripten, or Rust via its own normal toolchain or Emscripten as well. It has a plain text assembly output called WAT, but its not really meant to be handwritten, but rather reviewed as a build artifact.
You can see an examples in Rust including the readable Wat output here:
I've got to admit, I'm really clueless about these things
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)
The first upside is WebAssembly is designed to run C++ at close to native <10% overhead. The WASM team is starting with that foundation then adding features needed for GC and cross language API access (DOM). This is as opposed the Java and C# byte codes which come with a lot of assumptions baked in.
If I can't just type it and see the result, I am not much interested. I don't like to install software. As a child of the web, my feet are firmly planted into the cloud.
You can do that but why would you want to? The tool you're looking for is wat2wasm, which converts the human readable WAT source to WASM binary, and here [0] is an online tool if you want to tinker with it.
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:
I like this answer a lot more than the other ones that are just dismissive.
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.
> Would being able to tinker with WASM not help development of compilers?
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.
I can understand the nostalgia, but that just isn't really true anymore for a lot of front-end web development.
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.
> I don't like to install software. As a child of the web, my feet are firmly planted into the cloud.
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 care if jsfiddle still exists tomorrow. I just use it to quickly try something and immediately share it with others.
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 own the virtual thing. It's my data. Yes, the vendor could illegaly tamper with it. Or legaly stop providing me service. But the beauty of the cloud is that it would not affect me. Because I can replace any vendor with a click.
> I own many machines in the cloud. They are beautiful.
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.
As someone who learned programming as the web grow, I was like you, but I now I see WebAssembly as the future of the web. Lots of amazing and horrible things will emerge. It's better to catch up now, than 2 years later when it will be everywhere.
BTW you DON'T need WA if you don't have performance issues with your current web application.
"There is a principle which is a bar against all information, which is proof against all arguments and which cannot fail to keep a man in everlasting ignorance—that principle is contempt prior to investigation." -William Paley
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.