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…
Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
161–170 of 281 posts
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#162Earlier 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?
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
#163Earlier 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…
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
#164How 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.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#165This 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…
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
#166Earlier 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.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#167Looks very slick, but I am extremely stressed out by the inconsistent font sizes and button spacing across platforms in the example calculator app.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#168Earlier 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."
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#169Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#170Earlier 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? :)
For searching, use SilverSearcher / fzf