14 ms·

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 th

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 https://tonsky.me/blog/disenchantment )

mixedCase 6y ago
It's definitely not. It's just a different toolkit that the one you already have in memory, so it can't "cheat".
afavour 6y ago
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 somewhere in the middle. OT but a bone to pick with that article: > Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters. Sometimes I feel like people forget that.
- setr 6y ago
  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
  - andylynch 6y ago
    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/ http://danluu.com/input-lag/. The Apple ][ ties for first place with an iPad Pro.
    - jart 6y ago
      Are you referring to this submission? https://news.ycombinator.com/item?id=23369999 https://news.ycombinator.com/item?id=23369999 Outstanding article. Total shame it only got 100 upvotes.
    - fao_ 6y ago
      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 https://threadreaderapp.com/thread/927593460642615296.html
      - underwater 6y ago
        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 app.
        1ark 6y ago
        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.
  - tshaddox 6y ago
    I’m pretty sure that none of these latency benchmarks are showing that text input speed is affected. You can definitely input more than 1 character every 40ms in modern “slow” text editors.
    - tleb_ 6y ago
      The question isn't about throughtput but latency.
- anthk 6y ago
  >all sorts of things we never had a couple of decades ago We had them.
- throwanem 6y ago
  Emacs does those things too, these days. It's still snappier than anything else I've tried recently.
  - unknown2374 6y ago
    cough vim cough I'm just kidding. Don't want to start a fight here.
    - throwanem 6y ago
      Well, with vim, it probably depends more on your terminal and tmux, while Emacs renders its own graphical frames. But those wars are long over anyway, these days. One might just as well fight over whether the monolith on Earth's moon is better than the one on Europa, or vice versa.
    - deleted 6y ago
      [deleted]
  - GuB-42 6y ago
    Interesting how what was seen as slow and bloated back then become the opposite today. Eight Megabytes And Constantly Swapping, yep, back then, 8MB was unthinkably large for a text editor... Another example is the Enlightenment window manager. It was considered a little heavy, but good looking. But because there was a large hiatus in development, it got "stuck in the past" and now, it is one of the lightest there is.
- unknown2374 6y ago
  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.
  - higerordermap 6y ago
    Yeah. LSP has changed a lot for me. For C/C++, could use QT Creater or KDevelop too, which I think are pretty good in latency.
  - zant 6y ago
    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? :)
    - smichel17 6y ago
      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.
      - bobmaxup 6y ago
        How is writing something in vim faster? You can have the same bindings in many IDEs.
        eska 6y ago
        Stop trying to use vim like your IDE. Vim doesn't have shortcuts, it has a whole language of commands that can freely be combined.
        6y ago
- Aeolun 6y ago
  > It's doing autocomplete suggestions, linting code as I type Even so, shouldn’t it be able to do that in 16ms?
  - dsr_ 6y ago
    Fermi guess: 60 wpm, that's one 5 character word per second, it probably doesn't make sense to give a new prediction more often than once per character -- that's 200ms to chew on autocomplete and linting and fancy animations. Meanwhile, please render the specific character out of your lookup table in 16ms, thank you. Do modern graphics drivers for X or Wayland hand off font rendering to the GPU? They probably should -- it's maybe 100 or so small textures per font-selection, 150KB or less prerendered with 3-bit alpha, and maybe 100 loaded up into graphics RAM at a time -- 10MB is nothing, really.
  - chii 6y ago
    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.
- xvilka 6y ago
  > IMO there's a tradeoff: we could be writing all our programs in C, still. No need for that - you could use Zig or Rust. Though both need a better GUI frameworks, but it's certainly more efficient with them.
  - deleted 6y ago
    [deleted]
