This looks nice !<p>However... "Low CPU and memory footprint (...) memory usage is under 20 MB for a Hello World program" : I am the only one who still thinks this is huge ? (-> <a href="https://tonsky.me/blog/disenchantment" rel="nofollow">https://tonsky.me/blog/disenchantment</a> )
Looks really good! At first glance, this seems like probably the best Electron alternative I've seen posted on HN.<p>Apart from the consistent GUI layer, I think an underrated reason that many teams stick with Electron is the mature tooling for cross-platform builds and upgrades. It's pretty painful to DIY.<p>It looks like NodeGUI doesn't currently support cross-compilation--is that something that's on the roadmap? How about upgrade/auto-upgrade tooling? Code signing?
I'm seeing a lot of Qt vs. Chromium in this thread. Here's your mindblown.gif of the day: Chromium is based off Webkit which is based off KDE which is based off Qt. <a href="https://en.wikipedia.org/wiki/KHTML" rel="nofollow">https://en.wikipedia.org/wiki/KHTML</a>
Just thought it was worth mentioning that nodegui is a node & qt runtime. There are framework components for not just Svelte, but React and Vue as well... just search on github if you prefer a different framework.
> core set of platform agnostic native widgets<p>This is confusing for me. I think such a framework is either 'platform agnostic' OR 'native'. Maybe the API is platform agnostic and the rendering is done natively?
I'm always a bit surprised there was the space for Electron to exist in the first place. Since most operating systems have widget toolkits that have browsers effectively embedded into them.<p>What I would have liked to have seen instead of Electron would have been a shim API that abstracted OSX/iOS/WinForms/QT webviews, and for those webviews to have a working API that would allow DOM manipulation, and allowed native sub-views to be inserted as block elements.
Same demo in VanilaJS and Sciter.JS : <a href="https://github.com/c-smile/sciter-js-sdk" rel="nofollow">https://github.com/c-smile/sciter-js-sdk</a> (see screenshots there).<p>Binary is ~5MB, and that is HTML/CSS + QuickJS + NodeJS runtime.<p>Versus 50MB+ of NodeGUI that is Node.JS + QT.<p>And SvelteJS works in Sciter.JS out of the box too.
Is there a way to have some small application that talks to the machine via a set of HTTP apis?<p>I envision something where you can just use your regular web app, have the user install the "Desktop Connector" which would be listening at say, port 8000 - then your web app can talk to the desktop via those APIs, instead of installing an Electron or related.<p>I must be missing/forgetting something crucial since that seems like the most straightforward solution imaginable.
Very cool, I've been following React-NodeGUI for about a year now and I love Svelte.<p>I especially love the idea of Svelte (compiling to imperative JavaScript code), but since it's technically a "superset" of JavaScript, IDE support has been an issue for me. Also I've cut my teeth trying to find a solid UI component library. These two things have restricted my use of the framework to smaller projects.<p>Anyone have any suggestions?
I've been following react-nodegui since it was announced and I really like it. In terms of memory usage it's the cat's meow; now there's a question of adoption and component / UI libraries for the ecosystem.<p>Perhaps a way to bootstrap that would be to align closer to react-native; at that point, we could use (js) components and libraries from react-native land.<p>The QT licensing question is also somewhat iffy; you need to put front and center what that implies for users of your library (do they need to open source their use of react-nodegui by extension of QT's licensing requirements for example).
It would be nice to have the ability to weave in WebViews with the native UI. I see this lib but it's still marked as WIP: <a href="https://github.com/nodegui/nodegui-plugin-webview" rel="nofollow">https://github.com/nodegui/nodegui-plugin-webview</a>
Is there any electron like framework which uses the native webview libraries (webkit etc) instead of shipping their whole browser for each application?
How is it "light" weight?<p>> Low CPU and memory footprint. Current CPU stays at 0% on idle and memory usage is under 20mb for a hello world program.<p>20MB!
How do you deal with zero day vulnerabilities? To me the biggest concern using browser-as-a-desktop solution is that there will be quite a lag between when Chrome patches zero days vs when it gets released.<p>ex) nw.js, electron.