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

171–180 of 281 posts

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

#171

Post by Aeolun »

f430 wrote: post #164
capableweb wrote: post #131

Earlier quoted context omitted.

> To me the biggest concern using browser-as-a-desktop solution Then this project sounds perfect for you because it's not a browser, it's Qt5 but called via APIs that JS developers are used to.

Isn't it rendering html5/javascript like a browser would? it would be great if somebody could take time to reply and explain things in a calm logical manner without reaching for downvotes

I think nobody wants to tell you since it’s something that is easily found on the linked site.

To answer your question, there is no more HTML involved in this than in a React Native app. The result looks like HTML, but it’s really used to compose native OS widgets.

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

#172

Post by badsectoracula »

jbluepolarbear wrote: post #161
badsectoracula wrote: post #127

Earlier quoted context omitted.

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

Visual Assist Tomato wouldn’t have existed if Visual C++ did what you said. I use Rider (mostly) and I don’t even know how I’d program without all the features it adds. Auto import, code cleanup, code optimizations, memory allocation and boxing highlights, decompile assembly, Unity engine integration. I remember the days using Visual C++ and banging away on trying to get QT to not look ugly. I don’t miss anything abo…

Visual Assist improves on what was already there, i never claimed that the functionality was the best it could have been (if anything i wrote the opposite) only that it existed.

But it is also an interesting thing to mention because in the last two C++ jobs i had where Visual Assist was preinstalled on my machine, i always disabled it because it was slowing down Visual Studio too much and the functionality VS provides is more than enough - VA does provide a bit more, but for me wasn't worth the slowdown.

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

#173

Post by conradev »

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 )

On a 2560 x 1600 screen showing 8-bit RGBA, a single full screen buffer would be 15 MB:

(2560 * 1600 * 4) / 1024 / 1024 = 15 MB

So no, that is not huge for a modern GUI program.

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

#174

Post by akhilcacharya »

abraxas wrote: post #144
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…

I wrote 3D visualization apps in 1998 using FLTK and OpenGL and the (statically linked) binary was less than 20 MB. I think my desktop had all of 64MB of RAM. It was snappier than a modern TODO app on Electron and far, far easier to write. What on earth have we done to ourselves?

Easier to write? I’m curious are there any sample apps like this that I can read?

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

#175

Post by anilgulecha »

c-smile wrote: post #150

Same demo in VanilaJS and Sciter.JS : https://github.com/c-smile/sciter-js-sdk (see screenshots there). Binary is ~5MB, and that is HTML/CSS + QuickJS + NodeJS runtime. Versus 50MB+ of NodeGUI that is Node.JS + QT. And SvelteJS works in Sciter.JS out of the box too.

Hi c-smile - i always get confused about the FOSS status of sciter related projects. It's a very promising platform - specially being CSS/HTML/JS at a low resource footprint.

I recall a crowd-sourcing campaign to make this toolset fully open - did that succeed? What's the current state? For me a signal to use sciter would be it's inclusion into the debian/ubuntu repository.

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

#176

Post by [deleted] »

conradev wrote: post #173
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 )

On a 2560 x 1600 screen showing 8-bit RGBA, a single full screen buffer would be 15 MB: (2560 * 1600 * 4) / 1024 / 1024 = 15 MB So no, that is not huge for a modern GUI program.

[deleted]

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

#177

Post by tleb_ »

tshaddox wrote: post #143
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

I’m pretty sure that none of these latency benchmarks are showing that text input speed is affected. You can definitely input more than 1 character every 40ms in modern “slow” text editors.

The question isn't about throughtput but latency.

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

#178

Post by abraxas »

akhilcacharya wrote: post #174
abraxas wrote: post #144

Earlier quoted context omitted.

I wrote 3D visualization apps in 1998 using FLTK and OpenGL and the (statically linked) binary was less than 20 MB. I think my desktop had all of 64MB of RAM. It was snappier than a modern TODO app on Electron and far, far easier to write. What on earth have we done to ourselves?

Easier to write? I’m curious are there any sample apps like this that I can read?

Sure. Check out the tutorial that has remained pretty much the same since I used it to learn FLTK + GL 23 years ago:

https://www.fltk.org/doc-1.3/fluid.html

You pretty much draw the UI in fluid and fill out the callbacks. Yeah it's C++ but it's not particularly esoteric C++.

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

#179

Post by varajelle »

empyrical wrote: post #102
flipcoder wrote: post #54

Earlier quoted context omitted.

From Qt's page https://www.qt.io/licensing/open-source-lgpl-obligations : "In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library."

Also, Chromium's Blink renderer has a lot of LGPLv2 source files that date back to the KDE KHTML days[1] and as you can see by the numerous proprietary applications that use Electron and Chromium Embedded Framework, that this doesn't hinder companies from using LGPL libraries as long as they abide by the license. However, one thing to note: the OSS version of Qt uses the LGPLv3 license, which has additional restricti…

The "Anti-Tivoization" clause is only applicable for hardware that are distributed with GPL/LGPL software included. It does not concern the app store.

The use of LGPLv2 on the iOS AppStore seems to be controversial. But nothing changes with LGPLv3 in that respect as far as I know.

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

#180

Post by jbverschoor »

square_usual wrote: post #168
reaperducer wrote: post #136

Earlier quoted context omitted.

HN: "RAM is cheap and plentiful." Also HN: "The MacBook Pro is worthless if I can't get it with at least 64GB of RAM."

Those don't seem contradictory to me. RAM is cheap and plentiful, and getting 64GB of RAM is easy, but Apple just doesn't want to sell that config right now. You can still get a 64GB config on another system.

Everyday users don’t get Ram upgrades. Many programmers are elitist snobs without any consideration for the end user
Post reply on HN