Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

github.com

Post reply on HN
Print view View original

121–130 of 281 posts

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#121

Post by kall »

gigel82 wrote: post #116
kall wrote: post #111

Earlier quoted context omitted.

Since you seem to be familiar with both, can you say something about what react-nodegui offers compared to react native? Is it just way simpler to use, like electron? Or does QT offer a more consistent cross platform experience? Or is it more mature than react-native-macos? Or for when you want to run on linux? All things that could be appealing to me if it did that.

react-nodegui is much simpler to use and more compatible because there's just node underneath, whereas react-native has varying js engines per-platform and a large library straddling the native-js bridge that reinvents things like Promise or XHR (it also cannot use native node modules). This reinvention also adds to the bloat (the calculator sample uses around 50Mb RAM with react-native-windows vs. 15Mb with react-no…

Thank you. A more lightweight model is very appealing to me. I just started a react-native-macos experiment, and it's not as smooth as iOS. The tooling alone on a multi platform, non expo RN app... Does react-nodegui offer straightforward builds like electron-builder?

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#122

Post by jiofih »

davej wrote: post #66
danenania wrote: post #10

Looks really good! At first glance, this seems like probably the best Electron alternative I've seen posted on HN. 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. It looks like NodeGUI doesn't currently support cross-compilation--is that something that's on the roadmap? How a…

Strongly agree. Hello World apps are great but it would be even better to see a Hello World tutorial that can actually be distributed to customers. You probably also need auto-update, native installers, code signing (notarization on Mac) and the ability to build native modules cross-platform. This is a super-interesting project though.

Both the App Store and Microsoft Store deal with installs and updates, no need for custom wrappers. Not sure about Linux.

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#123

Post by ComputerGuru »

gigel82 wrote: post #48
nine_k wrote: post #39

Earlier quoted context omitted.

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.

Indeed, but with some exceptions. .NET SWF shipped with extremely kludgy drawn clones of toolbars and menu bars instead of using the native ones (although the native ones were later exposed) and the result is that those particular controls on SWF apps did not age gracefully (DPI problems, system theme mismatch, scroll acceleration issues, etc). That’s the kind of thing Qt would also face with drawn components skinned to look like the real deal.

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#124

Post by davej »

capableweb wrote: post #103
davej wrote: post #66

Earlier quoted context omitted.

Strongly agree. Hello World apps are great but it would be even better to see a Hello World tutorial that can actually be distributed to customers. You probably also need auto-update, native installers, code signing (notarization on Mac) and the ability to build native modules cross-platform. This is a super-interesting project though.

Sure, would be great if everything had everything we need at creation. But this is first a Show HN from a user here and secondly open source software, so I think you need to adjust your expectations a bit. Agree with your final part, very exciting and gonna be interesting to see where nodegui goes, especially security wise.

This is awesome. Props to the authors. My comment was not meant to knock on this project. I'm just pointing out that people should consider distribution if they want to use a tool like this. Putting a desktop app in front of customers is not yet as easy as it is on the web but I'm working on making it better [1].

[1] https://www.todesktop.com/cli

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#125

Post by dsr_ »

Aeolun wrote: post #107
afavour wrote: post #24

Earlier quoted context omitted.

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…

> It's doing autocomplete suggestions, linting code as I type Even so, shouldn’t it be able to do that in 16ms?

Fermi guess: 60 wpm, that's one 5 character word per second, it probably doesn't make sense to give a new prediction more often than once per character -- that's 200ms to chew on autocomplete and linting and fancy animations. Meanwhile, please render the specific character out of your lookup table in 16ms, thank you.

Do modern graphics drivers for X or Wayland hand off font rendering to the GPU? They probably should -- it's maybe 100 or so small textures per font-selection, 150KB or less prerendered with 3-bit alpha, and maybe 100 loaded up into graphics RAM at a time -- 10MB is nothing, really.

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#126

Post by davej »

jiofih wrote: post #122
davej wrote: post #66

Earlier quoted context omitted.

Strongly agree. Hello World apps are great but it would be even better to see a Hello World tutorial that can actually be distributed to customers. You probably also need auto-update, native installers, code signing (notarization on Mac) and the ability to build native modules cross-platform. This is a super-interesting project though.

Both the App Store and Microsoft Store deal with installs and updates, no need for custom wrappers. Not sure about Linux.

