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

81–90 of 281 posts

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

#81

Post by LinguaBrowse »

jackconsidine wrote: post #31

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

In terms of IDE support, VS Code with the Svelte extension is the best around!

A component library is a bit much to come until Svelte NodeGUI gets a bit more attention. Even Svelte web projects are underpopulated on component libraries, I believe. But it’s worth trying out the built-in primitives first!

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

#82

Post by fabiospampinato »

ficklepickle wrote: post #79
fabiospampinato wrote: post #51

Earlier quoted context omitted.

You can make a very decent Electron app with roughly (roughly = ~2x or less) that amount of RAM too if written well, for that you get pretty much a codebase that you can use everywhere, which on it's own is _massive_.

I've noticed Signal Desktop only uses 100mb. That is quite good for an electron app. A simple server-side node process will use at minimum ~20mb, which obviously does not include a browser. It's open source, I've been meaning to poke around and see what they are doing differently.

There's no secret really, just don't import junk dependencies like most people do and spend some time inspecting your memory usage every now and then, with very little effort you'll probably cut down on your memory usage significantly by doing that. With a lot more effort often you can probably even make something faster than uses less memory than a supposedly native app (if they spent less time than you optimizing it).

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

#83

Post by jart »

caslon wrote: post #69
jart wrote: post #27

Earlier quoted context omitted.

Help me build Cosmopolitan Libc. We're using modern compilers to build programs that are tinier and more portable than anything developers even as far back as the 70's or 80's were able to produce. https://justine.lol/cosmopolitan/howfat.html I built a LISP interpreter too, which makes Altair BASIC look bloated by comparison. https://github.com/jart/sectorlisp I will say that 20mb isn't too shabby if we judge the OP'…

If we're only interested in one/"not-Mac/Win/FreeBSD" of those platforms, how small could we get programs down to? Is forgoing certain platforms supported? Also, there was a really fantastic question asked in the last Cosmopolitan thread, but it wasn't answered; what's the answer to it? https://news.ycombinator.com/item?id=26294721

If you uncheck the boxes on the "how fat" page I linked above, then static binaries for a single platform usually end up being 4kb. Most of that 4kb is padding nops to page size. The question you linked is now answered.

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

#84

Post by gigel82 »

rado wrote: post #41

Calculator demo doesn't run, makes some cmake errors.

The react-nodegui calculator example runs fine for me; on Win10 x64 it uses 14.4Mb of RAM and spawns a single process.

Really impressive resource-wise, now let's get the UI components / frameworks ported...

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

#85

Post by heavyset_go »

LinguaBrowse wrote: post #75
glutamate wrote: post #6

Earlier quoted context omitted.

There are other projects like this - But what would really set it apart would be mobile (iOS and Android) support. Can we do anything to support that happening?

Qt does have an implementation that targets mobile. I don’t know how the licensing works, but in theory there should be a way to rely on Qt for mobile to extend support to iOS and Android. Way out of my own expertise, though!

Qt for Android and Qt for iOS can be used under the LGPL[1]. The issue for iOS, though, is that Apple's App Store violates the terms of the LGPL. To comply with the LGPL, you must make available to iOS users versions of your app that can be linked against user-provided Qt libraries.

If you use the Qt commercial license for either, then you don't need to worry about your app conforming to the LGPL.

[1] https://wiki.qt.io/Licensing-talk-about-mobile-platforms

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

#86

Post by tuxychandru »

ficklepickle wrote: post #79
fabiospampinato wrote: post #51

Earlier quoted context omitted.

You can make a very decent Electron app with roughly (roughly = ~2x or less) that amount of RAM too if written well, for that you get pretty much a codebase that you can use everywhere, which on it's own is _massive_.

I've noticed Signal Desktop only uses 100mb. That is quite good for an electron app. A simple server-side node process will use at minimum ~20mb, which obviously does not include a browser. It's open source, I've been meaning to poke around and see what they are doing differently.

Signal desktop runs as multiple processes. Did you add up all their memory consumption? On my Debian laptop, Signal processes consume about 700 MB of RSS in total, immediately after starting.

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

#87

Post by fao_ »

andylynch wrote: post #59
setr wrote: post #44

Earlier quoted context omitted.

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

Even putting that aside, just showing text on a screen is much slower on modern PCs then older ones, since you have a far more complicated graphics stack and latency at several added steps. I remember an article a couple of years ago where someone rigged up a camera to measure key press to screen update on different machines and the results were eye opening. edit: found it http://danluu.com/input-lag/ . The Apple ][…

Related, my favourite thread to come out of the queer tech circles:

"Almost everything on computers is perceptually slower than it was in 1983" https://threadreaderapp.com/thread/927593460642615296.html

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

#88

Post by ficklepickle »

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…

Dell uses this exact technique on Windows to launch/interact with their driver installation tool from the web. That has decent UX because it comes pre-installed. But, generally, users aren't accustomed to this pattern and any user education requirement is often a non starter in many market segments.

It also has security implications if you are exposing OS functionality to websites. I remember Dell having a bad one a couple years ago.

There is also an antivirus browser extension that works in a similar way. It installs a native C++ executable that the extension interacts with. That has a huge security footprint. IIRC they rolled their own parser (HTML?, JSON?) and it went predictably bad.

There are lots of implications to consider. I'd like to see progressive web apps fill this niche on the desktop. They have various mechanisms for persistence of data and WASM will increase the practical use cases. Hopefully the APIs available to PWAs in the future will allow all sorts of new use cases.

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

#90

Post by esperent »

andylynch wrote: post #59
setr wrote: post #44

Earlier quoted context omitted.

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

Even putting that aside, just showing text on a screen is much slower on modern PCs then older ones, since you have a far more complicated graphics stack and latency at several added steps. I remember an article a couple of years ago where someone rigged up a camera to measure key press to screen update on different machines and the results were eye opening. edit: found it http://danluu.com/input-lag/ . The Apple ][…

> The Apple ][ ties for first place with an iPad Pro.

* When used with an Apple Pencil (30ms). When used with touch it drops to 70ms.

Also, it's worth noting that there's a very limited list of devices tested there and it heavily skews Apple.

Post reply on HN