On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim Grøstad wrote:
> Yes, although it makes more sense to do all the UI stuff in Dart and instead use other languages as "service providers".

I'm sceptical of that. I do basically the same with Bridge.Net (with the difference that big part of "services" code is also in C#). This isn't a design decision, the architechture is this way because spasm didn't exist yet when I started, D was added later.

And I can tell you that interfacing D-borne wasm with Bridge.Net is a low of work. D code can't take or pass JavaScript objects directly due to how WASM is designed, only their indexes if they are positioned in a purpose-built global array. This means that if you want to call your D functions in any easily readable way, you have to develop an automatic interface template in the ui language - introspection capabilites of D will not help. Perhaps those can be done in C# or Dart, but sounds unlikely to me that it could be done even nearly as well.

On Tuesday, 14 January 2020 at 15:01:06 UTC, Dukc wrote:
> array. This means that if you want to call your D functions in any easily readable way, you have to develop an automatic interface template in the ui language - introspection capabilites of D will not help. Perhaps those can be done in C# or Dart, but sounds unlikely to me that it could be done even nearly as well.

You need some kind of IDL compiler. I assume you could use attributes to specify the D code that should be used for generating Dart interfacing code?

On Tuesday, 14 January 2020 at 15:01:06 UTC, Dukc wrote:
> On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim Grøstad wrote:
>> Yes, although it makes more sense to do all the UI stuff in Dart and instead use other languages as "service providers".
>
> I'm sceptical of that. I do basically the same with Bridge.Net (with the difference that big part of "services" code is also in C#). This isn't a design decision, the architechture is this way because spasm didn't exist yet when I started, D was added later.
>
> And I can tell you that interfacing D-borne wasm with Bridge.Net is a low of work. D code can't take or pass JavaScript objects directly due to how WASM is designed, only their indexes if they are positioned in a purpose-built global array.

Isn't that what the webidl bindings generator does? It takes the definitions and generates D bindings and wrappers, JS code and glues everything together. You can add your own webidl files to generate D and JS glue code to interface with other things. (Although with Bridge.NET you have to take into account how they transpile C# to JS, complicating matters, but given a JS wrapper around Bridge.NET it might be possible).

With my (unfinished) typescript binding generator I am doing the same thing as from webidl, but instead it is based on typescript files, so you can interface D with typescript libraries (or JS libraries with ts typings).

> This means that if you want to call your D functions in any easily readable way, you have to develop an automatic interface template in the ui language - introspection capabilites of D will not help.

Calling D functions isn't so well supported in my webidl bindings generator, except for delegates which are used for callbacks. But we can definitely fix that.

On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 13 January 2020 at 08:11:49 UTC, Sebastiaan Koppe wrote:
>> On Sunday, 12 January 2020 at 23:08:16 UTC, Ola Fosheim Grøstad wrote:
>>> Hm, how would you do that when the UI components are written in Dart? Generate Dart VM code?
>>
>> I don't know, I haven't looked into it. But the repo the OP linked to did the same from JS, and Dart has a C FFI as well, so there must be a way in somehow.
>
> Ok, I don't know how they go about this, but there is a way to add isolates dynamically through data URIs in the JITted version of Dart. Never tried myself though.
>
> Apparently this capability is not available when using AoT (seems reasonable).

Nah. I think they generate some Dart glue code to help with the interfacing.

>> The point is that we ought to be able to, otherwise the UI programming community is just replacing one silo for another.
>
> Yes, although it makes more sense to do all the UI stuff in Dart and instead use other languages as "service providers".

I am talking about leveraging the multi-platform components from Flutter, and move as much of the UI composition and logic to D.

Not just Flutter really, anything. I mean, I like React, but no JS. I like Flutter, but no Dart. Why do all these frameworks get you locked into their language? Is there a technical reason?