End-users are still more familiar with a download link on a website for a exe/dmg installer on desktop.

You also need to need to redo your subscription/payments to support the stores and give a percentage of your revenue to Apple/Microsoft. On mobile you have no option but on desktop it's hard to justify giving up so much of your profit margin when there's a popular alternative.

BTW, Linux has the Snap Store.

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#127

Post by badsectoracula »

afavour wrote: post #24
karteum wrote: post #14

This 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…

I might sound like those weird language evangelists, but...

> we could be writing all our programs in C, still.

You don't need to use C, there are other languages. For example a hello world in Free Pascal[0] (a natively compiled language with no runtime or other dependencies, which supports object oriented programming and has RTTI rich enough to implement automatic object serialization, semi-automatic memory management, strings that know about their encoding, etc) is just 32KB.

Some time ago i wrote Fowl[1], a mostly complete recreation of the OWL toolkit that came with Turbo Pascal for Windows, the demo program of which is around 80KB.

Of course for a more realistic (and MUCH easier to use and develop with) approach, you'd need something like Lazarus[2]. A minimal application in Lazarus is 2.18MB. This might sound too big... and TBH it is, but the size doesn't grow too quickly from there. For example a profiler i wrote recently for Free Pascal applications is... 2.16MB (yes, smaller, why? Well, because i replaced the stupidly huge default icon with a smaller one :-P and without the default icon a minimal application is 2.05MB so the profiler added around 100KB of additional "stuff").

> It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters

FWIW we had those, Visual Basic (or even QBasic) would format your code as you type it, Visual Basic 6 and Visual C++ 6 would profile auto-completion (VB6 even for dynamic stuff), etc. Only issue with C++ was that sometimes it wouldn't work around complex macros.

But modern editors do a bit more, still no excuse for being that sluggish. Lazarus does pretty much everything you'd expect from an IDE with smart code completion (e.g. things like declaring variables automatically, filling method bodies, etc) and code suggestions yet it runs on an original Raspberry Pi.

Now i'm not saying that you should not be using whatever you are using or that you should code on a Rasberry Pi or even to switch to Free Pascal / Lazarus (which honestly is far from being free of issues), but i think that you're overestimating what tools do nowadays and many people are so used to running slow and bloated software that take it for granted that things should be like that and cannot even imagine things being better.

[0] https://www.freepascal.org/

[1] http://runtimeterror.com/tech/fowl/

[2] https://www.lazarus-ide.org/

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#128

Post by ric2b »

fouric wrote: post #94
karteum wrote: post #14

This 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 )

20 MB is less than 0.25% of my desktop machine's memory, and 2% of a 2010-era netbook. 20 MB, while much larger than what it has to be, is tiny even by the standards of decade-old computers. RAM is cheap and plentiful. If you don't use it, its value is almost zero (the "almost" comes from OS-level caching of files and CPU-level cache misses of code).

> If you don't use it, its value is almost zero

But the value is also zero if you're using extra for no benefit. Actually it's negative, because it prevents other programs from using it.

You should try to use all your RAM, yes, _but in ways that are actually useful_. The OS can always use leftover RAM for caching frequently used files if you don't have a better use for it.

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#129

Post by jiofih »

endisneigh wrote: post #29

Is there a way to have some small application that talks to the machine via a set of HTTP apis? 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. I must be missing/forgetting something crucial since that seems…

Chrome used to have a local socket API when chrome apps were still a thing.

Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

#130

Post by badsectoracula »

fouric wrote: post #94
karteum wrote: post #14

This 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 )

20 MB is less than 0.25% of my desktop machine's memory, and 2% of a 2010-era netbook. 20 MB, while much larger than what it has to be, is tiny even by the standards of decade-old computers. RAM is cheap and plentiful. If you don't use it, its value is almost zero (the "almost" comes from OS-level caching of files and CPU-level cache misses of code).

> RAM is cheap and plentiful. If you don't use it, its value is almost zero (the "almost" comes from OS-level caching of files and CPU-level cache misses of code).

I have fond memories of my DOS days and the simplicity inherent in a single tasking environment, however nowadays operating systems allow for more than a single application to run at the same time and each application should play nice with the system resources, so even if RAM is cheap and plentiful it doesn't automatically mean that every application should feel entitled to it.

(and also even during the DOS days we had TSRs which had to be RAM conscious too)

Post reply on HN