- badsectoracula 6y ago
  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 management, strings that know about their encoding, etc) is just 32KB. Some time ago i wrote Fowl[1], a mostly complete recreation of the OWL toolkit that came with Turbo Pascal for Windows, the demo program of which is around 80KB. Of course for a more realistic (and MUCH easier to use and develop with) approach, you'd need something like Lazarus[2]. A minimal application in Lazarus is 2.18MB. This might sound too big... and TBH it is, but the size doesn't grow too quickly from there. For example a profiler i wrote recently for Free Pascal applications is... 2.16MB (yes, smaller, why? Well, because i replaced the stupidly huge default icon with a smaller one :-P and without the default icon a minimal application is 2.05MB so the profiler added around 100KB of additional "stuff"). > It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters FWIW we had those, Visual Basic (or even QBasic) would format your code as you type it, Visual Basic 6 and Visual C++ 6 would profile auto-completion (VB6 even for dynamic stuff), etc. Only issue with C++ was that sometimes it wouldn't work around complex macros. But modern editors do a bit more, still no excuse for being that sluggish. Lazarus does pretty much everything you'd expect from an IDE with smart code completion (e.g. things like declaring variables automatically, filling method bodies, etc) and code suggestions yet it runs on an original Raspberry Pi. Now i'm not saying that you should not be using whatever you are using or that you should code on a Rasberry Pi or even to switch to Free Pascal / Lazarus (which honestly is far from being free of issues), but i think that you're overestimating what tools do nowadays and many people are so used to running slow and bloated software that take it for granted that things should be like that and cannot even imagine things being better. [0] https://www.freepascal.org/ https://www.freepascal.org/ [1] http://runtimeterror.com/tech/fowl/ http://runtimeterror.com/tech/fowl/ [2] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
  - jbluepolarbear 6y ago
    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.
- abraxas 6y ago
  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?
  - cwyers 6y ago
    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.
    - abraxas 6y ago
      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.
  - akhilcacharya 6y ago
    Easier to write? I’m curious are there any sample apps like this that I can read?
- naikrovek 6y ago
  > 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.
  - andi999 6y ago
    Before the second character is typed...
    - spacechild1 6y ago
      No. These things should happen concurrently, probably on different threads. If I quickly type “foo“, I don't need to do run autocomplete and code analysis between each character. That would be horrible.
- pjmlp 6y ago
  I bet some of those UI coded in Delphi versions targeting Windows 95 would be way less than 20MB.
  - qw 6y ago
    Many years ago I wrote a simple Delphi application that used the standard rich text editor. The size was less than 150kB
- canadianfella 6y ago
  It outrages you somewhat?
jart 6y ago
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 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 https://github.com/jart/sectorlisp I will say that 20mb isn't too shabby if we judge the OP's project by Electron standards. If NodeGUI was pruned a bit more, it wouldn't be too far off from where Go is at right now for Hello World on the console. Although one does have to take into consideration that it assumes external dependencies are available such as V8 I assume? Does it statically build? One thing I'm curious about is I looked at the yarn lock file and I couldn't find Qt so I have no idea where it comes from.
- kitd 6y ago
  I can't remember the precise mechanism, but IIRC the base NodeGUI pkg downloads and builds a minimal QT, and then links into it using NodeGUI/qode which hooks up the Node and Qt event loops.
- caslon 6y ago
  If we're only interested in one/"not-Mac/Win/FreeBSD" of those platforms, how small could we get programs down to? Is forgoing certain platforms supported? Also, there was a really fantastic question asked in the last Cosmopolitan thread, but it wasn't answered; what's the answer to it? https://news.ycombinator.com/item?id=26294721 https://news.ycombinator.com/item?id=26294721
  - jart 6y ago
    If you uncheck the boxes on the "how fat" page I linked above, then static binaries for a single platform usually end up being 4kb. Most of that 4kb is padding nops to page size. The question you linked is now answered.
- anthk 6y ago
  > built a LISP interpreter too, Some friend of mine like it :D. But I'd like that more if it was Scheme.
agumonkey 6y ago
It's probably to be put against Electron HelloWorld resources usage. If this project manages to cut it in half then it's a good step. Maybe competition will cut it in half once more. Considering the amount of Electron based apps around it can save quite a few GB worldwide :)
mrwoggle 6y ago
I just made hello world window in qt. It's 28 kB. edit: typo
- jart 6y ago
  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.
  - jcelerier 6y ago
    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.
    - makapuf 6y ago
      Id say its fair game if building hello world links those gstreamer and openssl.
      - jcelerier 6y ago
        > Id say its fair game if building hello world links those gstreamer and openssl. why ? it entirely depends on how your linux distro chose to build Qt, not on Qt itself.
        EvilEy3 6y ago
        Because application can't run without those libraries. It's like comparing Java application without taking JVM into account.
