I know very little about compilers, low-level optimization, or any of these topics beyond a rudimentary understanding of basic computer systems. It speaks volumes that Mozilla is able to explain some of these concepts in ways that I sort-of grasp, even if the specifics mostly go over my head.
Excellent, excellent article. I look forward to more improvements to asm.js and the future of Javascript. Maybe one day I will actually learn this shit.
I'd strongly discourage it. ASM.js is the most horrible hacky thing. It gets the job done, but there are no good things to learn about how it works. Low level and compiler backend optimization are the most hurtful programming problems. It's optimization for a tons of bad reasons. That's like send a car into space. There are no way it's a technology you can reuse later for other purposes.
I'm sure ASM.js must be quite cool to just use, but to understand how it works, I fear that it could get hairy very quickly.
That's why I have my doubts about it. If you run into a problem with ASM.js and there are not enough guidelines, you might run into 10 walls, solve it through, and still run into walls that noone else will have solved before you.
> ASM.js is the most horrible hacky thing. It gets the job done, but there are no good things to learn about how it works.
There's no denying this, ASM.js is an awful hack but that is for a good reason.
You're just going to have to accept the fact that JavaScript will be the only language supported by all major web browsers for the near future. No-one really likes the situation but there's nothing that can really be done about it, at least in the short term.
So if you're doing software for the web browser, it must be compatible with JavaScript. That is a fact you can't escape. And as much as asm.js is a dirty hack, it retains JavaScript compatibility while being a more sensible intermediate representation for compilers.
You're not supposed to like (or dislike) asm.js, it's intended to be written and consumed by computer programs, not humans.
That isn't true. Mozilla likes the situation. That is why they are pushing Javascript so damn hard: as the only language for the web, as the only language for apps, as the only language your phone can run, as the only language your tablet can run and so on. If Mozilla disliked Javascript why would they create an operating system that forces you to use Javascript? None of the backwards compatibility concerns apply there.
It's just politics and a power grab. If all user facing software has to run inside the Javascript sandbox then the people that control that sandbox are given massive power. That is why Mozilla and Google want a web-app future. It hands them the keys to everything. In a web app world if, for example, Microsoft brings out a new input device (like kinect), nobody will actually be able to develop software for it until the gatekeepers of the 'web standards' decide to design an API for it. Since those gatekeepers are mostly Microsofts competitors they would likely block it if they saw it as any kind of threat, or at least till they had developed their own competing version.
Javascript/web standards based OSs will be a huge roadblock to innovation.
> That isn't true. Mozilla likes the situation. That is why they are pushing Javascript so damn hard: as the only language for the web, as the only language for apps, as the only language your phone can run, as the only language your tablet can run and so on. If Mozilla disliked Javascript why would they create an operating system that forces you to use Javascript? None of the backwards compatibility concerns apply there.
What options does Mozilla or any other individual company have here? I think that if they were truly happy with JavaScript, they wouldn't be putting effort into ASM.js and Rust?
Mozilla isn't really pushing JavaScript as the "only language for the web", but they probably are recognizing the fact that they are unable to kill JavaScript or even provide an alternative because that would require all major browser vendors to co-operate (which is not impossible) and all the users to upgrade their browsers (which seems to be impossible judging by the popularity of old browsers like ie6, ie7).
What comes to Firefox OS, it's perhaps a little awkward choice but they are trying to leverage existing web based technologies. Starting from scratch and introducing a new environment with a new programming language would set them behind in terms of time to market and money required to develop the system.
I haven't seen anyone from Mozilla saying out loud that they love JavaScript and they think it's the way forward.
> It's just politics and a power grab. If all user facing software has to run inside the Javascript sandbox then the people that control that sandbox are given massive power.
While this is not entirely impossible, I think the real reason is that there is a JavaScript legacy and abandoning it would be expensive. And Mozilla has invested years of effort and tons of money in making the "web platform" better.
Your impression of this situation is different from mine, and neither of our opinions really matter. You should probably refrain from pushing your personal views as if they were facts.
We work well with Microsoft on Web standards, they are at least as engaged now as their competitors. We are actually having problems getting the missing device and system APIs standardized because Google wants to wait and do its own Chrome-only thing for a while, and Apple is as usual missing in action.
Samsung for Tizen was our best bud, and added battery status, network info, and a few others to WebKit, but then Blink forked and set the cat among the pigeons.
"In a web app world if, for example, Microsoft brings out a new input device (like kinect), nobody will actually be able to develop software for it until the gatekeepers of the 'web standards' decide to design an API for it."
What stops Microsoft (in this example) to implement kinect support in IE as a new API, propose it as a standard and evolve the interface like every other web API - that is, in parallel to the standardization process?
If it's any good, Google and Mozilla will scramble to implement it to prevent users to defect to IE.
Firstly they would be pilloried for having a "proprietary" browser and being "anti-standards".
More importantly, IE can't run on your Firefox OS phone or your ChromeOS chromebook or your iOS tablet. 'Deflecting' to IE would mean buying entirely new hardware (and in the case of phones, probably a new multi-year contract). That isn't an accident. The best way to ensure your browser remains relevant (i.e. you retain veto power over any new standards) is to create OSs that can only run a single browser. You then have millions of users that are locked into your browser to use as bargaining chips.
A world where all user-facing software has to target a single standard gives vast power to the owners of that standard. Very few people seem to be considering this problem. No matter how benevolent you think Google or Mozilla are today, it is madness to place so much trust in them. Their interests do not align with yours, and there are very few checks or balances to the system: end users or independent developers have basically zero say in the web standards process.
You are absolutely correct in your analysis, but you seem to have ended up with a very strange conclusion. The entities who participate in the formulation of open standards do have immense power, this is correct. As opposed to...people who write proprietary software having immense power. Are you actually arguing we return to a closed-door model where individual companies like Apple or Microsoft are the gatekeepers of innovation, as opposed to a process that is at least semi-public and can theoretically be contributed to by anybody?
I actually like it. Write once, run everywhere has become true. Of course there is always room for improvement, but that too is happening (and with a really fast peace too).
> You're not supposed to like (or dislike) asm.js, it's intended to be written and consumed by computer programs, not humans.
The fact it's executed through layers of an OS, a web browser, a javascript parser, an ASM parser, is just worrying. What about libraries ? What about opening files ? What about access to the hardware ?
> There's no denying this, ASM.js is an awful hack but that is for a good reason.
The whole idea is to get around the fact companies will lock their system and force some technologies and languages down the throat of programmers who have other solutions and ideas. You can't completely avoid the restrictions and not run into problems. I don't call that a "good reason". You can solve those problems by finding alternative techs and platform to reach an audience.
If you want to reach everyone who has a modern web browser or equivalent (modern web engines are in many devices now), then the rolling web standards party is the only "alternative tech" outside of native stacks.
Businesses that can afford to port or rewrite for every platform out there are rare. The web replaced Visual C++ / RogueWave windows apps for a reason.
Mobile pulls back toward per-OS apps, but only really to low degree: iOS for "elite consumers" (I didn't make that up), Android in several ways: native for games, some Java apps, and a long tail of PhoneGap-wrapped web apps.
Common among the mobile app approaches are web(view)-based apps and native apps. Emscripten/asm.js handles the latter by cross-compilation. The plugins escape valve for "alternative tech" is gone on mobile, so this is likely to be "it" for a while, IMHO.
The web+mobile composite is an ecosystem. Energy is never free, so apart from enthalpy beating entropy locally, tech that flows downhill usually wins with developers and publishers. Game devs/pubs porting their C++ catalogs to JS via Emscripten is an example of "flowing downhill".
What about opening files? The Web has lots of APIs, more all the time. Firefox OS has local storage, and it has only the web as its platform.
I think asm.js is the greatest runtime design that I have seen over past 20 years. It gets the job done cheaply. That is the ultimate goal for any runtime system. It is not designed for human to write asm.js code manually.
On the other hand, most programming languages are full of hacks. Even simple language like C has all kinds of weird behaviors on different platforms. Someone would need at least 1-2 real world experience before he can become a professional C developer in minimum way. asm.js was developed way faster than any other systems that I can remember.
People are using C#, Java and C++ just fine without understanding MSIL, bytecode and assembly. Asm.js might be a hacky thing but it may be the only way to defeat the dominance of a certain hacky scripting language.
Excellent, excellent article. I look forward to more improvements to asm.js and the future of Javascript. Maybe one day I will actually learn this shit.