Maybe you remember the NaCl or PNaCl plug-in from Google, that allows to safely run code at near native speed on the browser (only 10-30% speed loss, in a probably safe sandbox). This plug-in seems interesting, but so far I think it's not getting a lot of traction, and it seems Mozilla is not interested in it.

Now on Reddit they have linked "asm.js". It's an easy to compile subset of JavaScript, that contains type annotations (inside comments, so it's still valid standard JavaScript). Mozilla has created a modified version of its JIT that recognizes asm.js code and compiles it ahead of time to give, they say, about half the speed of native code (if it's not recognized, it's seen as normal JS). Even if this speed will increase a little with time, I think it will keep being a little slower than NaCl code, but maybe for lot of people the speed of asm.js will be enough (and the safety of NaCl is not so certain).

A modified version of Emscripten (a LLVM bytecode to JavaScript compiler) outputs asm.js. So if you have C/C++ code, with Emscripten and some parts of LLVM you compile it to asm.js, and then Firefox Nightly recognizes it (there is an annotation).

So given the LDC2 project, maybe with LDC+Emscripten+asm.js there is a chance to see D on the web. I think someone will be happy to use D instead of C/C++ on the web for performance-sensitive code, like games. This is a small window of opportunity for D.

Bye,
bearophile

On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
> I think someone will be happy to use D instead of C/C++ on the web for performance-sensitive code, like games.

If it compiles to any kind of javascript it is a mistake to think they'll be a performance boost over just writing javascript, with or without annotations. Odds are there will be leaky abstractions in the compile process that can hurt speed.

On Sat, Mar 23, 2013 at 03:34:54AM +0100, Adam D. Ruppe wrote:
> On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
> >I think someone will be happy to use D instead of C/C++ on the web for performance-sensitive code, like games.
> 
> If it compiles to any kind of javascript it is a mistake to think they'll be a performance boost over just writing javascript, with or without annotations. Odds are there will be leaky abstractions in the compile process that can hurt speed.

Any kind of translation from language X to language Y will incur at least the performance overhead of language Y, plus some incidental overhead incurred by non-trivial or imperfect mapping of X's features to Y'es features. This incidental overhead is rarely every zero.

So there is no way translating from language X to language Y will be faster than writing in language Y in the first place, no matter how good your optimizer is. Otherwise, you might as well just write in language Y to begin with, and run the optimizer on *that*.


T

-- 
Nothing in the world is more distasteful to a man than to take the path that leads to himself. -- Herman Hesse

Adam D. Ruppe:

> If it compiles to any kind of javascript it is a mistake to think they'll be a performance boost over just writing javascript, with or without annotations.

The Box3D compiled by Emscripten from C++ code is faster than other translations of Box3D to JavaScript written by more traditional means. Probably because the code produced by Emscripten is very un-idiomatic JS, hard to write manually.

And here we are talking about a version of Emscripten that targets asm.js, that a new JIT of Firefox Nightly digests better.

Bye,
bearophile

Am 23.03.2013 03:34, schrieb Adam D. Ruppe:
> On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
>> I think someone will be happy to use D instead of C/C++ on the web for
>> performance-sensitive code, like games.
>
> If it compiles to any kind of javascript it is a mistake to think
> they'll be a performance boost over just writing javascript, with or
> without annotations. Odds are there will be leaky abstractions in the
> compile process that can hurt speed.

It is actually quite fast.

http://kripken.github.com/mloc_emscripten_talk/#/19

Having said this, compiling code to JavaScript just feels wrong.

Unless the idea is to port legacy code, I don't see any advantage.

Code translation eventually means you might end up trying to understand why something does not work in the target language, while doing a compiler mental model of the translations taking place.

--
Paulo

Paulo Pinto:

> Having said this, compiling code to JavaScript just feels wrong.

I agree. On the other hand going against the trends all the time is not wise.

Bye,
bearophile

On Saturday, 23 March 2013 at 02:39:55 UTC, H. S. Teoh wrote:
> On Sat, Mar 23, 2013 at 03:34:54AM +0100, Adam D. Ruppe wrote:
>> On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
>> >I think someone will be happy to use D instead of C/C++ on the web
>> >for performance-sensitive code, like games.
>> 
>> If it compiles to any kind of javascript it is a mistake to think
>> they'll be a performance boost over just writing javascript, with or
>> without annotations. Odds are there will be leaky abstractions in
>> the compile process that can hurt speed.
>
> Any kind of translation from language X to language Y will incur at
> least the performance overhead of language Y, plus some incidental
> overhead incurred by non-trivial or imperfect mapping of X's features to
> Y'es features. This incidental overhead is rarely every zero.
>
> So there is no way translating from language X to language Y will be
> faster than writing in language Y in the first place, no matter how good
> your optimizer is. Otherwise, you might as well just write in language Y
> to begin with, and run the optimizer on *that*.
>

I don't think you understood the point. asm.js is not the same as js. Pure js isn't involved anywhere along the translation path bearophile proposed except as a side-effect.

On Saturday, 23 March 2013 at 02:39:55 UTC, H. S. Teoh wrote:
> So there is no way translating from language X to language Y will be
> faster than writing in language Y in the first place, no matter how good
> your optimizer is. Otherwise, you might as well just write in language Y
> to begin with, and run the optimizer on *that*.

Too strong of a statement, especially since focus is only strength of optimizer and not also caliber of developers. There is huge benefit and it is one of the big selling points of Dart. You write in a familiar OOP language with great toolset and out comes working javascript. I don't know javascript - I've started to learn a few times but was repelled by it. But most traditional OO programmers can grok Dart in a few days, plus it has great tools. If D could do the same it would be great.

Thanks,
Dan

Dan:

> There is huge benefit and it is one of the big selling points of Dart. You write in a familiar OOP language with great toolset and out comes working javascript. I don't know javascript - I've started to learn a few times but was repelled by it. But most traditional OO programmers can grok Dart in a few days, plus it has great tools. If D could do the same it would be great.

I prefer TypeScript. It doesn't require a new JavaScript VM, and it looks designed very well. I am waiting for a TypeScript=>asm.js compiler :-)

Bye,
bearophile

On Sat, 23 Mar 2013 14:22:04 +0100
"bearophile" <bearophileHUGS@lycos.com> wrote:

> Dan:
> 
> > There is huge benefit and it is one of the big selling points of Dart. You write in a familiar OOP language with great toolset and out comes working javascript. I don't know javascript - I've started to learn a few times but was repelled by it. But most traditional OO programmers can grok Dart in a few days, plus it has great tools. If D could do the same it would be great.
> 
> I prefer TypeScript. It doesn't require a new JavaScript VM, and it looks designed very well. I am waiting for a TypeScript=>asm.js compiler :-)
> 

While some of this stuff is fairly interesting, if you're doing so much
DHTML that JS's downsides become a problem, then you're doing way
too much DHTML. Time to either:

1. Pre-bake stuff (There are sooo many pages out there that do DOM manipulations or even AJAX requests during page load or "onload". This is, of course, completely moronic because if it's done during/upon page load, it *could* have all been just done ahead of time and baked into the original page. The only thing "during/upon page load" JS ever has any legitimate reason to do, is undo certain "JS-disabled" elements on the page - and even that's only for cases where <noscript> is unsuitable.)

2. Put some of the processing back on the server, where it belongs.

3. Rip the stupid thing out of the web browser, because it's clearly not a goddamn document.