Calculator demo doesn't run, makes some cmake errors.
Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
41–50 of 281 posts
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#42This looks nice ! 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 ? (-> https://tonsky.me/blog/disenchantment )
I just made hello world window in qt. It's 28 kB. edit: typo
The thing is nobody actually uses hello world programs, by the time you build a real application the difference in RAM usage between that and a good Electron app for example blurs significantly.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#43Earlier quoted context omitted.
I saw Qt and immediately understood what you were trying to say, but for the record: That’s not what native means. Native means “uses the platform widgets and drawing/theming api” and Qt is not native: it actually draws its own widgets (for the most part with certain exceptions on certain platforms) that are drawn to mimic the system UI with subtle differences. If the system UI implementation suddenly changes (say wi…
Is Qt considered native when you use KDE and not native when you use GNOME? Is Qt 3 considered not native when you use a KDE release that uses Qt 4 under the hood?
Native usually means standard or specific to the particular system. I would say yes to those questions.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#44This looks nice ! 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 ? (-> https://tonsky.me/blog/disenchantment )
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhe…
However, most of that should be done in the background — it shouldn’t affect your actual text input speed. Auto-format is more along the lines of something that could be blocking, but we’re not dealing with latex problems as to be significant
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#45Earlier quoted context omitted.
I just made hello world window in qt. It's 28 kB. edit: typo
The thing is nobody actually uses hello world programs, by the time you build a real application the difference in RAM usage between that and a good Electron app for example blurs significantly.
I disagree. I remember using lots of GUI apps within a 96MB budget 25 years ago -- even browsers.
Electron does not provide that much more desired features than apps from 25 years ago.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#46This looks nice ! 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 ? (-> https://tonsky.me/blog/disenchantment )
I just made hello world window in qt. It's 28 kB. edit: typo
NodeGui (which is used here) is also running on Qt.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#47Earlier quoted context omitted.
I saw Qt and immediately understood what you were trying to say, but for the record: That’s not what native means. Native means “uses the platform widgets and drawing/theming api” and Qt is not native: it actually draws its own widgets (for the most part with certain exceptions on certain platforms) that are drawn to mimic the system UI with subtle differences. If the system UI implementation suddenly changes (say wi…
Real question, what do some people mean with native C++? Or stuff like react native? Seems like it just equals more performance / peels away an abstract layer.
React Native does extend from platform UI components such as UIView, so that one at least is uncontroversially “native”.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#48Earlier quoted context omitted.
I would say so. Just like GTK is native on GNOME but definitely not on Windows. "native" (to me) really just means whatever the system is designed for.
Then Windows 10 apparently lacks a native GUI toolkit, because it's certainly not "designed for" just one. A similar thing happened to Android.
One could argue Win32 is still the de-facto GUI toolkit in Win10. Things like .NET Windows Forms and (non-WinUI3) UWP are actually rendered with Win32 common controls.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#49This looks nice ! 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 ? (-> https://tonsky.me/blog/disenchantment )
I just made hello world window in qt. It's 28 kB. edit: typo
28kb? You're only seeing the tip of the iceberg. I just built Qt Hello World myself. It's about sixty megabytes in size.
jart@debian:~/scratch/qtproject$ qmake -project
jart@debian:~/scratch/qtproject$ make
jart@debian:~/scratch/qtproject$ ldd ./qtproject | grep -Po '(? )[^ ]*' | xargs ls -alH | awk '{x += $5} END {print x / (1024 * 1024.)}'
59.5916
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#50Very cool, I've been following React-NodeGUI for about a year now and I love Svelte. 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. Anyone have any…
It’s unfortunate but the component library situation is really Svelte’s weak point currently.
At Monitoro[0] we bit the bullet and implemented the vast majority of our components from scratch. Apart from the obvious time to develop and test, and the trailing bugs that are hard to solve for small closed source projects, the experience wasn’t that bad.
Ultimately what helped us the most is writing our components using a state machine-like pattern, mixed with TailwindCSS to make styling easier.
In our case, the effort was worth it as we anyway needed several super specific components, and now that we’re over the hill we have complete control on our UX.
(Also having built component libraries/design systems before in different UI frameworks, doing it in Svelte was one of the best experiences so far)
There are some efforts in the Svelte ecosystem but they’re small and do not have much firepower behind, thus limited or of relatively low quality.