Live data from Hacker News

On “On Asm.js”

calculist.org

1–10 of 64 posts

Re: On “On Asm.js”

#2
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.

Re: On “On Asm.js”

#3
post #2

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 b…

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.

Re: On “On Asm.js”

#6
> 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.

Re: On “On Asm.js”

#7
post #6

> 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.

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).

Re: On “On Asm.js”

#8
> 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.

Re: On “On Asm.js”

#9
post #6

> 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.

> Mozilla is too much focused on Brendan Eich baby. They should really move forward because JavaScript is becoming new IE6.

How is a language which all browsers implement comparable to an obsolete browser?

In any case, JavaScript is alive and well. Look at the continuous growth of node.js: http://www.google.com/trends/explore?q=node.js

Re: On “On Asm.js”

#10
post #8

> 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.

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.
Post reply on HN