Based on demands from some developers, there are new features added - like Websocket implementation for real-time apps development, frame handling (to execute JavaScript functions see - https://github.com/mattkol/Chromely/wiki/Frame-Handling) and "iframe" support.
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.
The idea that everyone sees "lightweight" and they ONLY think of Chromium size seems an ascription of "lightweight" ONLY to chromium size. I understand that has been a more common approach to chromium based solutions. This is not it here.
I have said in a few of my comments that this is simple referring to "simpler".
See a definition of "lightweight" from wikipedia:
A lightweight programming language is one that is designed to have very small memory footprint, is easy to implement (important when porting a language), and/or has minimalist syntax and features.
So if we replace "lightweight programming language" with Chromely, while the small memory footprint, may be arguable false, it is however easier to implememt and minimal features. Note the "and/or" part.
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).
CEF3 still allows single process, but it is only advisable for testing/debugging only. Multi process is recommended for optimal performance and likely some functions may not work well without it. My experience is for simpler apps, single process can still be used.
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.
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.
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.
> It's a great project though, thanks for building it!
Thank you.
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.
The notion of Chromely not needing Node to run and may not even be needed for development should count for some difference and less use of resources, methinks.
Worse if you consider Electron.NET, you have to run a separate Asp.net server besides Node.
These are differences that made me conclude, yes, it is somewhat "lightweight" or simpler compared to them.
To me these are the advantages Chromely brings to the table.
If you like CefSharp with WinForms, then likely you will like Chromely too. Chromely on Windows is like CefSharp hosted on Winapi ("thinner" WinForms, if you may). And Chromely has a lot of implementations out of the box, that lets you hit the road in minutes.
I hope you will give it another shot sometimes later.
No, Chromely does not use WPF or WinForms. That is the main difference compared to other .NET Cef approaches. Chromely uses "thin" native GUI as host. This can be seen as an advantage or disadvantage depending on which angle you are looking at it.