
Show HN: Chromely – Lightweight Alternative to Electron for .NET and .NET Core - mattkol
https://github.com/mattkol/Chromely
======
mattkol
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](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-...](https://stackoverflow.com/questions/43362301/automation-why-wpf-
based-cefsharp-uses-bitmap-for-rendering-while-winforms-does)). 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](https://github.com/mattkol/Chromely)

~~~
Const-me
You embed Chrome into a windows-only WPF app?

The OS already has two web browser controls built-in.

The good old IE has a couple of issues, but they are fixable, especially if
you only display your own content.

Also there’s newer MS Edge:
[https://blogs.windows.com/msedgedev/2018/05/09/modern-
webvie...](https://blogs.windows.com/msedgedev/2018/05/09/modern-webview-
winforms-wpf-apps/)

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

~~~
Const-me
> 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..

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

~~~
Const-me
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.

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

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

~~~
jug
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)?

~~~
butz
It's called Progressive Web Apps. Already supported in Chrome, coming (or
released already) on Edge. Still waiting for Firefox and Safari to catch up.

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

------
fake-name
If it's built on top of chromium/CEF, it's not "lightweight", and you've
missed the entire reason people don't like webapps.

~~~
mattkol
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?

~~~
fake-name
It's emphatically _NOT_ lightweight. It's basically __just __obese, rather
then the morbidly-on-the-deathbed obese that is electron.

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.

~~~
mattkol
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-...](https://stackoverflow.com/questions/39797181/why-javascript-
is-called-as-light-weight-programming-language)

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...](https://en.wikipedia.org/wiki/Lightweight_programming_language)

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.

~~~
fake-name
Ok, I'll retract that statement.

Corrected:

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

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

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

~~~
mattkol
Thanks for your encouraging comment.

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

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

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

~~~
Bizarro
So your team is only using one UI tech.

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

------
roryisok
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!

~~~
roryisok
Ok not sure what I did to upset the HN masses with this post. I genuinely want
to know if there's a mac OS version

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

~~~
roryisok
It's ok, I just meant I got downvoted initially and I don't know why

------
parvenu74
> Chromely uses Windows and Linux native GUI API as chromium hosts.

No plans to support macOS?

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

------
starbuzz
Duplicate of
[https://news.ycombinator.com/item?id=17132823](https://news.ycombinator.com/item?id=17132823)

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

