Very good project, but I think the interoperability between C # and JavaScript is so troublesome.

[HongChenLuYuan]

Very good project, but I think the interoperability between C # and JavaScript is so troublesome.

[ottodobretsberger]

Would you mind elaborating on what specific scenarios you find troublesome?

[HongChenLuYuan]

Messages can only be conveyed using string. In JavaScript, we also need to use the Switch statement for processing, which is very troublesome (especially in the vue project, I don't know what to do). Or is there a more detailed example?

I suggest that we can refer to the wails project. url address: https://wails.io/docs/howdoesitwork

[MikeYeager]

@HongChenLuYuan This would be a nice addition to Photino, but not crucial as it only makes the dev experience a little nicer. It doesn't enable any new features or functionality. We will add this to our roadmap. Thanks for the suggestion.

[LauraWebdev]

For reference, I've written a small parser that interfaces via JSON payloads. If there is interest, I'll split it out as a seperate library later on.

MessageParser.cs
Implementation in C#
Implementation in JS
Example Command

I'm also using mitt in Vue to broadcast Photino responses globally. Components can then listen to the events individually.

[rtmann]

As an alternative idea, you might want to consider not using send message, and use gRPC instead: https://github.com/grpc/grpc-dotnet

And offload all data requests to modern web workers to leverage true multithreading in JavaScript. This has the added benefit of making your app compatible with being run in other browsers. And instead of directly running a PhotinoWindow in the main console app thread, you can setup IOC/Services/Configuration etc and wire up gRPC, and then kick off PhotinoWindow in another thread separate from the main program thread.

This would give you the ability of enabling users to run the program as a server an access it from other browsers on their network while also letting them run it as an application if they'd prefer.

I think Photino's main strong point is it's not shipping an entire Chromium Embeded Framework with it, it's just using the browser control natively on the pc's already. But I think one of the main benefits of using a browser control for a UI is being able to seamlessly support a web site UI and a Desktop UI at the same time with the same code base.

If you start integrating with priority things in Photino it destroys that benefit.

Grpc is plenty fast.

[rtmann]

Personally, I opted not use the js/c# interoperability at all.

Instead I use Signal R on .Net 7 and it's compatible with Azure SignalR. I then design a proper Asp.net Web Api on .net 7 and I add and setup SignalR in it and design hubs.

This gives me a lot of advantages.... I.e. I can have multiple windows that all send/receive messages to signalr on the same contexts with a connection id for each window. And it runs on websockets and I get an automatic client side hub api (generated) and I can call backend apis, hardware etc from the client side signal r connection.

To run the api, I have "standalone" mode and "self hosted mode". In standalone mode, all my Console App does is host Photino and serve assets, that's it. In embeded mode my Photino app spins up IoC and setups Self Hosting Web Api stuff and self hosts the api so the photino app is hosting the web api and signalr connections itself and rendering photino. I just run the webapi on a separate thread so photino can have the main thread for the browser control ui work.

If I get around to it, I think I might try to contribute to this project and add some signalr / websocket packages/options.

Another option though would be to write a translation layer that compiles to webasm, so you can pass that "switch stuff" to the web asm code and let it do all the mapping and call out to the proper js interopt end point.