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

191–200 of 281 posts

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

#191

Post by pjmlp »

jbluepolarbear wrote: post #188
pjmlp wrote: post #185

Earlier quoted context omitted.

I use C++ since 1993, moved into Visual C++ around version 6.0, and never used Visual Assist, or any of the JetBrains products that slow down Visual Studio to InteliJ levels of performance. One of my key learnings with alternative languages is to always use the SDK tools from the platform vendor, everything else comes and goes, while playing catch up all the time.

I don’t understand the reasoning against modern tools under the moniker that they’re slow. If you can type out a class in a 10th the time but your ide is 40% slower (as a hypothetical impact) that is a net gain in output. In reality it’s not anywhere near a 40% slow down to use the features on computers made in the last 5 years. Anecdotal to this, I am a slowish typer (40 wpm) and because of this writing code was a l…

Visual Studio has been pretty modern, specially when compared against traditional UNIX offerings.

Anyone measuring typing speed as productivity measurement is doing it wrong.

Writing code is around 50% of daily activities.

Visual Assist doesn't do nothing when I have to write documentation, architecture diagrams, meetings to decide roadmap items, demos at customer review meetings,....

On top of that, none of the OS SDK replacements offer better UI or debugging capabilities across the platform tooling, they just play "catch-me if you can" with what I can get on day 0 of each OS SDK release.

JetBrains wants to be Borland, yet they don't sell any of the platforms, or languages.

I guess Kotlin and Android marriage will help them, as they are trying to make it their "Delphi", lets see how it plays out if Fuchsia ever happens.

https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...

> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA.

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

#192

Post by andi999 »

jbluepolarbear wrote: post #188
pjmlp wrote: post #185

Earlier quoted context omitted.

I use C++ since 1993, moved into Visual C++ around version 6.0, and never used Visual Assist, or any of the JetBrains products that slow down Visual Studio to InteliJ levels of performance. One of my key learnings with alternative languages is to always use the SDK tools from the platform vendor, everything else comes and goes, while playing catch up all the time.

I don’t understand the reasoning against modern tools under the moniker that they’re slow. If you can type out a class in a 10th the time but your ide is 40% slower (as a hypothetical impact) that is a net gain in output. In reality it’s not anywhere near a 40% slow down to use the features on computers made in the last 5 years. Anecdotal to this, I am a slowish typer (40 wpm) and because of this writing code was a l…

It is about the feedback-response loop. If I type a character and it doesn't appear (what feels) instantaneous I start to feel physically sick. I have build up some tolerance but I think when I tried Julia with Atom three years ago, I gave up after 15 minutes (atom too much latency if I remember correctly and Julia as well)

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

#193

Post by himujjal »

LinguaBrowse wrote: post #2

Maintainer here – Happy to answer any questions!

I might go a little offtopic here. Any plans to integrate https://github.com/c-smile/quickjspp. That way you can target mobile platforms too. QT supports mobiles well

As for desktop only this is great. Great work. Many people are commenting on NodeGUI only. They have forgotten to mention how Svelte also contribytes to saving memory footprint and cpu cycles over other frameworks with a much easier way to write apps. Add a small learning curve to that.

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

#194

Post by makapuf »

moosingin3space wrote: post #153
andylynch wrote: post #59

Earlier quoted context omitted.

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 ][…

Another fascinating look into text on computer screens is this article: https://gankra.github.io/blah/text-hates-you/ . Just goes to show that text rendering is actually absurdly complex, unless you drastically restrict the problem space.

This sometimes makes me think we're still on the skeuomorphism phase of text. Its more and more complex to render realistic looking with proper illumination and textured faux leather for your UI until until you just admit you're rendering a ui on a screen and then you're back to colored rectangles. We're still trying to render ideas and words resembling handwriting and print press characters, until we embrace screens and render arial and images or even monospaced fonts which are perfectly readable (I do that all day long on my code editor)

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

#195

Post by fabiospampinato »

tonyarkles wrote: post #120
fabiospampinato wrote: post #42

Earlier quoted context omitted.

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.

Looking at a few things on my machine right now: - Emacs (with 251 open files and IRC running): 100MB - Activity Monitor: 98MB - Word: 227MB - Spotify: 465MB - Slack: 526MB - Thunderbird (not Electron, but a similar weird browser hybrid thing): 663MB - Teams (which appears to be Electron): 747MB I'm not seeing too much of a blur here. The worst chat app (Teams) is using ~7x the RAM of my primary code editor that also…

What some people actually build with Electron doesn't really say much about what people _can_ build with Electron.

You can't just compare Emacs with Spotify here, I can't even scroll a list in Spotify without seeing it disappearing on me momentarily, that says more about Spotify's engineers or project managers than it says about Electron.

Teams and Slack kind of address the same problem and I'm seeing wildly varying numbers reported by you, without knowing anything about how you are using those apps those numbers are meaningless in my opinion, and if you think they are meaningful then clearly you can achieve different results despite addressing the same use case with the same technology stack.

Also there's "chat" and "chat", there's a reason ~nobody uses IRC anymore compared to Slack, they are not the same thing, and it's not just that Slack is easier to use.

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

#197

Post by makapuf »

jcelerier wrote: post #183
jart wrote: post #49

Earlier quoted context omitted.

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 That's bigger than I expected to be honest.

Aren't you also listing all the non Qt libs here ? X11, libinput, pulse audio, dbus, gstreamer, OpenSSL... e.g. here on linux for a static build of Qt (which links against both X11 and wayland platform plug-ins, and uses an embedded libpng, harfbuzz, freetype, etc...) a QWidget hello world comes out at 14 megabytes.

Id say its fair game if building hello world links those gstreamer and openssl.

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

#198

Post by jcelerier »

makapuf wrote: post #197
jcelerier wrote: post #183

Earlier quoted context omitted.

Aren't you also listing all the non Qt libs here ? X11, libinput, pulse audio, dbus, gstreamer, OpenSSL... e.g. here on linux for a static build of Qt (which links against both X11 and wayland platform plug-ins, and uses an embedded libpng, harfbuzz, freetype, etc...) a QWidget hello world comes out at 14 megabytes.

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

#199

Post by jug »

badsectoracula wrote: post #130
fouric wrote: post #94

Earlier quoted context omitted.

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

In case this discussion is still about a 20 MB RAM NodeGUI application, I don't think this is a comparable situation because DOS was really not about developing cross-platform applications with a Turing complete styling language. It was about building text mode tools that ran on x86 and nothing else. I swear even the "bloated" Windows 10 will have absolutely no trouble running a Win32 Console application at < 1 MB RAM consumption but that's not what this is about.
Post reply on HN