Surprise! Mozilla can produce near-native performance on the Web

We put Mozilla's JavaScript subset—asm.js—to the test.

Read the whole story

 

[Faramir]

I don't understand why people seem to think that every sort of program should run in a browser.

Triple A video games, scientific computing programs, and computer assisted design programs seem particularly ill suited to a web browser strait jacket, that nonetheless people are enthusiastically working on.

The number one answer seems to be that people trust the browsers' sandboxes which seems a) unwarranted and b) overkill for the problem of untrusted code.

 

[Faramir]

styron[/url]":1ugwl425]Now I hardly care, and streaming has some advantages around multiple devices and not having to maintain media libraries etc.

You can stream in programs other than web browsers. In fact, a web browser isn't a terribly great streaming platform.

Apps moving to browsers is the same kind of progression. Yes it kind of sucks at the moment (especially for complex apps), but year by year it sucks less, and the advantages around not having to maintain software start becoming more compelling.

Programs can auto-update themselves without having to run in web browsers. In fact, your web browsers is such a program.

 

[Faramir]

jimjimjimjimjim[/url]":f5jnaze3]

Faramir[/url]":f5jnaze3]I don't understand why people seem to think that every sort of program should run in a browser.

Triple A video games, scientific computing programs, and computer assisted design programs seem particularly ill suited to a web browser strait jacket, that nonetheless people are enthusiastically working on.

The number one answer seems to be that people trust the browsers' sandboxes which seems a) unwarranted and b) overkill for the problem of untrusted code.

The alternative to having everything run in a browser seems to be platform specific apps (iOS, Android, Windows, etc).

Even if the javascript runs identically across platforms you still have to do a lot of customization to deal with radically different display and input hardware. And even after you've done all that what you are left with is strictly inferior to something actually designed for each platform. It is for that reason, among others, you don't see many java swing GUIs, which is the last technology that promised write once, run anywhere.

 

[Faramir]

Tundro Walker[/url]":qda1wk9f]What I think would be interesting is if maybe someone like the W3C came up with a "standardized" javascript usage library. A lot of sites that use javascript do the same things with it... buttons, banners, etc. If there was a standardized library, a page could say something like "look for this standardized, compiled component on user machine first, and if it's not found then snag the component from us, compile it, and keep it in cache for future use (from us and other sites that may use it)." I guess that would be sort of like javascript versions of dll's. Instead of each site dumping their own version into your web cache, they can trim down the javascript to a standardized library for most of the functions. Maybe I'm talking out of my ass here.

HTML have something like this in that more widgets, for lack of a better word, are getting tags that are then left up to the browser implementer to build. So for example, instead of choosing one of the hundred date pickers out there, in a compliant browser you can include: <input type="date"> and the browser chooses a widget that works for its environment. No need to download or parse any javascript for that widget, it's all built into the browser.

 

[Faramir]

Haravikk[/url]":7lshhll9]

Brutha[/url]":7lshhll9]Why can't someone apply the same solutions Apple does with obj-c? v-table lookups, etc?

They do. However, the problem with Javascript isn't just dynamic typing, it's portability and usability; Javascript isn't precompiled, and is instead sent as source code so that any browser that supports Javascript can run it, with no worries about the hardware that a browser is running on.

However, this means that Javascript is completely uncompiled when it enters a user's browser, and as a result compilers can't just compile code to be as optimal as possible, because they also need to be able to compile it quickly (otherwise a site would seem slow and unresponsive).

There are ways to compile Javascript into a runnable binary like C or C++, and these can be pretty fast. Even so, Javascript's free-form dynamic variables and handling of objects can be a bit of a hurdle, as they're even less restrictive than Objective-C's capabilities.

One of the interesting thing about dynamic typing is how rarely the extreme flexibility it offers is actually used.

E.g. you'll almost never see code like this:

var i = 0;
...
i = "Hello World!"

Modern javascript engines exploit this fact, and optimize the heck out of the the i-will-always-be-numeric-path, but they can't get rid of the guards that check to insure that always remains true. The big advantage to static analysis (i.e. compiling) is that you can sometimes get rid of those guards altogether.

 

[Faramir]

Didn't support for PNaCl just land in canary?

 

[Faramir]

Given that c++ is (almost) a superset of c, and assuming that by c++ you mean the language and not the standard library you should be able to write a c in c++ program for most situations that would compile to very similar assembly code.

That said, I think that'd defeat the point of the shoot out.