I've been reading on Emscripten and LDC and how they would be nice together, and came across this nice little library:
http://www.leaningtech.com/duetto/examples/

It's a C++ server/client framework that compiles to JS through clang => LLVM bytecode => ASM.js.

I'd like to point out that asm.js is a very fast subset of the javascript language that allows almost native speeds (3x slowdown vs C only) which enables games to be run in the browser without external dependencies.

This had me thinking of forking the Emscripten project in order to support the druntime / phobos library & give it access to the browser DOM interface, as to allow javascript web applications to be written fully in D (to produce interfaces like openUI5 and more).

This would have multiple advantages:
- Suitable for huge front-end development frameworks using safe typing and contractual programming
- Opens the door to petaFLOPS of distributed CPU power based simply on website visitation without affecting user experience
- Allows Javascript proprietary code to be harder to de-obfuscate or reverse engineer
- FAST Browser-based database engines and full runtime capabilities can be developed (and added as browser extensions for persistence) to be actively used by the server with a simple interface

And most of all, it simplifies web development.

I'm not going to instantly call for a project to be started, but I'd love to hear some why do's and why don'ts b/c I don't like to rely on my point of view alone.

> I'd like to point out that asm.js is a very fast subset of the javascript language that allows almost native speeds (3x slowdown vs C only) which enables games to be run in the browser without external dependencies.

It also doesn't do multithreading, as far as I know. Also three times slower for peak performance is not near-native. It's bullshit Mozilla marketing. (They actually use the expression "2x the speed", yes, it's hilarious.)

And I still think the browser is a terrible platform for anything but small flashgames-like games.

> - Opens the door to petaFLOPS of distributed CPU power based simply on website visitation without affecting user experience

If you have JS doing heavy computation on your website for every visitor, I'm sure you'll soon run out of visitors to reach that number, because that's not a very nice thing to do. It does affect user experience.

> - Allows Javascript proprietary code to be harder to de-obfuscate or reverse engineer

That's not an advantage. That's terrible. Please stop.

> - FAST Browser-based database engines and full runtime capabilities can be developed (and added as browser extensions for persistence) to be actively used by the server with a simple interface

"Fast". For reference: If some JS-thing says "fast", it usually means "it's not quite so terrible as before". Also, are you suggesting that putting a database on the client browser, and then having a server call that for data is a good idea and fast?

> And most of all, it simplifies web development.

Hardly.

The only good idea that I see in this is that it allows you to do client-side web-development without having to use JS.

On 2014-05-13 1:30 PM, Nicolas F. wrote:
>
>
> The only good idea that I see in this is that it allows you to do
> client-side web-development without having to use J

I do believe it would allow some web frameworks and UI projects to run faster by reducing the massive use of fallback scopes and HashMaps. Also, nothing says a thread pool won't be in the works if it becomes necessary. JS has the advantage of running in every single web browsers out there regardless of the OS, and for platforms like the Chrome OS that only run JS/HTML, it's also going to be an important tool.

Don't get me wrong, I do believe javascript is a horrible technology and I hate how it managed to get there by stacking indirections so much, but it's also what browsers rely on and this is supposed to improve it.

On 5/13/2014 1:38 PM, Etienne wrote:
> and for platforms like the Chrome OS
> that only run JS/HTML, it's also going to be an important tool.
>

I thought Chrome wasn't on-board with asm.js?

On 2014-05-13 2:18 PM, Nick Sabalausky wrote:
> On 5/13/2014 1:38 PM, Etienne wrote:
>> and for platforms like the Chrome OS
>> that only run JS/HTML, it's also going to be an important tool.
>>
>
> I thought Chrome wasn't on-board with asm.js?
>

They are on board, and ironically it runs faster on Chrome's V8 than on Firefox

Am 13.05.2014 20:18, schrieb Nick Sabalausky:
> On 5/13/2014 1:38 PM, Etienne wrote:
>> and for platforms like the Chrome OS
>> that only run JS/HTML, it's also going to be an important tool.
>>
>
> I thought Chrome wasn't on-board with asm.js?
>

They aren't. If you look at Chrome Dashboard, integration of Dart VM is the important stuff going on.

NaCL is already integrated and enabled.

--
Paulo

On 2014-05-13 2:21 PM, Etienne wrote:
> On 2014-05-13 2:18 PM, Nick Sabalausky wrote:
>> On 5/13/2014 1:38 PM, Etienne wrote:
>>> and for platforms like the Chrome OS
>>> that only run JS/HTML, it's also going to be an important tool.
>>>
>>
>> I thought Chrome wasn't on-board with asm.js?
>>
>
> They are on board, and ironically it runs faster on Chrome's V8 than on
> Firefox

Scratch that, I was looking at this:

http://allievi.sssup.it/techblog/wp-content/uploads/2013/05/benchmarks2.png

On 2014-05-13 2:22 PM, Paulo Pinto wrote:
> Am 13.05.2014 20:18, schrieb Nick Sabalausky:
>> On 5/13/2014 1:38 PM, Etienne wrote:
>>> and for platforms like the Chrome OS
>>> that only run JS/HTML, it's also going to be an important tool.
>>>
>>
>> I thought Chrome wasn't on-board with asm.js?
>>
>
> They aren't. If you look at Chrome Dashboard, integration of Dart VM is
> the important stuff going on.
>
> NaCL is already integrated and enabled.
>
> --
> Paulo

It doesn't seem like any work has been in asm.js since a while according to this:

http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps

Dart is very nice, the editor and tools are great, the integration to the browser as well... if only the language and libraries were from D :)

On 14 May 2014 04:22, Paulo Pinto via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am 13.05.2014 20:18, schrieb Nick Sabalausky:
>
>> On 5/13/2014 1:38 PM, Etienne wrote:
>>>
>>> and for platforms like the Chrome OS
>>> that only run JS/HTML, it's also going to be an important tool.
>>>
>>
>> I thought Chrome wasn't on-board with asm.js?
>>
>
> They aren't. If you look at Chrome Dashboard, integration of Dart VM is the important stuff going on.
>
> NaCL is already integrated and enabled.

I'm interested in PNaCl support in LDC, and a bunch of my friends. I reckon we could definitely create a movement there...

On Wednesday, 14 May 2014 at 03:06:52 UTC, Manu via Digitalmars-d wrote:
> On 14 May 2014 04:22, Paulo Pinto via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>> I thought Chrome wasn't on-board with asm.js?

Not officially, but they probably tweak V8.

> I'm interested in PNaCl support in LDC, and a bunch of my friends. I
> reckon we could definitely create a movement there..

Me too. Especially if it is possible to compile to both pnacl and asm.js using the same API.