lhorie 6y ago
That actually sounds kinda impressive, considering [0] says a minimal standard Qt hello world app is ~5mb and stock node.js is ~100MB. I'm curious what kind of magic is happening where node.js is in the picture yet the executable comes out at ~20MB. Is it simply a bundle of wrappers for most of Qt with Node.js being required to be installed separately? Is it purely UPX compression? [0] https://stackoverflow.com/questions/450455/minimal-qt-executable-size https://stackoverflow.com/questions/450455/minimal-qt-execut...
- lhorie 6y ago
  Poked a bit more. It seems the 20Mb claim is indeed mostly only about runtime memory, and doesn't translate to equivalent disk usage. The entry point in ther starter kit calls qode (a fork of node), which talks to qt via napi (node's API for c++ bindings). It can be distributed as binaries via the *-deployqt toolchains. So for distributable binary size in disk, we're probably looking at something in the ~100mb range with no UPX shenanigans. So, tl;dr not as magical as I initially assumed. The trade-off between "bloat" vs ability to use web paradigms feels like a reasonable one. Overall pretty cool stuff.
- jiofih 6y ago
  A node OS X build is 13mb, 20mb on Linux.
  - lhorie 6y ago
    Are you looking at tar.gz files in nodejs.org/dist? Those are compressed. "Get info" on the actual binary on my OSX gives me a number closer to 80MB.
pier25 6y ago
A couple of years ago we switched an Electron/Cordova application to the native OS Webview (WKWebView on macOS and iOS, etc). The UI was written with Inferno + MobX and the backend in Swift/C#/Kotlin depending on the platform. IIRC on macOS it consumed less than 15MB.
pqb 6y ago
@tonsky is right about the huge memory footprint (in terms of RAM) but 20MB for Hello World GUI program is totally fine today [0]. In my humble experience there is really hard to fit in below 10MB with a GUI app that only displays "Hello World" text, while the next 10MB are often consumed for extra resources like font, rendering cache or custom textures. It might a bit rude to remind that, but the same person saying aforementioned words about huge memory usage promotes the Skija [1], Java-based GUI toolkit, which is even worse in memory consumption than electron (jb-compose provided examples, even in release builds). [0] Memory Footprint of GUI Toolkits - https://szibele.com/memory-footprint-of-gui-toolkits/ https://szibele.com/memory-footprint-of-gui-toolkits/ [1] Graphics for JVM - https://tonsky.me/blog/skija/ https://tonsky.me/blog/skija/
- EvilEy3 6y ago
  Compose is alpha tech. Even more alpha than it is on Android. Electron has been around what? 7 years?
fouric 6y ago
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).
- hypertele-Xii 6y ago
  > If you don't use it, its value is almost zero Yet if you use all of it, its value is also zero - to every other program on the same computer. Don't be a dick; Use what you need, not all you can.
  - texasbigdata 6y ago
    Conversely, to the end user, if they could pick a bit more resources usage (knowing they can close your app, or heaven forbid uninstall it) versus an extra feature what should the dev team prioritise?
  - fouric 6y ago
    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 simplistic. It's a trade-off - not a single-axis "good or bad" decision. Moreover, 20 MB of memory usage is going to be an acceptable trade-off for the majority of HN users, who skew webdev, not embedded.
    - jcelerier 6y ago
      > 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 apps. And that's for computers being sold today - they will still be in use in five years.
klingon79 6y ago
I’m less concerned about the footprint and more about security. It can be assumed that anything running on the desktop has or will have vulnerabilities. The rise of web applications has been partially due to the assumption of great sandboxing. I look forward to this project doing well, but it’s not the first time I’ve seen an electron competitor on HN promoting it being Node-based. Node isn’t sandboxed by default.
- LinguaBrowse 6y ago
  Another commenter brought up the idea of porting it to Deno – I’m not sure how inter-compatible the two are, but it provides a hopeful future direction to facilitate sandboxing.
mhh__ 6y ago
The trick is really whether 20MB is the short end of bad graph, or a constant offset on the end of a good trend.
conradev 6y ago
On a 2560 x 1600 screen showing 8-bit RGBA, a single full screen buffer would be 15 MB: (2560 * 1600 * 4) / 1024 / 1024 = 15 MB So no, that is not huge for a modern GUI program.
- deleted 6y ago
  [deleted]
bflies 6y ago
20 compared to the typical 80mb electron footprint is 4x better.
OOPMan 6y ago
It is huge. After doing web dev for years I wrote a desktop application with Qt. It's not massively complex (but a lot more complex than a hello world) but when it's running the memory usage is very low even compared to 20mb
jcelerier 6y ago
One thing is, as someone who develops cross-platform software, you really want font rendering & unicode support to be exactly the same across platforms, so that users don't have a save file that looks one way when opened on a Mac and another way when opened on a Windows. This means that you can't use the OS provided facilities (as they all have different metrics) and have to bundle good font rendering engines (if you care about non-us-ascii people) - that means already ~7-8 megabytes at the bare minimum for that.

