> interop can be 10x faster
except JavaScript interop. I meant D<->WASM

On Monday, 27 May 2019 at 15:30:46 UTC, KnightMare wrote:
> proxies of outer objects in wasm space will solve interop from inside.

Yes, I know. In fact, I just wrote that for my blog thing this week:


export extern(C) void magic() {
        document.insertAdjacentHTML("beforeend", "cool!<span id=\"beans\">beans</span>");

        auto e = document.querySelector("span");
        e.insertAdjacentHTML("beforeend", " man");
}

That D runs as wasm and yields this page: http://arsdnet.net/wasm/test.html (see source for the JS glue there too)


It is doable and not too bloated, but, I don't love it still and it used a couple filthy hacks regardless. idk though I might spend more time on it.

Of course, you could use the emscripten thing now to do a bunch of in-browser web app stuff.

> with 2 such things Dlang will rise to heaven - scripting, protocol adapters, dynamically types interop, serialization from and to different formats, so formatters, ORM in runtime with schemas from DB-connection, GUI scripts as QML...
> (and we will get C#? :) )

We already have all that stuff fyi.

>> with 2 such things Dlang will rise to heaven - scripting, protocol adapters, dynamically types interop, serialization from and to different formats, so formatters, ORM in runtime with schemas from DB-connection, GUI scripts as QML...
>> (and we will get C#? :) )
>
> We already have all that stuff fyi.

The fact is that you cannot run this material in WASM.
Speaking figuratively:
We guessed all the letters, but we cannot read the word in the “wheel of fortune”.
We are standing on a platform with people and want to get into the country of WASM. Which train comes first (rust, D, C++, Kotlin) and will be comfortable enough for these people (and we just hope/expect D-train on this forum), most people will board it, and when these people reach and call to others, that they drove well, and in this country everything is fine, the rest of the people (and new ones that will appear later) also gather on the trains of this company.

Writing CLI-tools on D is enough for now. Improvements to this can wait a year. We must look around and fight for people with their wallets and fresh blood for the future. Building this train can bring a lot of gold to D. And, probably, you will have 6-12 months to be on the first line.

> Writing CLI-tools on D is enough for now.
*is good enough

continue:
thousands of people crave this stuff. there is demand. you just need something to offer them something working, and benefits will flow like a river

any compiler based on LLVM can compile wasm-code.
we should provide the environment and runtime.
I understand that easy to speak and hard to do, but party leaders must indicate direction/target for nation. "Gondor calls for aid! And Rohan will answer!"

On Monday, 27 May 2019 at 15:42:16 UTC, Adam D. Ruppe wrote:
> I just wrote that for my blog thing this week:

here's my little blog entry

http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_27.html

the code is miserable but it works, there's some potential in this kind of interop for small amounts of glue code to enable access to the browser.

> here's my little blog entry
> http://dpldocs.info/this-week-in-d/Blog.Posted_2019_05_27.html

cool!
are u sure that need something like retain/release?
imo wasm can work with data only in wasm region and can invoke exported functions.

I find another blog with strings in wasm interop. author used another technique:
https://blog.usejournal.com/string-manipulation-webassembly-5011e64c6b76

On Monday, 27 May 2019 at 21:41:24 UTC, KnightMare wrote:
> are u sure that need something like retain/release?

The idea there is to use objects created in javascript without leaking the resources forever. Not sure if it really works but it at least has a good chance of working well.

> I find another blog with strings in wasm interop.

strings are pretty easy, i was more interested in native objects from the JS side like dom elements.

> strings are pretty easy, i was more interested in native objects from the JS side like dom elements.

https://github.com/skoppe/spasm/blob/v0.1.13/README.md#spa-framework
here Koppe went deep enough in dom

On Tuesday, 28 May 2019 at 07:47:33 UTC, KnightMare wrote:
>> strings are pretty easy, i was more interested in native objects from the JS side like dom elements.
>
> https://github.com/skoppe/spasm/blob/v0.1.13/README.md#spa-framework
> here Koppe went deep enough in dom

That is the spa framework part of spasm.

I also have bindings to many web apis. All generated from WebIDL files.

https://github.com/skoppe/spasm/tree/master/source/spasm/bindings

Example:

https://github.com/skoppe/spasm/blob/master/examples/dom/source/app.d
https://github.com/skoppe/spasm/blob/master/examples/fetch/source/app.d