Earlier quoted context omitted.
Emacs does those things too, these days. It's still snappier than anything else I've tried recently.
cough vim cough I'm just kidding. Don't want to start a fight here.
[deleted]
Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
181–190 of 281 posts
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#182Earlier 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…
> 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.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#183Earlier quoted context omitted.
I just made hello world window in qt. It's 28 kB. edit: typo
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.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#184This 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…
I bet some of those UI coded in Delphi versions targeting Windows 95 would be way less than 20MB.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#185Earlier quoted context omitted.
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 abo…
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.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#186Earlier quoted context omitted.
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 abo…
Visual Assist improves on what was already there, i never claimed that the functionality was the best it could have been (if anything i wrote the opposite) only that it existed. But it is also an interesting thing to mention because in the last two C++ jobs i had where Visual Assist was preinstalled on my machine, i always disabled it because it was slowing down Visual Studio too much and the functionality VS provide…
Last time I used VAT was in 2013 and it wasn’t an issue on my i5 with an ssd. I would rather put my money into faster hardware to keep up with the demands of modern tools than live without them.
If you’re using Visual Studio for C++ I’d highly recommend Resharper C++. If you develop for Unreal Engine Rider for Unreal C++ is literally unreal, it makes me not hate writing Unreal C++ code.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#187Earlier quoted context omitted.
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…
And the compiled ones also included some form of records.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#188Earlier quoted context omitted.
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 abo…
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 long process for me. With modern tools I can produce a monstrous amount of code in a short amount of time.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#189Earlier quoted context omitted.
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.
How is writing something in vim faster? You can have the same bindings in many IDEs.
Re: Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
#190Earlier 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…
> 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.
Before the second character is typed...