The main differences for developers will be the download size for compiled code will be smaller and the startup time will be faster.
Outside of those differences all browsers will consistently optimize for it. At least one upstream compiler backbend (clang/llvm) will support it. So you'll get more tooling from outside of the few folks working on emscripten and you'll more likely see support from language frontends like Swift and Rust.
I don't write "JavaScript" right now. I write Typescript. Most of the front-end ecosystems that I deal with (primarily Aurelia and React) aren't being written in ES5. It's usually ES6/7 and Typescript.
Backend developers already have many languages to choose from, and the communities are doing fine.
My only worry will be in the very beginning when dozens of new languages will compete with each other. In the long run, I think a fistful will survive.
Its true that backend has had this since the dawn of time, but _not_ having that on the frontend allowed it flourish. I agree though that after a certain amount of time, only a few languages will live on.
Wat? This statement is devoid of reason or proof. I hate javascript, but at least explain that Browser adoption + momentum is why people aren't writing client code in python yet.
I think the reason we aren't writing client code in Python yet is at least partially explained later in the article. Even if all browser vendors decided to adopt a new language (say Python) we would still have to support all the older versions around. That's why WebAssebmly is such a great innovation: there's one single compilation target and we can write code in any language suits our needs.
Uh, it's an expansive platform, but it is not even remotely 'well designed'.
The 'barrier to entry' is actually getting worse for basic apps. How many tools must one use? Crazy framworks that keep changing?
'The browser' is the only platform one can develop for these days wherein you have no idea how your app will function 'in the field'. You use a lot of crazy product decisions and compatibility tables to 'estimate' for what % of your audience the app will work.
Behold: the biggest company in the world leaves their browser documentation empty :
https://developer.apple.com/reference/webkitjs/2030049-webki...
All of the limitations of JS described in the article are true. That said, I don't think JS is going anywhere.
But to say that we won't be using it 5 years I think is simply wrong.
For instance, to use my location, my web browser displays a prompt asking if I want to share my location with a web site. I get to decide if I trust a web site.
If a website wants to run an arbitrary bytecode on my computer would it also ask for my permission first? Of course, web browsers interpret arbitrary JavaScript without asking for permission, so this may be a distinction without a difference. But how will vendors implement this?
The most likely scenario, I think, is that in any scenario where WebAssembly is widely adopted it will live side-by-side JavaScript for at least a decade or longer. Vendors will continue to ship JavaScript interpreters - so there's no immediate reason to jump from interpreted to bytecode. Most web sites that use JavaScript don't use that much. Meaning, WebAssembly is an over complication for a very common type of web site, the informational, landing page, photo sharing, blog, etc. In fact, if there's just a few AJAX calls or simple interactions on a site, you'd be an asshole to implement it in WebAssembly. Programming is about removing complexity. Imposing a bytecode compiling tool-chain is unneeded.
Also, we have front-end ecosystems, like the large online collection of jQuery plugins. Want a photo slider? Just drop in the JavaScript include and go. This may be mitigated by compiling jQuery and existing plugins to WebAssembly. (And possibly become part of optimizing front-end assets). But if you're going to use the JavaScript/jQuery ecosystem why would you code just your part in Ruby or Python or some other language? If you were to do this, you would be an asshole. If your ecosystem is JavaScript, write your code in JavaScript. The problem is not the programming language used. The problem is understanding the context (web browser) and interacting with multiple front-end environments, across a wide range of network speeds and devices.
That being said, I've worked on several large projects where writing in one language, compiling to bytecode, and running everywhere would have been awesome.
Assuming wide-spread adoption WebAssembly will probably have the following use cases:
1) Large, complex web apps with a heavy front-end footprint.
2) Used as part of the optimization pipeline. Instead of minifying, combining, and zipping JavaScript, compile to WebAssembly for delivery.
3) Programming tasks/scenarios where JavaScript literally cannot be used due to the limitations of the language.
