D => asm.js for the web?

[Nick Sabalausky]

On Sat, 23 Mar 2013 16:55:14 +0100
Jacob Carlborg <doob at me.com> wrote:

> On 2013-03-23 10:02, Paulo Pinto wrote:
> 
> > Having said this, compiling code to JavaScript just feels wrong.
> 
> If you want to run the code in a browser that's basically your only 
> option. Good luck getting all the browser to implement support for
> some new kind of language. In addition to that getting all users to
> update to this version of the browser. It will never happen.
> 

"Never happen"? Nonsense. This is what you do:

Browser devs are obsessed with two things: The speed of their browser,
and blindly imitating each other. So you do this:

1. Make a better language, make it compilable to JS, and also make
an "executes without compiling to JS" browser extension or fork+pull
request for just one browser (or more if you really want, but only
one is needed).

2. Make sure the no-JS-involved version works much better than the
fallback-on-JS version. Luckily, that's easy because being lazy about
it and generating inefficient JS code is totally fair game
here (I actually do mean that, I'm dead serious here).

Remember, most of these Web people are the sorts who firmly believe in
the popular new bandwagon "My time as a developer is far more important
than my user's time; if my code is slow then those mouth-breathing
dinosaurs should just upgrade their computers or fuck off". You could
probably even implement it by compiling "new language" into JS *using*
client-side JS.

Again, I'm dead serious about all that - really hardly anyone will
raise an eyebrow. As long as the language itself (and libs/tooling) is
good enough and convenient enough then most devs will just assume the
speed hit is a natural unavoidable consequence and happily accept it.
(I mean, fuck, they accepted JS and VMs and PHP, etc, didn't they? And
I know people who genuinely believed that iTunes's inability to scroll
smoothly/quickly through your list of songs was just because list of a
few thousand was somehow too much for a 1GHz+, 4GB+ computer to
handle. A laughable notion, of course, to anyone with half a brain, but
people actually believe this shit.) To adapt an old security quote:
"Dancing pigs will win every time."

3. Once the "fallback-to-JS" version catches on (because this new
language *is* worthwhile, isn't it?), then point out to everyone: "Hey,
I've got this extention/pull request/whatever for XXXX browser that
seamlessly makes your 'SuperNewLangauge' webapp far, far faster!"
People will think it's absolutely brilliant and near-magical, and that
you must be a genius. The first browser will adopt it in their mainline
because it's already *right there* for them to fold in since you
already made it for them, and because it gives their browser a huge
instant advantage on all the popular new 'SuperNewLangauge'-based web
apps.

4. As soon as that first browser contains a feature, all the rest will
trip over each other to add it too, because really, when was the last
time a browser developer could actually stand for their browser to not
be blindly dead-identical to every other browser out there? And because
of reigniting the whole "browser speed wars" thing.

(5. W3C will step in and rape the spec into something completely
and utterly moronic. Not to mention excessively convoluted.)