Earlier quoted context omitted.
> This attitude is like buying a sports car and never redlining it. This is a perfect analogy. To stretch it, the majority of sports car owners are developers. The vast majority of your users are not.
We can play this game, sure. The vast majority of cars on the road today have more than enough horsepower and can handle being redlined. Most users have enough RAM unless they're running on some absurdly low 4GB< device, which is just nowhere near as common these days.
Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
271–280 of 281 posts
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#272Earlier 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?
How much time and expertise did it take? Did automatically work on all OSs? Could person without tech background slap something like this in a weekend? Did it have accessibility built-in? Could you reuse it on web?
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#273Earlier 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?
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#274Earlier quoted context omitted.
At least on Linux swap is a great tool for shuffling things you probably statistically wont use again out while retaining the ability to transparently recall them if it turns out your system guessed wrong. If you find yourself in a situation where your OS is actually shuffling things around for your system to function you will find your performance and desktop experience has gone to absolute dog shit. It's entirely l…
> don't run too many app once from people who think unused RAM is wasted RAM The baseline memory usage of Svelte NodeGUI is 20 MB. 400 instances of that can fit into 8 GB of RAM. Don't you even try to tell me that you've run 400 separate GUI applications at once. Let me repeat it again: unused RAM is wasted RAM. This is a fact. It does nothing when neither you nor the OS is using it - and the value of the OS using a…
Any time you actually say this delete the sentence if you want anyone to actually read what you are saying. I made no assertions specifically about NodeGUI. The idea I was responding to is
> the OS will generally move things around to accommodate you as necessary
Because this isn't accurate performance goes to hell when applications contend for ram. If you haven't noticed it you probably have enough ram to not have that issue not because your OS "moved stuff around" at least on windows/linux I have never owned a mac.
I agree that 20MB baseline for a gui app is fine.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#275Earlier quoted context omitted.
This is ridiculous. 20 MB is so far from "all of it" on any modern computer that it makes me question if you're using something from the 90's. How are you even on Hacker News? The reduction of the complex trade-off between memory use, CPU, disk, development environment, ease of deployment, and the dozen other variables that go into a choice like picking what toolkit to use to "don't be a dick" is so absurdly simplist…
> This is ridiculous. 20 MB is so far from "all of it" on any modern computer that it makes me question if you're using something from the 90's. If I look at today's top seller computers in Amazon for my country (France, 6th economic power in the world), the top two models both come with 4G of RAM (a chromebook, and a win10). The windows one will already use ~2gigs just for the OS. That leaves 2 gigs of RAM for your…
It's pretty clear that 2O MB of RAM as baseline memory consumption for a graphical application (we're not talking about a runtime that might be used for a bunch of background processes - that would be an issue) is a non-issue for the vast majority of users of such programs.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#276Earlier quoted context omitted.
> This is ridiculous. 20 MB is so far from "all of it" on any modern computer that it makes me question if you're using something from the 90's. If I look at today's top seller computers in Amazon for my country (France, 6th economic power in the world), the top two models both come with 4G of RAM (a chromebook, and a win10). The windows one will already use ~2gigs just for the OS. That leaves 2 gigs of RAM for your…
Meanwhile, you can fit 100 20MB apps into 2GB. I've never seen a normal desktop user use more than 10 graphical applications at once. I've never used more than 20 at once myself. It's pretty clear that 2O MB of RAM as baseline memory consumption for a graphical application (we're not talking about a runtime that might be used for a bunch of background processes - that would be an issue) is a non-issue for the vast ma…
But if a browser like chrome already uses 1.5 gigs there will be a big difference between the app that uses 500 (your average electron app) and the app that uses 50 (your average Qt, GTK, ex, fltk... app). One will swap and make the whole system slow, the other not.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#277Earlier quoted context omitted.
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.
The license looks ok: https://github.com/c-smile/sciter-js-sdk/blob/main/LICENSE The only unusual limitation is that you're not allowed to say "built with Sciter" without getting permission from the maintenaners. You can still use it for commercial projects though.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#278Very cool, I've been following React-NodeGUI for about a year now and I love Svelte. I especially love the idea of Svelte (compiling to imperative JavaScript code), but since it's technically a "superset" of JavaScript, IDE support has been an issue for me. Also I've cut my teeth trying to find a solid UI component library. These two things have restricted my use of the framework to smaller projects. Anyone have any…
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#279Earlier quoted context omitted.
Flutter isn't a good Electron alternative? Flutter 2.0 just came out with desktop support for osx, windows and linux and will be the main GUI framework for Linux.
> and will be the main GUI framework for Linux. That's already GTK+ and Qt, and the big GTK+ and Qt projects aren't switching over to Flutter any time soon.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#280Earlier quoted context omitted.
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…
This is part of what I meant when I said "drastically restrict the problem space".