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.
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.
Back in 2009, using chromium instead of IE in WPF was the only way to do overlays (that wouldn’t burn air space) and effects efficiently. Since WPF has been stagnant for so long, I wonder if there still isn’t a better solution than using chrome.
> if there still isn’t a better solution than using chrome.
A better solution is use WPF for the complete GUI.
Text & typography, raster and vector graphics are very compatible to HTML5. Effects, animations and templating are far superior. The only areas where HTML5 is winner are styling, maybe layout, and definitely the labor market i.e. it’s easier and cheaper to find a front-end developer than a WPF developer.
Also WPF is better integrated into Windows. Its easier to implement per-monitor DPI awareness (starting from .NET 4.6.2, released in 2016), easier to support accessibility (narrator & others), etc..
Believe it or not modern browsers are a clear winner when it comes to graphics performance. Sure WPF has a slick animation API that can do all sorts of things and a super-flexible "lookless controls" model, but the second you try to display a lot of data with anything fancier than plain text, you're in for a world of pain. Endless optimizing of visual trees and layouts, large data binding operations causing opaque and difficult to control UI-thread freezes that disable all your wait indicators, half-baked UI-virtualization support, it's not fun. What takes me days of fiddling to get to acceptable with WPF I can do with HTML5 and an easy to use battle-tested library in a few hours.
Developed quite a lot of WPF apps but very rarely encountered performance issues you’re talking about.
> Endless optimizing of visual trees and layouts
Never did that.
> UI-thread freezes that disable all your wait indicators
I avoid doing lots of stuff in the UI thread. This is especially easy to do with modern .NET and async-await.
In addition, I design my wait indicators so they run on the composition thread, i.e. aren’t affected by the UI thread being stuck.
> half-baked UI-virtualization support
For me it usually works OK but I agree there’re probably some issues with this feature. I remember fixing problems when my code or markup did something that disabled the virtualization and ruined the performance. But it never took days, maybe a few hours.
P.S. The worst issues I’ve encountered with WPF wasn’t performance, it was stability. Once I’ve spent a lot of time debugging rare render thread crash. I still don’t know the reason but I’ve simplified my visuals a bit (namely, pre-multiplied a render transform with the complex vector shapes I was rendering) and the problem seems to gone for now. Another time it crashed when I opened a popup, and closed it too soon, like 10-20ms after the open. The popup was “loading, please wait…” progress bar so it only happened when opening very small files from very fast hard drives.
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).
> The only areas where HTML5 is winner are styling, maybe layout, and definitely the labor market
You're missing a major feature - cross platform. WPF is Windows only.
As someone who has also built a few WPF apps (altho not for some years now), I absolutely hated working with XAML - the visual designer in Visual Studio was really buggy and brought any machine to it's knees. Doing things without the designer, hand cranking all that XML felt really clunky, and things like event handling and synchronisation were fiddly to get right.
HTML and CSS aren't perfect by a stretch, but at this point I think they're a great option for desktop UIs, especially if cross-platform is desirable (and I say this as a long in the tooth, Microsoft-stack focused architect).
> You're missing a major feature - cross platform. WPF is Windows only.
You’re missing the context. The OP has created that Electron-like thing to embed into a windows-only WPF app.
> the visual designer in Visual Studio was really buggy
Expression blend was, and still is, much better. It’s not especially friendly towards programmers, initially I had to read quite a lot of documentation and articles. But now I use it a lot (albeit not exclusively) and enjoy doing so.
> things like event handling and synchronization were fiddly to get right.
For me, MVVM works in 90%. The trick is to recognize the 10% of things for which it doesn’t, and do something else like code behind, or programmatic visual tree manipulation/generation, or something else.
> I think they're a great option for desktop UIs
If that desktop UI is a thin interface between user and a web server/cloud, maybe. If that desktop UI actually does something locally, I don’t think HTML is a great option: shell integration, WinAPI interop (both need COM interop). Also JavaScript isn’t exceptionally good general-purpose programming language especially for medium to large projects, e.g. MS had to create a TypeScript on top of JS for their VS Code.
> You’re missing the context. The OP has created that Electron-like thing to embed into a windows-only WPF app.
I didn't miss that, I was talking in a more general sense about HTML vs WPF.
> Expression blend was, and still is, much better.
I never did actually try this properly - I had a brief play with it years ago when it first came out, but it seemed like a toy; maybe I should give it a go now it's had time to mature.
> Also JavaScript isn’t exceptionally good general-purpose programming language
No arguments there, I'm a sense-confessed JS hater ;) Typescript however, is an absolute joy to use.
Technically no, the expression was lost a few years ago.
But practically yes, the blend is still a thing. The latest version of visual studio 2017 comes with a corresponding version of it. It’s as useful for everything XAML as the expression one was in 2010 when I started using it.
Is there a reason why you chose to use Ajax instead of WebSockets which has much lower latency and overhead? Not backward compatibility I hope! The spec was finalized and implemented ages ago.
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.
My apologies if this is explained somewhere and I simply didn't get it, but is the HTML5 app talking to a portable web server (Kestrel?) and the .NET web portion talking to the operating system or is this a case where .NET code is being invoked from the web app with via a JavaScript-to-.NET bridge of some sort? If the latter I'm massively interested.
Cefsharp with the winforms host is good. I'm not sure how anyone can stand the wpf version though... No matter how simple I made the app, it was still noticibly laggy with it having to render in such the terrible way.
I looked at chromely for a few minutes but the amalgamation of all those projects turned me off.
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.
Is this also bound by all the limitations of CEF? AFAIK, there's no way to override the storage limitations (i.e. 20% or something of the available free space, see http://magpcss.org/ceforum/viewtopic.php?f=6&t=15857 )
Excuse my ignorance, but is this written in a .net language that transpiles to js runtime or this written in HTML/CSS/js that transpiles to .net runtime? I'm probably missing what is electron.net and similar platforms.
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.
Nice project. However, I think Chrome is what people are talking about when they say Electron in heavy, not node. I have built apps with CEF and they are not really any lighter weight. You still have multiple processes of Chrome that are memory hogs. It's not like Electron's Chrome build has much more than CEF's.
Since all major operating systems in their normal desktop-use configurations now come bundled with one of four browsers - Edge (Windows), Safari (macOS), Firefox or Chrome/ium (*nix) which are actually also all supporting at least HTML5 and CSS3 pretty well, I think it would be an interesting idea if a framework that turned web pages into "apps" could have the app configured to fire up the app in the system browser and not just embed Chromium.
It shouldn't be that horrible anymore to do it cross browser like that, at least as long as you follow web standards and ignore Internet Explorer, requiring Windows 10 support there.
And it would make these apps, of course, absolutely tiny.
How about using that as a starting point, and have that Electron alternative focus on making cross-browser development as painless as possible instead via built in Javascript shims/polyfills where necessary, and special API calls to integrate it into the underlying OS of course (OS native notifications etc)?
The enabling technologies, like service workers and web assembly are in the early stages of being supported across evergreen browsers. These are progressive, because they work in all modern browsers, but have extra capabilities like being "installable" on forward looking systems like, Android and Chrome OS.
It is a big deal when industry is willing to work together.
The Boscop one is just bindings for https://github.com/zserge/webview which is only MSHTML on Windows not Edge. The tether one appears Rust only which means I have to expose my own C FFI layer to use in other langs. I want them to combine and give me the best of both! :-)
Hey! Original Webview author here. I am aware of the issue of MSHTML vs Edge, and I would really love to support Edge. With the new cppwinrt included into Windows SDK it should be possible - it's just plain C++17 (and then we need a small C wrapper to make it compatible with Cgo). But so far I'm failing miserably to even build a minimal WPF app using cppwinrt. Still, the hope remains, and any help is highly appreciated.
Or maybe we should build a separate DLL for Edge and call it from the webview library? Not sure how that will work with the UWP packaging. Any expert knowledge is highly welcome and I'm open to the discussions.
I was also thinking about adding CEF bindings using dlopen, so that one could compile a binary, drop it into CEF "Release" directory and run. But I'm not sure whether it's a good idea. CEF is heavy. But it's the same on all platforms. I wonder what do people think about it?
Oh for sure. I am watching https://github.com/zserge/webview/issues/85 like a hawk and have even tried to do some self-contained binaries w/ the new WinRT libs myself with limited luck (because of the UWP packaging). I personally won't use it from Go if I can't distribute a single binary.
I have used CEF and while I love the abstraction, it comes w/ baggage. I ship CEF along w/ an app (it's the browser I'm typing this from now) and just libcef.dll is 91MB, not counting some of the tiny ancillaries. I think you are on the exact right approach and even if you want a CEF, just make sure it's not the preferred option on any platform. I have heard that MS people are working towards a usable Edge shared lib elsewhere, we'll see.
The major support for PWAs for Edge was released in this recent Windows 10 April Release.
That also includes Microsoft Store support for PWA apps.
Several applications in the Microsoft Store for Windows 10 have already launched or switched to PWAs (one of the most noticeable one was Twitter replaced their increasingly outdated Windows 8 application with a PWA as soon as the April Release happened).
The Android Store also supports PWAs directly in recent versions (the "Twitter Lite" application on Android is the same PWA that Windows users now get by default, and presumably will be the only first party Android Twitter client once usage of PWA-capable versions of Android rises).
Microsoft's Bing crawler is supposed to start adding "high quality" PWAs directly to the Microsoft Store as soon as it finds them on the web and minimally vets them (and will provide tools to PWA website owners to control/enhance their listings).
Google's search crawler team is also supposedly investigating lighting up automatic app ingestion into the Android and/or Chrome Stores.
I wonder why Electron doesn't use less processes or even only one process. Reliability for normal chat apps etc. is less important and I believe in practice one of the sub processes never crashes.
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.
Not sure why sciter gets ignored in this space. It's very lightweight in comparison to anything chrome is doing (even a hand carved cef build is 15+MiB) supports react and angular, uses GPU compositing and has been commercially supported for nearly a decade.
It's free in binary form, $310/yr in source form for Windows, and $620 for cross-platform added to that. Given how people use Electron, that licensing should be fine for many use cases. The company has also been around for 10 years or so if anyone is worrying about longevity.
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?
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.
There are a lot of potential reasons to use something like this, but having a main selling point of it being "lightweight" is just flat out lying or willfully misunderstanding what lightweight means.
------
Javascript, and all scripting languages in general (maybe excepting lua and similar) are fundamentally not lightweight. They require enormously complex runtimes.
I'd say a reasonable definition of "lightweight" for an application runtime is if a complete, distributable app including all the required components can fit in 1 MB (This functionally excludes things like .NET too).
There are, or course, odd corner cases (using the OS UI components, etc...), but it's broadly applicable.
Other relevant bits to being lightweight - how fast is the application to start/stop? What's the minimum runtime overhead? etc...
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 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.
The repo looks great, I can see a lot of thought has been put into the project. It makes sense to leverage HTML/CSS/JS to build UIs for desktop apps. Chromium and Electron get a tough treatment here at HN, for valid reasons, but I'd say, the more experiments and implementations the better for the ecosystem.
Did anyone combine this with Blazor yet? That would make it possible to create the entire application, backend and frontend, in dotnet, running it as webassembly in the UI. No javascript needed, just c#/f# against the DOM.
For F#, you can also use F# to transpile f# to clean javascript (will use standard babel and has an awesome interop story with existing npm packages or js libraries), and use electron api as is
Related, the ionide extension of Visual Studio Code ( https://github.com/ionide/ionide-vscode-fsharp ) is implemented with fable, and used to generate extension of vscode (electron/js based).
works really well and power the F# language support of Visual Studio Code
What's the point of this? Xamarin is cross platform and a lot more "lightweight" than this will ever be. xamarin.forms supports mac, windows (uwp right now, wpf soon), GTK, Android and iOS.
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.
I noticed there's no mac version. Linux and windows only, is that correct? Is there a version planned for Mac OS? Most electron apps seem to target Mac OS and Windows primarily with Linux as an after thought, so I would imagine this would be a deal breaker for them.
It's a great project though, thanks for building it!
> 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.
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.
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