8 ms·

Show HN: Chromely – Lightweight Alternative to Electron for .NET and .NET Core

143 points by mattkol 8y ago

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 ago
  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.
  - mattkol 8y ago
    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.
- helthanatos 8y ago
  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.
  - mattkol 8y ago
    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.
- Const-me 8y ago
  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-webview-winforms-wpf-apps/ https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie...
  - seanmcdirmid 8y ago
    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 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 ago
  Hi 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 ago
    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.
- parvenu74 8y ago
  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.
  - parvenu74 8y ago
    I 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 ago
      Thanks for that. Please any help, no matter how small will be appreciated. Contributions, PRs are also accepted.
- egeozcan 8y ago
  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 http://magpcss.org/ceforum/viewtopic.php?f=6&t=15857 )
  - mattkol 8y ago
    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.
kodablah 8y ago
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.
- mattkol 8y ago
  Thank you. True. Simpler is more appropriate.
- sebazzz 8y ago
  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.
  - kodablah 8y ago
    Not an option with Chromium. There was once a barely supported single-process option, but I think they even removed that.
    - mattkol 8y ago
      So far there are CEF1 and CEF3 - https://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Overview 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 https://github.com/mattkol/Chromely/wiki/Configuration
- jug 8y ago
  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)?
fake-name 8y ago
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 8y ago
  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?
  - aepiepaey 8y ago
    More of a reason for disliking Electron apps. Because it's a whole extra web browser, using a lot of resources (much more than a native app would). And Chromely doesn't address that concern.
    - mattkol 8y ago
      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.
  - fake-name 8y ago
    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 8y ago
lioeters 8y ago
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 8y ago
  Thanks for your encouraging comment.
starbuzz 8y ago
Duplicate of https://news.ycombinator.com/item?id=17132823 https://news.ycombinator.com/item?id=17132823
- mattkol 8y ago
  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.
Maarten88 8y ago
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 8y ago
  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.
- enricosada 8y ago
  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 https://github.com/fable-compiler/samples-electron https://github.com/fable-compiler/samples-electron Related, the ionide extension of Visual Studio Code ( https://github.com/ionide/ionide-vscode-fsharp 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
roryisok 8y ago
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 8y ago
  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 8y ago
    Sorry for the late response. Just a busy day for me.
    - roryisok 8y ago
      It's ok, I just meant I got downvoted initially and I don't know why
- mattkol 8y ago
  > 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.
deft 8y ago
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 8y ago
  So your team is only using one UI tech.
  - mattkol 8y ago
    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.
- mattkol 8y ago
  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.
CNJ7654 8y ago
Thank God, I almost went a whole 24 hours without seeing another service with a -ly suffix Still cool though, hopefully devs will hop on this
parvenu74 8y ago
> Chromely uses Windows and Linux native GUI API as chromium hosts. No plans to support macOS?
- mattkol 8y ago
  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.

143 points 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 ago
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.
- mattkol 8y ago
  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.
helthanatos 8y ago
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.
- mattkol 8y ago
  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.
Const-me 8y ago
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-webview-winforms-wpf-apps/ https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie...
- seanmcdirmid 8y ago
  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 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 ago
Hi 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 ago
  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.
parvenu74 8y ago
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.
- parvenu74 8y ago
  I 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 ago
    Thanks for that. Please any help, no matter how small will be appreciated. Contributions, PRs are also accepted.
egeozcan 8y ago
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 http://magpcss.org/ceforum/viewtopic.php?f=6&t=15857 )
- mattkol 8y ago
  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.

kodablah 8y ago

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.

mattkol 8y ago
Thank you. True. Simpler is more appropriate.
sebazzz 8y ago
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.
- kodablah 8y ago
  Not an option with Chromium. There was once a barely supported single-process option, but I think they even removed that.
  - mattkol 8y ago
    So far there are CEF1 and CEF3 - https://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Overview 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 https://github.com/mattkol/Chromely/wiki/Configuration
jug 8y ago
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)?

fake-name 8y ago

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 8y ago
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?
- aepiepaey 8y ago
  More of a reason for disliking Electron apps. Because it's a whole extra web browser, using a lot of resources (much more than a native app would). And Chromely doesn't address that concern.
  - mattkol 8y ago
    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.
- fake-name 8y ago
  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 8y ago

lioeters 8y ago

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 8y ago
Thanks for your encouraging comment.

starbuzz 8y ago

Duplicate of https://news.ycombinator.com/item?id=17132823 https://news.ycombinator.com/item?id=17132823

mattkol 8y ago
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.

Maarten88 8y ago

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 8y ago
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.
enricosada 8y ago
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 https://github.com/fable-compiler/samples-electron https://github.com/fable-compiler/samples-electron Related, the ionide extension of Visual Studio Code ( https://github.com/ionide/ionide-vscode-fsharp 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

roryisok 8y ago

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 8y ago
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 8y ago
  Sorry for the late response. Just a busy day for me.
  - roryisok 8y ago
    It's ok, I just meant I got downvoted initially and I don't know why
mattkol 8y ago
> 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.

deft 8y ago

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 8y ago
So your team is only using one UI tech.
- mattkol 8y ago
  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.
mattkol 8y ago
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.

CNJ7654 8y ago

Thank God, I almost went a whole 24 hours without seeing another service with a -ly suffix Still cool though, hopefully devs will hop on this

parvenu74 8y ago

> Chromely uses Windows and Linux native GUI API as chromium hosts. No plans to support macOS?

mattkol 8y ago
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.