|
This really hinges on the development of WebAssembly, the timeline to getting to a stable release version, and adoption by each browser vendor. 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. |