mixedCase 6y ago

It's definitely not. It's just a different toolkit that the one you already have in memory, so it can't "cheat".

afavour 6y ago

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 somewhere in the middle. OT but a bone to pick with that article: > Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters. Sometimes I feel like people forget that.

setr 6y ago
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
- andylynch 6y ago
  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/ http://danluu.com/input-lag/. The Apple ][ ties for first place with an iPad Pro.
  - jart 6y ago
    Are you referring to this submission? https://news.ycombinator.com/item?id=23369999 https://news.ycombinator.com/item?id=23369999 Outstanding article. Total shame it only got 100 upvotes.
  - fao_ 6y ago
    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 https://threadreaderapp.com/thread/927593460642615296.html
    - underwater 6y ago
      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 app.
      - 1ark 6y ago
        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.
- tshaddox 6y ago
  I’m pretty sure that none of these latency benchmarks are showing that text input speed is affected. You can definitely input more than 1 character every 40ms in modern “slow” text editors.
  - tleb_ 6y ago
    The question isn't about throughtput but latency.
anthk 6y ago
>all sorts of things we never had a couple of decades ago We had them.
throwanem 6y ago
Emacs does those things too, these days. It's still snappier than anything else I've tried recently.
- unknown2374 6y ago
  cough vim cough I'm just kidding. Don't want to start a fight here.
  - throwanem 6y ago
    Well, with vim, it probably depends more on your terminal and tmux, while Emacs renders its own graphical frames. But those wars are long over anyway, these days. One might just as well fight over whether the monolith on Earth's moon is better than the one on Europa, or vice versa.
  - deleted 6y ago
    [deleted]
- GuB-42 6y ago
  Interesting how what was seen as slow and bloated back then become the opposite today. Eight Megabytes And Constantly Swapping, yep, back then, 8MB was unthinkably large for a text editor... Another example is the Enlightenment window manager. It was considered a little heavy, but good looking. But because there was a large hiatus in development, it got "stuck in the past" and now, it is one of the lightest there is.
unknown2374 6y ago
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.
- higerordermap 6y ago
  Yeah. LSP has changed a lot for me. For C/C++, could use QT Creater or KDevelop too, which I think are pretty good in latency.
- zant 6y ago
  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? :)
  - smichel17 6y ago
    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.
    - bobmaxup 6y ago
      How is writing something in vim faster? You can have the same bindings in many IDEs.
      - eska 6y ago
        Stop trying to use vim like your IDE. Vim doesn't have shortcuts, it has a whole language of commands that can freely be combined.
      - 6y ago
Aeolun 6y ago
> It's doing autocomplete suggestions, linting code as I type Even so, shouldn’t it be able to do that in 16ms?
- dsr_ 6y ago
  Fermi guess: 60 wpm, that's one 5 character word per second, it probably doesn't make sense to give a new prediction more often than once per character -- that's 200ms to chew on autocomplete and linting and fancy animations. Meanwhile, please render the specific character out of your lookup table in 16ms, thank you. Do modern graphics drivers for X or Wayland hand off font rendering to the GPU? They probably should -- it's maybe 100 or so small textures per font-selection, 150KB or less prerendered with 3-bit alpha, and maybe 100 loaded up into graphics RAM at a time -- 10MB is nothing, really.
- chii 6y ago
  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.
xvilka 6y ago
> IMO there's a tradeoff: we could be writing all our programs in C, still. No need for that - you could use Zig or Rust. Though both need a better GUI frameworks, but it's certainly more efficient with them.
- deleted 6y ago
  [deleted]
