If you can’t reuse/share a lot of web technologies/stacks/libraries. Why would you not go for flutter instead
Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
151–160 of 281 posts
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#152Earlier 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? :)
Write code in vim with no/few plugins. Don't worry about getting the variable names right. Then move to your IDE to get it to compile.
It's conceptually similar to sketching out the design of your code with a pen and paper or whiteboard. First write it quickly, then make it correct.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#153Earlier 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
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.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#154This 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 )
Help me build Cosmopolitan Libc. We're using modern compilers to build programs that are tinier and more portable than anything developers even as far back as the 70's or 80's were able to produce. https://justine.lol/cosmopolitan/howfat.html I built a LISP interpreter too, which makes Altair BASIC look bloated by comparison. https://github.com/jart/sectorlisp I will say that 20mb isn't too shabby if we judge the OP'…
8 bit BASICs were extremely tightly coded and packed a lot of functionality. They had working garbage collection for strings, with useful string processing built on it. Programs could be interrupted to safely return to the prompt, and errors which terminated the program informed the user of the line number, e.g. "illegal quantity error in 210". The internal, tokenized representation of programs could be interactively edited to update the program, which could be saved to disk. BASICS also had floating-point support, with functions like LOG, EXP, SIN, COS, TAN, ATAN, ... Also arrays, including multi-dimensional ones.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#155Looks really good! At first glance, this seems like probably the best Electron alternative I've seen posted on HN. Apart from the consistent GUI layer, I think an underrated reason that many teams stick with Electron is the mature tooling for cross-platform builds and upgrades. It's pretty painful to DIY. It looks like NodeGUI doesn't currently support cross-compilation--is that something that's on the roadmap? How a…
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.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#156Earlier 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…
> It's doing autocomplete suggestions, linting code as I type Even so, shouldn’t it be able to do that in 16ms?
they certainly could. Games can do 16ms frames, while calculating full physics simulations.
It's just that text editors of the modern day are programmed by people who prefer to not write it that way - mainly because it's quite hard, and the modern OS doesn't usually fit well into this framework of rendering for multi-tasking. And it takes more effort too.
Much easier to rely on a UI framework which adds overhead. The expectation is that the user probably won't care, and prefer that the software be more feature rich.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#157Looks really good! At first glance, this seems like probably the best Electron alternative I've seen posted on HN. Apart from the consistent GUI layer, I think an underrated reason that many teams stick with Electron is the mature tooling for cross-platform builds and upgrades. It's pretty painful to DIY. It looks like NodeGUI doesn't currently support cross-compilation--is that something that's on the roadmap? How a…
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.
There was a lot of criticism, especially of the Web version, in https://news.ycombinator.com/item?id=26332944
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#158Earlier quoted context omitted.
Related, my favourite thread to come out of the queer tech circles: "Almost everything on computers is perceptually slower than it was in 1983" https://threadreaderapp.com/thread/927593460642615296.html
Google Maps is a truly horrendous interface. It's pretty, it's well built, but it's fundamentally a horrible UX. I find myself frequently bamboozled until I stop and try and determine which mode I'm in. Navigation behaves differently to browsing, which behaves differently to searching, which behaves differently to viewing an individual result. I'll be thrown from one mode to another and never feel in control of the a…
I hate it with passion. Clicking a photo on a café in the main view, horrendous because it does not actually open the photo, nor the overview on the café screen. Have to be on the photos screen for the photo to open up full screen.
Pressing on some place while being in other than top mode.
The back button experience.
And the bottom drawer, no idea when I should pull it up or down, or if I am currently in it.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#159Maintainer here – Happy to answer any questions!
Is there a story for interop with other languages? I understand the UI probably has to be defined in JS, but what about transparently making request to a local server written in another language (bonus point if it can somehow be made less observable than that, i.e. not consuming a localhost port).
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#160Earlier quoted context omitted.
> 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…
>and each application should play nice with the system resources, so even if RAM is cheap and plentiful it doesn't automatically mean that every application should feel entitled to it. Yes, you shouldn't be a bad neighbor, but the OS will generally move things around to accommodate you as necessary. RAM is an afterthought for most of these applications for a reason. This attitude is like buying a sports car and never…
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 likely that the user will actually hard reboot the machine because they conclude it has frozen.
The absolutely only way to have a nice desktop experience in Linux is to ensure you have enough ram for all the things you intend to run at once which means have at least 8GB-16GB of RAM and don't run too many app once from people who think unused RAM is wasted RAM.