9 ms·

On “On Asm.js”

98 points by bpierre 13y ago

avmich 13y ago
I see the point; but I don't think it has enough justification. Something evolutionary successful isn't always globally perfect - rather it's most probable along the path from there to here. JavaScript may stay long with us. Or - as sometimes happens - it could be eclipsed in few years, as happened with technologies and paradigms before. Say, guessing correctly on technologies in use in 2000, sitting in 1990, would be quite hard. Not that "more direct approach" of defining bytecode and standardizing should always be better. With ideas disruptive enough many bets are off.
- derefr 13y ago
  But it seems to me that "evolving into" the use of other languages through Javascript, will allow us to start ignoring the fact that it's Javascript in particular that we're targeting--such that, one day soon, the browser-makers will just give us a "shortcut" to doing the things that have already evolved, without all the Javascript-y mess in-between. But something has to get popular first as a new "open web-scripting language", before the browser-makers will be willing to all go in on supporting it. (Otherwise you get the reactions you see by, e.g., Mozilla to Google's NaCl.) And that was a chicken-and-egg problem until now, because you can't really create and force universal adoption of an "open web-scripting language" (or framework, or platform, or bytecode, etc.) if you're just one company. But now, with asm.js, you can--and the rest of the steps will follow soon after.
oddshocks 13y ago
Damn that site is gorgeous yo
skwosh 13y ago
Onanism?
dgregd 13y ago
> I see plenty of reason to keep betting on evolution So why Mozilla helped to kill WebSQL? Because NoSQL (IndexedDB) is so much better than SQLite? Mozilla is too much focused on Brendan Eich baby. They should really move forward because JavaScript is becoming new IE6.
- azakai 13y ago
  WebSQL was a completely separate debate, if I recall correctly, the issues there had to do with WebSQL being heavily dependent on SQLite, a single implementation. So it was hard to spec in a vendor-independent way like web standards require. IndexedDB is much less capable than SQLite, no doubt about it, but still very useful, and far far simpler and feasible to spec and standardize (which it has been).
  - Touche 13y ago
    In what way is it less capable?
    - azakai 13y ago
      SQLite supports a pretty comprehensive query language including joins, sorts, filtering, etc etc. It's a full RDBMS.
  - dgregd 13y ago
    It is another case where they make fundamentally bad decision. In case of WebSQL, 40 years of legacy is not important. Millions business apps developers needs are not important. Clean and nice spec is more important for Mozilla guys. However in case of Brendan Eich baby, legacy is very important. Ugly hacks like asm.js, without W3 specs, are promoted. Try to guess why.
  - iso-8859-1 13y ago
    But SQL is already standardized! They just have to determine a reasonable subset of the existing standard.
sirsar 13y ago
> On his impossibly beautiful blog I found the parallax background incredibly distracting. Maybe I just lack focusing skills, but I would much rather read a plain text file than have a slightly laggy background change every time I scroll.
- SkyMarshal 13y ago
  I'm more than happy to make the effort to read a blog that pushes the limits with JS/CSS/HTML the way acko's blog does, even if it marginally decreases readability. I spend more time reading the source than the articles anyway. Think of acko.net as a tech demo first, blog second.
- EpicEng 13y ago
  It also blinks black for me every time I scroll (latest Chrome on OSX ML)
pornel 13y ago
In this exchange UTF-8 got dragged into list of ugly hacks, but it is a beautiful hack. Endian-independent, more efficient than UTF-16 for most languages (often including CJK web pages: halved cost of HTML & URLs makes up for 33% extra text cost), supports easy and safe substring search, can detect cut characters, and all that with ASCII and C-string backwards-compatibility. If I could redesign entire computing platform from scratch UTF-8 is one thing I wouldn't change.
- pilif 13y ago
  The disadvantage of utf-8 is that it's a variable length encoding. This means that certain operations which are usually O(1) are O(n) with UTF-8: one is finding the n-th character in a string, the other is finding the length in characters (though that's also true for null terminated C strings) Another problem is that swapping a character in a string might cause the (byte) length of the string to change, which might force a reallocation (also slow) and if you're doing it in a loop over the string, your loop-ending condition might now have changed because the string (byte) length has changed. In-fact, iterating over a UTF-8 strings characters is not something you can use a simple for loop any more, but something that requires at least one, possibly two function calls per character (one to find the next character, one for finding the end of the string which might just have moved due to your modification). Finally, efficiency: For English texts, UTF8 is the most efficient Unicode encoding, but for other languages, that isn't true. A Chinese text would require three to four bytes per character, as opposed to just two in UCS-2 (which is what most OSes and languages use, even though it doesn't support encoding all of Unicode) For these reasons, dealing with a fixed-length encoding is much more convenient (and speedier) while the string is loaded into memory. UTF8 is great for i/o and storage on disk, but in memory, it's inconvenient. UCS-2 or UTF-16 is the reverse: it's very inconvenient on disk and for i/o (need I say more than BOM), but in-memory UCS-2 is very convenient, even though it doesn't support all of Unicode. It's in-fact so convenient that it's used by most programming environments (see yesterday's discussion about strings being broken) Take python 3.3 and later for example: even though they now have full support for Unicode, also for characters outside of the BMP and thus requiring more than two bytes of storage, they didn't go with a variable length in-memory encoding, but they now chose the shortest width possible fixed length encoding that can be used for a particular string. This seems like an awful lot of work to me, but they decided the fixed-lengthness was still worth it.
jheriko 13y ago
"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterly lacking, and there is a lack of focus on developing mechanisms to deploy native code /directly/ across the web. Don't kid yourself either - all the data being thrown around at the moment is always (always, always, always otherwise it wouldn't even work!) translated into native code in some way - we are already throwing native code around the web, just in a horribly inefficient way. In todays world of sandboxing and virtualisation all of the security arguments that used to be completely reasonable are quite thoroughly invalidated. I really do believe that fixing this from the technical perspective is not an impossible or even hard problem to solve - I can not stress this point enough. Game developers are constantly re-solving this problem in limited, optimisation focused ways. JavaScript implementations themselves are ultimately built on top of this technology or other technologies built on top of it. The standard libraries of modern scripting languages are possible to use from within the constraints of C. We have already solved all of these problems and there are myriad examples. On the other hand, the political problem could be intractable... and thats sad. Worst of all perhaps, C can be made better for performance without much thought or effort, and none of the new languages I see actually tackle this problem, which is quite real and measurable and impacts everything from productivity to the environment - they (quite rightly in many ways) focus utterly on ease of use and massive standard libraries. Why can't we focus this effort on fixing C, or providing a better alternative? Why are we trying to catchup with native code performance instead of using just native code? Why aren't we improving native code performance in a serious way?
- steveklabnik 13y ago
  JavaScript is sandboxed, and safe. C......... isn't.
  - jheriko 13y ago
    but it trivially can be - this is very measurable and lots of people do it. see for instance iOS, OS X, Android, Windows 8... actually I can just list the modern operating systems that don't provide such an environment out of the box: (end of list)
fdej 13y ago
Naive question: is there a reason why we cannot just compile programs to both native/bytecode and javascript and have browsers automatically fetch the version they support? If it turns out that native/bytecode universally runs (say) 20% faster and loads in half the time, the javascript target will eventually die a natural death of obsolescence without compatibility ever being sacrificed. If it turns out that the javascript target can keep up with the performance native/bytecode, then we can just stop compiling to anything but javascript, and nothing will be lost. The attitude that we should not even try to do better than compiling to javascript just seems odd.
- steveklabnik 13y ago
  This scenario assumes that browser vendors have the time and employees to work on a JavaScript and a WhateverScript VM.
  - CmonDev 13y ago
    "WhateverScript VM" - you mean kind of like Dart VM for Chrome by Google?
    - steveklabnik 13y ago
      Yup. Only one organization in the world has the resources and desire. I don't want a Google-run future.
      - CmonDev 13y ago
        I don't care if it's just Google or Google + Mozilla + some bunch of other guys. At least with Dart I can see the difference and it took a couple of years to implement instead of a dozen of years. I hope Dart will get some traction so that other players will be innovating again instead of relying on legacy languages.
- PeterisP 13y ago
  We can do that - I mean, it's a chicken and egg problem; browsers don't support proper bytecode because there's not a particular mass of software that needs that support, and there won't be a mass of software until the support exists on most browsers. Asm.js provides a 'fake egg' that can be hatched by the already existing JS support - but once there is enough software being built through, say, LLVM to asm.js, then it would make sense for a browser vendor to provide a feature "supply alternative bytecode built by the exact same compiler toolchain, and you'll get 50% better performance".

98 points by bpierre 13y ago

I see the point; but I don't think it has enough justification. Something evolutionary successful isn't always globally perfect - rather it's most probable along the path from there to here. JavaScript may stay long with us. Or - as sometimes happens - it could be eclipsed in few years, as happened with technologies and paradigms before. Say, guessing correctly on technologies in use in 2000, sitting in 1990, would be quite hard. Not that "more direct approach" of defining bytecode and standardizing should always be better. With ideas disruptive enough many bets are off.

derefr 13y ago
But it seems to me that "evolving into" the use of other languages through Javascript, will allow us to start ignoring the fact that it's Javascript in particular that we're targeting--such that, one day soon, the browser-makers will just give us a "shortcut" to doing the things that have already evolved, without all the Javascript-y mess in-between. But something has to get popular first as a new "open web-scripting language", before the browser-makers will be willing to all go in on supporting it. (Otherwise you get the reactions you see by, e.g., Mozilla to Google's NaCl.) And that was a chicken-and-egg problem until now, because you can't really create and force universal adoption of an "open web-scripting language" (or framework, or platform, or bytecode, etc.) if you're just one company. But now, with asm.js, you can--and the rest of the steps will follow soon after.

oddshocks 13y ago

Damn that site is gorgeous yo

skwosh 13y ago

Onanism?

dgregd 13y ago

> I see plenty of reason to keep betting on evolution So why Mozilla helped to kill WebSQL? Because NoSQL (IndexedDB) is so much better than SQLite? Mozilla is too much focused on Brendan Eich baby. They should really move forward because JavaScript is becoming new IE6.

azakai 13y ago
WebSQL was a completely separate debate, if I recall correctly, the issues there had to do with WebSQL being heavily dependent on SQLite, a single implementation. So it was hard to spec in a vendor-independent way like web standards require. IndexedDB is much less capable than SQLite, no doubt about it, but still very useful, and far far simpler and feasible to spec and standardize (which it has been).
- Touche 13y ago
  In what way is it less capable?
  - azakai 13y ago
    SQLite supports a pretty comprehensive query language including joins, sorts, filtering, etc etc. It's a full RDBMS.
- dgregd 13y ago
  It is another case where they make fundamentally bad decision. In case of WebSQL, 40 years of legacy is not important. Millions business apps developers needs are not important. Clean and nice spec is more important for Mozilla guys. However in case of Brendan Eich baby, legacy is very important. Ugly hacks like asm.js, without W3 specs, are promoted. Try to guess why.
- iso-8859-1 13y ago
  But SQL is already standardized! They just have to determine a reasonable subset of the existing standard.

sirsar 13y ago

> On his impossibly beautiful blog I found the parallax background incredibly distracting. Maybe I just lack focusing skills, but I would much rather read a plain text file than have a slightly laggy background change every time I scroll.

SkyMarshal 13y ago
I'm more than happy to make the effort to read a blog that pushes the limits with JS/CSS/HTML the way acko's blog does, even if it marginally decreases readability. I spend more time reading the source than the articles anyway. Think of acko.net as a tech demo first, blog second.
EpicEng 13y ago
It also blinks black for me every time I scroll (latest Chrome on OSX ML)

pornel 13y ago

In this exchange UTF-8 got dragged into list of ugly hacks, but it is a beautiful hack. Endian-independent, more efficient than UTF-16 for most languages (often including CJK web pages: halved cost of HTML & URLs makes up for 33% extra text cost), supports easy and safe substring search, can detect cut characters, and all that with ASCII and C-string backwards-compatibility. If I could redesign entire computing platform from scratch UTF-8 is one thing I wouldn't change.

pilif 13y ago
The disadvantage of utf-8 is that it's a variable length encoding. This means that certain operations which are usually O(1) are O(n) with UTF-8: one is finding the n-th character in a string, the other is finding the length in characters (though that's also true for null terminated C strings) Another problem is that swapping a character in a string might cause the (byte) length of the string to change, which might force a reallocation (also slow) and if you're doing it in a loop over the string, your loop-ending condition might now have changed because the string (byte) length has changed. In-fact, iterating over a UTF-8 strings characters is not something you can use a simple for loop any more, but something that requires at least one, possibly two function calls per character (one to find the next character, one for finding the end of the string which might just have moved due to your modification). Finally, efficiency: For English texts, UTF8 is the most efficient Unicode encoding, but for other languages, that isn't true. A Chinese text would require three to four bytes per character, as opposed to just two in UCS-2 (which is what most OSes and languages use, even though it doesn't support encoding all of Unicode) For these reasons, dealing with a fixed-length encoding is much more convenient (and speedier) while the string is loaded into memory. UTF8 is great for i/o and storage on disk, but in memory, it's inconvenient. UCS-2 or UTF-16 is the reverse: it's very inconvenient on disk and for i/o (need I say more than BOM), but in-memory UCS-2 is very convenient, even though it doesn't support all of Unicode. It's in-fact so convenient that it's used by most programming environments (see yesterday's discussion about strings being broken) Take python 3.3 and later for example: even though they now have full support for Unicode, also for characters outside of the BMP and thus requiring more than two bytes of storage, they didn't go with a variable length in-memory encoding, but they now chose the shortest width possible fixed length encoding that can be used for a particular string. This seems like an awful lot of work to me, but they decided the fixed-lengthness was still worth it.

jheriko 13y ago

"On a shared medium like the web, where content has to run across all OSes, platforms, and browsers, backwards-compatible strategies are far more likely to succeed than discrete jumps." This is a valid point, but hits on something that constantly grates with me. We already have something massively more cross platform and performance focused than JavaScript - C. The problem is that the standard library for C is utterly lacking, and there is a lack of focus on developing mechanisms to deploy native code /directly/ across the web. Don't kid yourself either - all the data being thrown around at the moment is always (always, always, always otherwise it wouldn't even work!) translated into native code in some way - we are already throwing native code around the web, just in a horribly inefficient way. In todays world of sandboxing and virtualisation all of the security arguments that used to be completely reasonable are quite thoroughly invalidated. I really do believe that fixing this from the technical perspective is not an impossible or even hard problem to solve - I can not stress this point enough. Game developers are constantly re-solving this problem in limited, optimisation focused ways. JavaScript implementations themselves are ultimately built on top of this technology or other technologies built on top of it. The standard libraries of modern scripting languages are possible to use from within the constraints of C. We have already solved all of these problems and there are myriad examples. On the other hand, the political problem could be intractable... and thats sad. Worst of all perhaps, C can be made better for performance without much thought or effort, and none of the new languages I see actually tackle this problem, which is quite real and measurable and impacts everything from productivity to the environment - they (quite rightly in many ways) focus utterly on ease of use and massive standard libraries. Why can't we focus this effort on fixing C, or providing a better alternative? Why are we trying to catchup with native code performance instead of using just native code? Why aren't we improving native code performance in a serious way?

steveklabnik 13y ago
JavaScript is sandboxed, and safe. C......... isn't.
- jheriko 13y ago
  but it trivially can be - this is very measurable and lots of people do it. see for instance iOS, OS X, Android, Windows 8... actually I can just list the modern operating systems that don't provide such an environment out of the box: (end of list)

fdej 13y ago

Naive question: is there a reason why we cannot just compile programs to both native/bytecode and javascript and have browsers automatically fetch the version they support? If it turns out that native/bytecode universally runs (say) 20% faster and loads in half the time, the javascript target will eventually die a natural death of obsolescence without compatibility ever being sacrificed. If it turns out that the javascript target can keep up with the performance native/bytecode, then we can just stop compiling to anything but javascript, and nothing will be lost. The attitude that we should not even try to do better than compiling to javascript just seems odd.

steveklabnik 13y ago
This scenario assumes that browser vendors have the time and employees to work on a JavaScript and a WhateverScript VM.
- CmonDev 13y ago
  "WhateverScript VM" - you mean kind of like Dart VM for Chrome by Google?
  - steveklabnik 13y ago
    Yup. Only one organization in the world has the resources and desire. I don't want a Google-run future.
    - CmonDev 13y ago
      I don't care if it's just Google or Google + Mozilla + some bunch of other guys. At least with Dart I can see the difference and it took a couple of years to implement instead of a dozen of years. I hope Dart will get some traction so that other players will be innovating again instead of relying on legacy languages.
PeterisP 13y ago
We can do that - I mean, it's a chicken and egg problem; browsers don't support proper bytecode because there's not a particular mass of software that needs that support, and there won't be a mass of software until the support exists on most browsers. Asm.js provides a 'fake egg' that can be hatched by the already existing JS support - but once there is enough software being built through, say, LLVM to asm.js, then it would make sense for a browser vendor to provide a feature "supply alternative bytecode built by the exact same compiler toolchain, and you'll get 50% better performance".