Live data from Hacker News

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

github.com

161–170 of 281 posts

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

#161
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 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 about the development process from 15 years ago.

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

#162
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?

Among other things we've done to ourselves, we've got higher-resolution displays, and we have GUI apps that can scale to different resolutions seamlessly. We have support for high DPI displays. We have fonts with sub-pixel rendering for sharper, easier to read text. Speaking of font-rendering, we have Unicode and internationalization support, so that people who read and write Arabic, Chinese, Japanese and other languages that don't use the Latin alphabet can use their native language in file names, dialog boxes and in anywhere else they might want to. We have better support for screen readers for the blind. For people who aren't fully blind, but have vision problems, we have the ability to make text and UI features larger dynamically to support them. We have better multitasking support, including process isolation to keep a badly-behaved application from crashing the entire computer. We have better security at the OS level to prevent malicious applications to take over the whole machine.

That's a big part of what we've done to ourselves. And this makes computers better for a whole lot of people.

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

#163
post #162

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?

Among other things we've done to ourselves, we've got higher-resolution displays, and we have GUI apps that can scale to different resolutions seamlessly. We have support for high DPI displays. We have fonts with sub-pixel rendering for sharper, easier to read text. Speaking of font-rendering, we have Unicode and internationalization support, so that people who read and write Arabic, Chinese, Japanese and other langu…

Yeah, no.

First, all those things sans high DPI functionality existed in 1998.

Second, most of Electron apps don't benefit from these theoretical advancements.

Preemptive multitasking existed in 1998 and worked every bit as well as it does today. Even in MS Windows.

Security, nah. We have more attack vectors than at any point in the past. And just more crapola caked on to "protect" against those.

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

#164
post #89

How do you deal with zero day vulnerabilities? To me the biggest concern using browser-as-a-desktop solution is that there will be quite a lag between when Chrome patches zero days vs when it gets released. ex) nw.js, electron.

> 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

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

#165
post #24
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…

> That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things

BEFORE the typed character shows up? Are you sure?

16ms should be an absolute upper bound for a character to show up. Everything else comes after.

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

#166

Earlier quoted context omitted.

Word, thanks! I think it's interesting because Svelte community support is pretty big. The repo's consistently been on Github's Trending repos for the past 2.5 years and it has an impressive number of stars

> been on Github's Trending repos for the past 2.5 years and it has an impressive number of stars Wow, must mean the project is real important. I agree that svelte is interesting, but focusing on metrics and popularity is the wrong approach to new technology.

You can't judge a technology by its popularity. But I was judging the ecosystem by its popularity and those things are very highly correlated. More people bookmarking a project mean in theory it should have better 3rd party library support.

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

#167

Looks very slick, but I am extremely stressed out by the inconsistent font sizes and button spacing across platforms in the example calculator app.

I think this is part of why many people stick with Electron instead of Qt in the first place. Nevertheless, a really cool idea. I will jump ship from Electron as soon as the first viable alternative emerges. However I haven't yet seen a wysiwyg text editing framework that can hold a candle to something like ProseMirror, so for my use case that might be a while.

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

#168
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).

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.

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

#170
post #135

Earlier quoted context omitted.

As mentioned in the other comment, emacs does those things, and so does Vim (with plugins of course). I moved from sublime to atom to VS code, but eventually settled on Vim because I was able to get the same features (that I used) while getting almost instant response. A feeling that has completely changed how much I enjoy writing any sort of text.

I tried to move from VS Code to NeoVim with NerdTree and some other plugins to make it more IDE-like. But eventually wasn't able to get the same code completion, and searching was also a bit more painful. How do you go about that? Would you mind sharing your setup? :)

The vim plugin CoC uses the same engine for code completion as Code. It’s pretty trivial to set up.

For searching, use SilverSearcher / fzf

Post reply on HN