On Sat, 23 Mar 2013 22:44:39 +0100
Paulo Pinto <pjmlp@progtools.org> wrote:

> Am 23.03.2013 20:09, schrieb Nick Sabalausky:
> > On Sat, 23 Mar 2013 15:07:58 -0400
> > Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> >
> >> On Sat, 23 Mar 2013 19:29:55 +0100
> >> Paulo Pinto <pjmlp@progtools.org> wrote:
> >>>
> >>> And don't get me started to discuss about customers that only pay projects when the web application is pixel perfect with the given Photoshop design.
> >>>
> >>
> >> if(request.userAgent == "IE" && request.ip in
> >> paityHairedIPAddresses) {
> >>      response.send(smokeAndMirrors());
> >> }
> >> else
> >> {
> >>      response.send(normalSite());
> >> }
> >>
> >
> > Ugh, stupid buggy NG client. Ignore this semi-duplicate post...
> >
> 
> You forgot the thousand and one versions of Webkit available around the web.
> 

Yea, I guess my key point was the "request.ip in
paityHairedIPAddresses". I was just thinking "graphic designer
who expects pixel-perfect == doesn't know what a web browser is ==
always uses IE". But then, "graphic designer" tends to imply Mac
anyway, as Mac has always tended to be the artist-type's OS, so no IE.

> I already had to explain to a few customers why Safari on Windows, Mac OS X, iOS on iPhone and on iPad all have different behaviours, even though it is always "Safari Browser".

Heh, I think the first explanation I would have tried would've been "They're all different *because* it's Safari." :) Not necessarily to bash on Safari, but whatever makes the dumb questions go away ;)

"They're different because they're different, dammit! Now shaddup and lemme finish making your stupid little site..."  <-- Heh, if only we could get away with that...

"They're different because the people who make browsers just like to piss me off."

Tons 'o fun to be had with that one!

On Saturday, 23 March 2013 at 02:34:56 UTC, 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.

The DeltaBlue benchmark written in Dart, translated to JS using dart2js, and run on V8 actually just started running faster than handwritten JS running on V8.

http://www.dartlang.org/performance/#

Of course, the handwritten JS could be optimized to match whatever dart2js is doing but it's an interesting result.

On 2013-03-23 18:47, Nick Sabalausky wrote:

> Totally different domain. We're talking about replacing JS due to JS's
> problems when used heavily. Any site that uses JS that heavily in the
> first place wouldn't be working on IE6 anyway. So, if you're making
> such a JS-heavy site that a "NewJS" could even matter at all, then
> you've *already* made the decision (explicitly or implicitly,
> ill-advised or not) to not support IE6.
>
> In other words, a site that needs to work on IE6 isn't going to
> be JS-heavy enough to benefit from "NewJS". Therefore,
> the whole issue of a "NewJS" isn't relevant to IE6 at all.

What I mean is that users don't upgrade to the latest version of their browser.

-- 
/Jacob Carlborg

On Sun, 24 Mar 2013 11:03:16 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-03-23 18:47, Nick Sabalausky wrote:
> 
> > Totally different domain. We're talking about replacing JS due to JS's problems when used heavily. Any site that uses JS that heavily in the first place wouldn't be working on IE6 anyway. So, if you're making such a JS-heavy site that a "NewJS" could even matter at all, then you've *already* made the decision (explicitly or implicitly, ill-advised or not) to not support IE6.
> >
> > In other words, a site that needs to work on IE6 isn't going to
> > be JS-heavy enough to benefit from "NewJS". Therefore,
> > the whole issue of a "NewJS" isn't relevant to IE6 at all.
> 
> What I mean is that users don't upgrade to the latest version of their browser.
> 

That's why there's the "fallback to JS" stuff.

On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
>
> 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


I think this is very interesting but needs a dedicated site with some awesome examples, otherwise it will just be a nice idea.

Maybe vibe.d could play a significant role here.

back to the original, will d compile to asm.js?




On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
> 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 03/28/2013 04:47 PM, Kirill wrote:
> back to the original, will d compile to asm.js?
> ...

Eventually.

ABA-san tried LDC+Emscripten+asm.js.

http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese)

LDC has some limitations but this SDL code works :)


Masahiro

On Saturday, 23 March 2013 at 02:20:33 UTC, bearophile wrote:
>
> 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

Masahiro Nakagawa:

> ABA-san tried LDC+Emscripten+asm.js.
>
> http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese)
>
> LDC has some limitations but this SDL code works :)
>
>
> Masahiro

Very good.

Is is visible the resulting javascript able to run on the browswer?


This is a part translated with Google Translate:

>Problem of the time being, where is moss Emscripten writing class as I wrote at the beginning. The moss just write an empty class that does not contain anything that I downright difficult. I guess the difference is the treatment of class in Clang and LDC.<


What's the problem with classes and LDC?

Bye,
bearophile

On Sunday, 31 March 2013 at 12:56:46 UTC, bearophile wrote:
> Masahiro Nakagawa:
>
>> ABA-san tried LDC+Emscripten+asm.js.
>>
>> http://d.hatena.ne.jp/ABA/20130331#p1 (in japanese)
>>
>> LDC has some limitations but this SDL code works :)
>>
>>
>> Masahiro
>
> Very good.
>
> Is is visible the resulting javascript able to run on the browswer?

Yes. The window which has "Nightly" menu in top picture is his browser.

> This is a part translated with Google Translate:
>
>>Problem of the time being, where is moss Emscripten writing class as I wrote at the beginning. The moss just write an empty class that does not contain anything that I downright difficult. I guess the difference is the treatment of class in Clang and LDC.<
>
>
> What's the problem with classes and LDC?

I'm not sure.

He tried to use D's class but translating LLVM to JavaScript via Emscripten failed.
He guesses internal class representation is different between LDC and Clang.