badsectoracula 6y ago
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 management, strings that know about their encoding, etc) is just 32KB. Some time ago i wrote Fowl[1], a mostly complete recreation of the OWL toolkit that came with Turbo Pascal for Windows, the demo program of which is around 80KB. Of course for a more realistic (and MUCH easier to use and develop with) approach, you'd need something like Lazarus[2]. A minimal application in Lazarus is 2.18MB. This might sound too big... and TBH it is, but the size doesn't grow too quickly from there. For example a profiler i wrote recently for Free Pascal applications is... 2.16MB (yes, smaller, why? Well, because i replaced the stupidly huge default icon with a smaller one :-P and without the default icon a minimal application is 2.05MB so the profiler added around 100KB of additional "stuff"). > It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters FWIW we had those, Visual Basic (or even QBasic) would format your code as you type it, Visual Basic 6 and Visual C++ 6 would profile auto-completion (VB6 even for dynamic stuff), etc. Only issue with C++ was that sometimes it wouldn't work around complex macros. But modern editors do a bit more, still no excuse for being that sluggish. Lazarus does pretty much everything you'd expect from an IDE with smart code completion (e.g. things like declaring variables automatically, filling method bodies, etc) and code suggestions yet it runs on an original Raspberry Pi. Now i'm not saying that you should not be using whatever you are using or that you should code on a Rasberry Pi or even to switch to Free Pascal / Lazarus (which honestly is far from being free of issues), but i think that you're overestimating what tools do nowadays and many people are so used to running slow and bloated software that take it for granted that things should be like that and cannot even imagine things being better. [0] https://www.freepascal.org/ https://www.freepascal.org/ [1] http://runtimeterror.com/tech/fowl/ http://runtimeterror.com/tech/fowl/ [2] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
- jbluepolarbear 6y ago
  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.
abraxas 6y ago
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?
- cwyers 6y ago
  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.
  - abraxas 6y ago
    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.
- akhilcacharya 6y ago
  Easier to write? I’m curious are there any sample apps like this that I can read?
naikrovek 6y ago
> 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.
- andi999 6y ago
  Before the second character is typed...
  - spacechild1 6y ago
    No. These things should happen concurrently, probably on different threads. If I quickly type “foo“, I don't need to do run autocomplete and code analysis between each character. That would be horrible.
pjmlp 6y ago
I bet some of those UI coded in Delphi versions targeting Windows 95 would be way less than 20MB.
- qw 6y ago
  Many years ago I wrote a simple Delphi application that used the standard rich text editor. The size was less than 150kB
canadianfella 6y ago
It outrages you somewhat?

jart 6y ago

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 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 https://github.com/jart/sectorlisp I will say that 20mb isn't too shabby if we judge the OP's project by Electron standards. If NodeGUI was pruned a bit more, it wouldn't be too far off from where Go is at right now for Hello World on the console. Although one does have to take into consideration that it assumes external dependencies are available such as V8 I assume? Does it statically build? One thing I'm curious about is I looked at the yarn lock file and I couldn't find Qt so I have no idea where it comes from.

kitd 6y ago
I can't remember the precise mechanism, but IIRC the base NodeGUI pkg downloads and builds a minimal QT, and then links into it using NodeGUI/qode which hooks up the Node and Qt event loops.
caslon 6y ago
If we're only interested in one/"not-Mac/Win/FreeBSD" of those platforms, how small could we get programs down to? Is forgoing certain platforms supported? Also, there was a really fantastic question asked in the last Cosmopolitan thread, but it wasn't answered; what's the answer to it? https://news.ycombinator.com/item?id=26294721 https://news.ycombinator.com/item?id=26294721
- jart 6y ago
  If you uncheck the boxes on the "how fat" page I linked above, then static binaries for a single platform usually end up being 4kb. Most of that 4kb is padding nops to page size. The question you linked is now answered.
anthk 6y ago
> built a LISP interpreter too, Some friend of mine like it :D. But I'd like that more if it was Scheme.

agumonkey 6y ago

It's probably to be put against Electron HelloWorld resources usage. If this project manages to cut it in half then it's a good step. Maybe competition will cut it in half once more. Considering the amount of Electron based apps around it can save quite a few GB worldwide :)

mrwoggle 6y ago

I just made hello world window in qt. It's 28 kB. edit: typo

jart 6y ago
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.
- jcelerier 6y ago
  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.
  - makapuf 6y ago
    Id say its fair game if building hello world links those gstreamer and openssl.
    - jcelerier 6y ago
      > Id say its fair game if building hello world links those gstreamer and openssl. why ? it entirely depends on how your linux distro chose to build Qt, not on Qt itself.
      - EvilEy3 6y ago
        Because application can't run without those libraries. It's like comparing Java application without taking JVM into account.

lhorie 6y ago

That actually sounds kinda impressive, considering [0] says a minimal standard Qt hello world app is ~5mb and stock node.js is ~100MB. I'm curious what kind of magic is happening where node.js is in the picture yet the executable comes out at ~20MB. Is it simply a bundle of wrappers for most of Qt with Node.js being required to be installed separately? Is it purely UPX compression? [0] https://stackoverflow.com/questions/450455/minimal-qt-executable-size https://stackoverflow.com/questions/450455/minimal-qt-execut...

