4 ms·
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/Su
by mattkol 8y ago
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-wpf-based-cefsharp-uses-bitmap-for-rendering-while-winforms-does 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 https://github.com/mattkol/Chromely
- nawfalhasan 8y agoExcuse 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.
- mattkol 8y agoThis 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.
- helthanatos 8y agoCefsharp 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.
- mattkol 8y agoIf 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.
- Const-me 8y agoYou 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-webview-winforms-wpf-apps/ https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie...
- seanmcdirmid 8y agoBack 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 8y ago> 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..
- GordonS 8y ago> 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).
- davidhyde 8y agoHi Mattkol, 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.
- mattkol 8y agoActually 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.
- parvenu74 8y agoMy 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.
- parvenu74 8y agoI think I've answered my own question: it's the latter: https://github.com/cefsharp/CefSharp https://github.com/cefsharp/CefSharp I think a sprint or two to document this project better would be massively helpful and I'm willing to volunteer.
- mattkol 8y agoThanks for that. Please any help, no matter how small will be appreciated. Contributions, PRs are also accepted.
- egeozcan 8y agoIs 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 http://magpcss.org/ceforum/viewtopic.php?f=6&t=15857 )
- mattkol 8y agoThanks 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.