mattkol

EdgeSharp is WebView2 for Win32 C# and value added for WinForm/WPF. EdgeSharp uses many features in Chromely - https://github.com/chromelyapps/Chromely.

Hi All,

Chromely - https://github.com/mattkol/Chromely was introduced earlier. Thanks to all that gave feedbacks.

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.

Appreciate the feedbacks! Thanks.

Thanks for your response, but I do not get the "flat out lying" part.

What has lying got to do with a subjective definition of "lightweight". See discussion on Javascript - https://stackoverflow.com/questions/39797181/why-javascript-...

What does "lightweight" really mean?

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.

https://en.wikipedia.org/wiki/Lightweight_programming_langua...

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).

So far there are CEF1 and CEF3 - https://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Ov... CEF1 is single process - no longer supported. CEF3 is multi-process - current.

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.

Chromely is fully configurable and allows single process usage. Please see configuration wiki page at : https://github.com/mattkol/Chromely/wiki/Configuration

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.

> 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.

True.

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.

I appreciate the feedbacks.

Just knowing about Blazor from you. That should be interesting and doable.

Chromely is relatively new, so may be soon someone may show interest and combine with Blazor. I will also take a look.

Thanks for pointing that out.

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.

> Also there’s newer MS Edge: https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie....

You can see Chromely as an alternative to this.

> You embed Chrome into a windows-only WPF app?

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.

Thanks for your encouraging comment.

I did not include the link in this post. The admin sent me an email advising me to re-submit. Thanks for pointing that out.

This is a html desktop app framework built on chromium/Cef. The front end (rendering process) is in HTML/CSS/js. The "backend" if you may, or the "browser" is in .NET C#.

You still need both pair of HTML/CSS/js and C# to develop an app.

However, you can use any frontend Javascript frameworks like Angular, React that may require transpiling.

Ok. I get that. Still a relative term, I guess. It is easy to make reference to Electron, because people are likely to be more keen on knowing more. If you consider other Cef implementations using Winform, WPF, Chromely is still "lightweight". And it is designed with potential to be pure cross-platform like Electron.

Reason for not liking webapps - what is that reason? Because of chromium/CEF?

Thank you. True. Simpler is more appropriate.

Hi All on HN!

My name is Kola I am a .NET Architect currently working on WPF projects.

I was working on a SugarCrm WPF project - https://github.com/mattkol/SugarDesk - and wanted to include a reporting module to my project. I was presented with many options and concluded that an HTML5 report will be more appropriate. That led me to Cef. However all Cef WPF implementations use bitmap rendering (https://stackoverflow.com/questions/43362301/automation-why-...). I started looking into raw html rendering. Long story short - Chromely was born. I found it a lot more challenging and rewarding, as a result, I abandoned SugarDesk to focus more on Chromely as I concluded in my mind there is almost no fully developed framework using Cef and thin native UI host without WinForms or WPF.

Summary: Chromely is a lightweight .NET/.NET Core HTML5 Chromium desktop framework alternative to Electron.NET, Electron for .NET/.NET Core developers.

Chromely builds HTML5 desktops without WinForms or WPF. Chromely is based on CEF's Xilium.CefGlue and CefSharp using thin Windows and Linux native GUI API as chromium hosts.

With Chromely, you can build SPA's HTML5 desktop apps- using Angular, React, Vue or similar - with or without Node/NPM.

For more info please go to - https://github.com/mattkol/Chromely