mattkol

Thanks for your explanation. If you read my intro, you will notice that Chromely was not started as an alternative to Electron, I was trying to solve a problem and over time I realized I came up with something that can be used instead of Electron (for .NET/.NET Core).

> Other relevant bits to being lightweight - how fast is the application to start/stop? What's the minimum runtime overhead? etc...

I have not had the bandwidth to check this. My hunch is Chromely may have some edge on this. But we leave that until it is proven or not.

> There are a lot of potential reasons to use something like this ..

I thought so too, so have many developers, thanks for pointing this out.

Appreciate the feedbacks! Thanks.

Like you, I have developed quite a lot of WPPF apps and still do (my day job!). I completely agree with all the points you made. Especially the point on composite control handling it's own wait indicator is spot on.

However, I believe @m_fayer is right too. The performance issue can creep up on you if you are not constantly watching it.

The weak-reference used by DelegateCommand in most WPF framework implementations - Prism, MVVMLight, Caliburn.Micro can cause extra headaches if one is not watching it. I have seen memory clogs with InputBindings; I have seen unexplaiined performance issues with ColumnSpan, RowSpan usages, and others issues I can't remember at the moment.

Buttom line is one needs to take C/C++ mindset to WPF to achieve optimal performance - that is you may have to have a strategy to clean up after yourself (just like pointers) and not rely too much on Garbage Collector (GC).

Thanks for bringing this up. This is one area I have not looked at closely.

Chromely is based on CefGlue, CefSharp that are also based on CEF. So yes, restrictions, unless overridden will pass up from base.

Thanks for that. Please any help, no matter how small will be appreciated. Contributions, PRs are also accepted.

Actually I am currently looking at websocket, but not for the same reason you raised. I was looking at extending for real-time apps.

However ... Ajax is one of the options of IPC, and this is common to both CefGlue and CefSharp implementations. The options are:

1. Ajax HTTP/XHR (Xilium.CefGlue, CefSharp) 2..NET/Javascript integration (CefSharp) 3. Generic Message Routing (Xilium.CefGlue)

I see 2 and 3 as the common usage for the CEF .NET community. Ajax may see less usage because it's use can result in other issues -- like cross-origin error and may be more complex for some people.

Like I said, I have just started looking into WebSocket and may soon be implemented for CefGlue apps.

Correct me if I am wrong ...

Sure Xamarin.Forms will be a lot more "lightweight".

Chromely is an HTML desktop app.

All the options you mention will end up being traditional (with their own controls) desktop apps with HTML support. Chromely is pure HTML. Chromely is not tied to rigid frontend controls .. you can use any html/javascript/css framework you like.

Chromely does not use WinForm or WPF. Extendable to WinForms and WPF for those who want to.

So, a different approach, if you may.

Yes, for now, just humble me. Others are already showing interest, and the team will grow, I hope.

Contributions are always welcome, via issues raised, or PRs or any other means.

Sorry for the late response. Just a busy day for me.

No support yet for macOS, but the plan is to make Chromely truly cross-platform. The only limitation now is the required skill. I have never developed on macOS before and do not currently have the bandwidth to learn enough.

However, as I have mentioned to others in the past, help and contributions are welcome.