On Thursday, 16 January 2020 at 09:35:33 UTC, Sebastiaan Koppe wrote:
> On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 13 January 2020 at 08:11:49 UTC, Sebastiaan Koppe wrote:
>>> On Sunday, 12 January 2020 at 23:08:16 UTC, Ola Fosheim Grøstad wrote:
>>>> Hm, how would you do that when the UI components are written in Dart? Generate Dart VM code?
>>>
>>> I don't know, I haven't looked into it. But the repo the OP linked to did the same from JS, and Dart has a C FFI as well, so there must be a way in somehow.
>>
>> Ok, I don't know how they go about this, but there is a way to add isolates dynamically through data URIs in the JITted version of Dart. Never tried myself though.
>>
>> Apparently this capability is not available when using AoT (seems reasonable).
>
> Nah. I think they generate some Dart glue code to help with the interfacing.
>
>>> The point is that we ought to be able to, otherwise the UI programming community is just replacing one silo for another.
>>
>> Yes, although it makes more sense to do all the UI stuff in Dart and instead use other languages as "service providers".
>
> I am talking about leveraging the multi-platform components from Flutter, and move as much of the UI composition and logic to D.
>
> Not just Flutter really, anything. I mean, I like React, but no JS. I like Flutter, but no Dart. Why do all these frameworks get you locked into their language? Is there a technical reason?

There is, developing a programing language that takes into account designer and IDE tooling leads to more productive experiences.

Swift and Kotlin are also getting features that make it easier for SwiftUI and Jetpack Composer development.

Same applies to Common Lisp, Delphi, VB, C#, Java.

Without such features, the tooling needs to be clever about specific programming patterns, which always breaks down when the developers decide to manually change the code.

On Thursday, 16 January 2020 at 09:21:32 UTC, Sebastiaan Koppe wrote:
> Calling D functions isn't so well supported in my webidl bindings generator, except for delegates which are used for callbacks.

That's why. If you use Dart (or C#) to as the UI language, you have to call D from it, not vice-versa (I think?). But if you interface with a framework directly the situation should change. Well, presumably one needs to write a Dart wrappers for the events, if Flutter uses them, I'm not familiar with it...

> But we can definitely fix that.

...but if that is done, it should work in any case.

Just to be clear, I don't personally think I'm going to use Flutter. I've grown to dislike frameworks, preferring to use libraries. The language agnosticity you lobby for is among the reasons, but not the only one.

On Thursday, 16 January 2020 at 09:35:33 UTC, Sebastiaan Koppe wrote:
> Nah. I think they generate some Dart glue code to help with the interfacing.

Apparently they build proxies:

https://github.com/TGIF-iMatrix/MXFlutter/blob/master/js_flutter_src/js_framework_lib/js_flutter_basic_types.js#L83

Not something I want to deal with...

> I am talking about leveraging the multi-platform components from Flutter, and move as much of the UI composition and logic to D.

Then the advantage of hot patching is lost and it will be difficult to interface with all Dart-based Flutter components.

One big advantage with Flutter is that you see visual changes in a running application right after hitting  the save menu item in the editor (or keyboard shortcut).

> Why do all these frameworks get you locked into their language? Is there a technical reason?

As frameworks grow they tend to start using language-features in ways that are difficult to interface with.

On Thursday, 16 January 2020 at 16:02:28 UTC, Ola Fosheim Grøstad wrote:
>
> Then the advantage of hot patching is lost and it will be difficult to interface with all Dart-based Flutter components.
>
> One big advantage with Flutter is that you see visual changes in a running application right after hitting  the save menu item in the editor (or keyboard shortcut).
>

There is a way to do this with static build: https://github.com/lc-soft/trad

It use a limit javascript subset at develop stage, and can build into c binary in release mode.

On Friday, 17 January 2020 at 06:28:55 UTC, Newbie2019 wrote:
> On Thursday, 16 January 2020 at 16:02:28 UTC, Ola Fosheim Grøstad wrote:
>>
>> Then the advantage of hot patching is lost and it will be difficult to interface with all Dart-based Flutter components.
>>
>> One big advantage with Flutter is that you see visual changes in a running application right after hitting  the save menu item in the editor (or keyboard shortcut).
>>
>
> There is a way to do this with static build: https://github.com/lc-soft/trad
>
> It use a limit javascript subset at develop stage, and can build into c binary in release mode.

It does not preserve state between changes like Flutter does.

On Friday, 17 January 2020 at 07:38:42 UTC, Paulo Pinto wrote:
>
> It does not preserve state between changes like Flutter does.

In develop emulator it dose, because that is a pure nodejs implement.  only in release mode it generate pure binary code.