lhorie 6y ago
Poked a bit more. It seems the 20Mb claim is indeed mostly only about runtime memory, and doesn't translate to equivalent disk usage. The entry point in ther starter kit calls qode (a fork of node), which talks to qt via napi (node's API for c++ bindings). It can be distributed as binaries via the *-deployqt toolchains. So for distributable binary size in disk, we're probably looking at something in the ~100mb range with no UPX shenanigans. So, tl;dr not as magical as I initially assumed. The trade-off between "bloat" vs ability to use web paradigms feels like a reasonable one. Overall pretty cool stuff.
jiofih 6y ago
A node OS X build is 13mb, 20mb on Linux.
- lhorie 6y ago
  Are you looking at tar.gz files in nodejs.org/dist? Those are compressed. "Get info" on the actual binary on my OSX gives me a number closer to 80MB.

pier25 6y ago

A couple of years ago we switched an Electron/Cordova application to the native OS Webview (WKWebView on macOS and iOS, etc). The UI was written with Inferno + MobX and the backend in Swift/C#/Kotlin depending on the platform. IIRC on macOS it consumed less than 15MB.

pqb 6y ago

@tonsky is right about the huge memory footprint (in terms of RAM) but 20MB for Hello World GUI program is totally fine today [0]. In my humble experience there is really hard to fit in below 10MB with a GUI app that only displays "Hello World" text, while the next 10MB are often consumed for extra resources like font, rendering cache or custom textures. It might a bit rude to remind that, but the same person saying aforementioned words about huge memory usage promotes the Skija [1], Java-based GUI toolkit, which is even worse in memory consumption than electron (jb-compose provided examples, even in release builds). [0] Memory Footprint of GUI Toolkits - https://szibele.com/memory-footprint-of-gui-toolkits/ https://szibele.com/memory-footprint-of-gui-toolkits/ [1] Graphics for JVM - https://tonsky.me/blog/skija/ https://tonsky.me/blog/skija/

EvilEy3 6y ago
Compose is alpha tech. Even more alpha than it is on Android. Electron has been around what? 7 years?

fouric 6y ago

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

hypertele-Xii 6y ago
> If you don't use it, its value is almost zero Yet if you use all of it, its value is also zero - to every other program on the same computer. Don't be a dick; Use what you need, not all you can.
- texasbigdata 6y ago
  Conversely, to the end user, if they could pick a bit more resources usage (knowing they can close your app, or heaven forbid uninstall it) versus an extra feature what should the dev team prioritise?
- fouric 6y ago
  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 simplistic. It's a trade-off - not a single-axis "good or bad" decision. Moreover, 20 MB of memory usage is going to be an acceptable trade-off for the majority of HN users, who skew webdev, not embedded.
  - jcelerier 6y ago
    > 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 apps. And that's for computers being sold today - they will still be in use in five years.

klingon79 6y ago

I’m less concerned about the footprint and more about security. It can be assumed that anything running on the desktop has or will have vulnerabilities. The rise of web applications has been partially due to the assumption of great sandboxing. I look forward to this project doing well, but it’s not the first time I’ve seen an electron competitor on HN promoting it being Node-based. Node isn’t sandboxed by default.

LinguaBrowse 6y ago
Another commenter brought up the idea of porting it to Deno – I’m not sure how inter-compatible the two are, but it provides a hopeful future direction to facilitate sandboxing.

mhh__ 6y ago

The trick is really whether 20MB is the short end of bad graph, or a constant offset on the end of a good trend.

conradev 6y ago

On a 2560 x 1600 screen showing 8-bit RGBA, a single full screen buffer would be 15 MB: (2560 * 1600 * 4) / 1024 / 1024 = 15 MB So no, that is not huge for a modern GUI program.

deleted 6y ago
[deleted]

bflies 6y ago

20 compared to the typical 80mb electron footprint is 4x better.

OOPMan 6y ago

It is huge. After doing web dev for years I wrote a desktop application with Qt. It's not massively complex (but a lot more complex than a hello world) but when it's running the memory usage is very low even compared to 20mb

jcelerier 6y ago

One thing is, as someone who develops cross-platform software, you really want font rendering & unicode support to be exactly the same across platforms, so that users don't have a save file that looks one way when opened on a Mac and another way when opened on a Windows. This means that you can't use the OS provided facilities (as they all have different metrics) and have to bundle good font rendering engines (if you care about non-us-ascii people) - that means already ~7-8 megabytes at the bare minimum for that.