Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
221–230 of 281 posts
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#222I'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. 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 s…
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#223This 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 )
@tonsky is right about the huge memory footprint (in terms of RAM) but 20MB for Hello World GUI program is totally fine today [0]. In my humble experience there is really hard to fit in below 10MB with a GUI app that only displays "Hello World" text, while the next 10MB are often consumed for extra resources like font, rendering cache or custom textures. It might a bit rude to remind that, but the same person saying…
Electron has been around what? 7 years?
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#224Earlier quoted context omitted.
Id say its fair game if building hello world links those gstreamer and openssl.
> Id say its fair game if building hello world links those gstreamer and openssl. why ? it entirely depends on how your linux distro chose to build Qt, not on Qt itself.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#225Earlier quoted context omitted.
> Id say its fair game if building hello world links those gstreamer and openssl. why ? it entirely depends on how your linux distro chose to build Qt, not on Qt itself.
Because application can't run without those libraries. It's like comparing Java application without taking JVM into account.
no, it's not. The "equivalent" of the JVM would be the libQt5{Core,Gui,Widgets...}.so ; but here we are talking about the operating-system-provided libraries, so it is like comparing with a Java application, with the JVM, and also for instance all the MS Windows system libraries, or all the macOS frameworks like CoreFoundation, etc etc.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#226Earlier quoted context omitted.
How is writing something in vim faster? You can have the same bindings in many IDEs.
This thread has been specifically about responsiveness. Latency, not throughput. Also, the bit about no plugins was a little white lie. I really meant "no plugins for IDE-like functionality (language server, etc)". While many IDEs offer basic vim keybindings, I don't know any that would let me import my .vimrc wholesale and work exactly the same. I'd love an IDE that embeds neovim as the text editor. Anyway, if you d…
The VSCode Neovim extension makes neovim run as its backend, while giving you all the IntelliSense etc of VSCode. I can’t tell exactly you how it affects responsiveness as I only toy around with it, but it does feel noticeably better in some aspects...yet maybe occasionally glitchy?
Anyway it’s pretty interesting, especially if you’re already using neovim anyway.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#227Earlier 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'…
8 bit BASICs were extremely tightly coded and packed a lot of functionality. They had working garbage collection for strings, with useful string processing built on it. Programs could be interrupted to safely return to the prompt, and errors which terminated the program informed the user of the line number, e.g. "illegal quantity error in 210". The internal, tokenized representation of programs could be interactively…
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#228Earlier 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'…
Off topic but what did you use for emulating and visualizing your bootsector (blinkenlights.com) in here [0]. Looks much more convenient then QEMU which is what I used last time when doing ring 0 stuff in x86. [0] - https://www.youtube.com/watch?v=hvTHZ6E0Abo
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#229How is it "light" weight? > Low CPU and memory footprint. Current CPU stays at 0% on idle and memory usage is under 20mb for a hello world program. 20MB!
So what? If you stored each Pixel on a modern WQHD monitor, that would be 15mb. Its almost like people on HN dont know what theyre talking about
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#230Is 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…