Hacker News
3 years ago by karteum

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 )

3 years ago by afavour

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.

3 years ago by setr

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

3 years ago by andylynch

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 ][ ties for first place with an iPad Pro.

3 years ago by tshaddox

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.

3 years ago by abraxas

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?

3 years ago by cwyers

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.

3 years ago by EvilEy3

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?

3 years ago by akhilcacharya

Easier to write? Iā€™m curious are there any sample apps like this that I can read?

3 years ago by AZ-X

The earth didnā€™t betray you. It shows facts every day. The reflection in news is upon humanā€™s mind.

3 years ago by xvilka

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

3 years ago by undefined
[deleted]
3 years ago by unknown2374

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.

3 years ago by zant

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? :)

3 years ago by higerordermap

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.

3 years ago by jart

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

3 years ago by kazinator

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.

3 years ago by jart

Very impressive. But it didn't have a metacircular evaluator! sectorlisp does.

3 years ago by pjmlp

And the compiled ones also included some form of records.

3 years ago by kitd

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.

3 years ago by caslon

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

3 years ago by jart

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.

3 years ago by gravypod

Off topic but what did you use for emulating and visualizing your bootsector (blinkenlights.com) in here [0]. Looks much more convenient then QEMU which is what I used last time when doing ring 0 stuff in x86.

[0] - https://www.youtube.com/watch?v=hvTHZ6E0Abo

3 years ago by jart

I used Blinkenlights to simulate x86 boot. I wrote it! https://justine.lol/blinkenlights/index.html

3 years ago by pqb

@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/

[1] Graphics for JVM - https://tonsky.me/blog/skija/

3 years ago by EvilEy3

Compose is alpha tech. Even more alpha than it is on Android.

Electron has been around what? 7 years?

3 years ago by lhorie

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

3 years ago by lhorie

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.

3 years ago by jiofih

A node OS X build is 13mb, 20mb on Linux.

3 years ago by lhorie

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.

3 years ago by danenania

Looks 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 about upgrade/auto-upgrade tooling? Code signing?

3 years ago by davej

Strongly agree. Hello World apps are great but it would be even better to see a Hello World tutorial that can actually be distributed to customers. You probably also need auto-update, native installers, code signing (notarization on Mac) and the ability to build native modules cross-platform.

This is a super-interesting project though.

3 years ago by capableweb

Sure, would be great if everything had everything we need at creation. But this is first a Show HN from a user here and secondly open source software, so I think you need to adjust your expectations a bit.

Agree with your final part, very exciting and gonna be interesting to see where nodegui goes, especially security wise.

3 years ago by davej

This is awesome. Props to the authors. My comment was not meant to knock on this project. I'm just pointing out that people should consider distribution if they want to use a tool like this. Putting a desktop app in front of customers is not yet as easy as it is on the web but I'm working on making it better [1].

[1] https://www.todesktop.com/cli

3 years ago by jiofih

Both the App Store and Microsoft Store deal with installs and updates, no need for custom wrappers. Not sure about Linux.

3 years ago by davej

End-users are still more familiar with a download link on a website for a exe/dmg installer on desktop.

You also need to need to redo your subscription/payments to support the stores and give a percentage of your revenue to Apple/Microsoft. On mobile you have no option but on desktop it's hard to justify giving up so much of your profit margin when there's a popular alternative.

BTW, Linux has the Snap Store.

3 years ago by hanniabu

I have a mac laptop and windows desktop and I never use the app stores.

3 years ago by m00x

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.

3 years ago by rudedogg

There was a lot of criticism, especially of the Web version, in https://news.ycombinator.com/item?id=26332944

3 years ago by heavyset_go

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

3 years ago by IshKebab

Not yet. Or rather, I would say you can use it for simple stuff, like Etcher then it is a reasonable choice. But you wouldn't want to use it for something like Slack yet. Some basic stuff like ctrl-Z in text fields does not work yet. Doing normal desktop things like menus and file dialogs will be a pain.

That said, I am writing a Git desktop client in Flutter and I like it. But I don't expect to finish it for many years so hopefully by then they'll have ironed everything out.

3 years ago by jart

I'm seeing a lot of Qt vs. Chromium in this thread. Here's your mindblown.gif of the day: Chromium is based off Webkit which is based off KDE which is based off Qt. https://en.wikipedia.org/wiki/KHTML

3 years ago by capableweb

Agree, there is a linage. But to say they are similar because of that is like saying Fortan and Ruby is similar because of the shared heritage. Still useful to compare them if you have to.

3 years ago by jart

Ruby isn't a fork of FORTRAN and Ruby isn't written in FORTRAN. The lineage from Qt to Chrome is both those things. It's more than heritage it's an origin story.

3 years ago by anthk

On GUI's, if Go had some GUI a la inferno (no, not the crap of node, the one from the Unix/C/Plan9 guys), it would be the best thing ever on interfaces.

3 years ago by ssss11

Just thought it was worth mentioning that nodegui is a node & qt runtime. There are framework components for not just Svelte, but React and Vue as well... just search on github if you prefer a different framework.

3 years ago by LinguaBrowse

Maintainer here ā€“ Happy to answer any questions!

3 years ago by norswap

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

3 years ago by akiselev

The NodeJS NAPI support binary modules written in any language that can build dynamic libraries against the C FFI. There's still a little overhead marshaling between Javascript and the guest language but it's small compared to the overhead of HTTP or WASM.

3 years ago by pfraze

Itā€™s looking good! One really common usecase Id suggest emphasizing (it looks supported) is the systray UI. Iā€™ve had a lot of cases where my program is mostly just a background nodejs service and the simple task of adding a dock UI required electron. A great thing to have solved!

3 years ago by hawthornio

Qt supports this! so you should be covered.

3 years ago by mrwoggle

I know QT is dual licensed for application development. How's the licensing here?

3 years ago by LinguaBrowse

Some clarification on that from the maker of the parent project, NodeGUI, here: https://twitter.com/a7ulr/status/1225498258233053184?s=21

Atul is licensing NodeGUI as MIT, so Iā€™m licensing Svelte NodeGUI as MIT accordingly.

3 years ago by flipcoder

From Qt's page https://www.qt.io/licensing/open-source-lgpl-obligations:

"In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is ā€œwork that uses the libraryā€ ā€“ typically achieved via dynamic linking of the library."

3 years ago by empyrical

Also, Chromium's Blink renderer has a lot of LGPLv2 source files that date back to the KDE KHTML days[1] and as you can see by the numerous proprietary applications that use Electron and Chromium Embedded Framework, that this doesn't hinder companies from using LGPL libraries as long as they abide by the license.

However, one thing to note: the OSS version of Qt uses the LGPLv3 license, which has additional restrictions (like the "Anti-Tivoization" clause) which make it incompatible with the iOS AppStore thus forcing you to use the commercial version of Qt in those situations. Not sure about the Mac and Windows 10 app stores, I am curious if anyone knows/has experience with LGPLv3 and those stores?

[1] https://github.com/chromium/chromium/search?q=%22kde.org%22

3 years ago by himujjal

I might go a little offtopic here. Any plans to integrate https://github.com/c-smile/quickjspp. That way you can target mobile platforms too. QT supports mobiles well

As for desktop only this is great. Great work. Many people are commenting on NodeGUI only. They have forgotten to mention how Svelte also contribytes to saving memory footprint and cpu cycles over other frameworks with a much easier way to write apps. Add a small learning curve to that.

3 years ago by Gys

> core set of platform agnostic native widgets

This is confusing for me. I think such a framework is either 'platform agnostic' OR 'native'. Maybe the API is platform agnostic and the rendering is done natively?

3 years ago by LinguaBrowse

Thatā€™s the case, yes ā€“ the UI runtime is Qt5 (which is rendered using low-level graphics APIs, so we class it as ā€œnativeā€ ā€“ mostly in contrast to WebView-based UIs), and itā€™s the same API regardless of which platform youā€™re running on.

3 years ago by ComputerGuru

I saw Qt and immediately understood what you were trying to say, but for the record: Thatā€™s not what native means. Native means ā€œuses the platform widgets and drawing/theming apiā€ and Qt is not native: it actually draws its own widgets (for the most part with certain exceptions on certain platforms) that are drawn to mimic the system UI with subtle differences. If the system UI implementation suddenly changes (say with an OS release) the Qt UI wouldnā€™t magically change with it.

An example of native UI is libui or WxWidgets.

3 years ago by avel

Is Qt considered native when you use KDE and not native when you use GNOME? Is Qt 3 considered not native when you use a KDE release that uses Qt 4 under the hood?

3 years ago by mrwoggle

Real question, what do some people mean with native C++? Or stuff like react native? Seems like it just equals more performance / peels away an abstract layer.

3 years ago by jart

Yeah but Qt does it well enough that I consider it de facto native. It's not like Swing Java where they totally went their own way with the widgets.

3 years ago by dschuessler

Not necessarily. This expression probably refers to Qt's capability to use the subset of native widgets that are functionally equivalent across platforms. This blog post has some images of this feature in action: https://www.qt.io/blog/desktop-styling-with-qt-quick-control...

3 years ago by porphyra

Looks very slick, but I am extremely stressed out by the inconsistent font sizes and button spacing across platforms in the example calculator app.

3 years ago by benrbray

I think this is part of why many people stick with Electron instead of Qt in the first place. Nevertheless, a really cool idea. I will jump ship from Electron as soon as the first viable alternative emerges. However I haven't yet seen a wysiwyg text editing framework that can hold a candle to something like ProseMirror, so for my use case that might be a while.

3 years ago by sonthonax

I'm always a bit surprised there was the space for Electron to exist in the first place. Since most operating systems have widget toolkits that have browsers effectively embedded into them.

What I would have liked to have seen instead of Electron would have been a shim API that abstracted OSX/iOS/WinForms/QT webviews, and for those webviews to have a working API that would allow DOM manipulation, and allowed native sub-views to be inserted as block elements.

3 years ago by Stratoscope

One reason is that for a very long time, if you created a native WebView on Windows, you would get an IE7-compatible browser, even if the user had installed a much newer version of IE. There were a couple of tricks you could use to get the user's actual browser version, which I described some time ago here:

http://forums.apricitysoftware.com/t/why-is-markdownpad-spaw...

In any case you were still dependent on IE10/11 at the best, and certainly nothing as modern as the old Edge, much less the Chromium-based Edge. And on older Windows versions it completely depended on whether the user had upgraded IE.

You could write HTML/CSS/JS that was portable between IE10/11 and other native browsers, just as we all did in actual websites. I did this for Mac/Windows in the past and it worked, but it was fairly compelling for web developers to have a single browser version to target instead of the various incompatible native web views.

The situation is a bit different now, where you can get an Chromium Edge view on Windows 10 and a Safari view on Mac, but what do you get on Linux? I don't know.

3 years ago by techdragon

That was sort of half doable with the horribly insecure Microsoft Hypertext Applications https://en.wikipedia.org/wiki/HTML_Application

You had to use JavaScript or VBScript but all the safety rails are off, this is pre-sand boxing, what do you mean websites might be malicious why would someone make one like that... you could do crazy things, and fully leverage windows APIs directly without much effort via VBScript, I once used the winforms(?) APIs to introspect field labels and names to automate the driving of multiple desktop apps from a crazy jquery and VBScript monstrosity. Made me twice as efficient at that job though so it was awesome.

You could control child iframes and pop up windows (remember these?) and VBScript let you shoehorn quite a bit of native UI type stuff whenever it was going to be easier than building something with simple forms, JavaScript, tables and frames. If you got really fancy you would Base64 some absurd binary into your app and unpack it on the fly with VBScript then call it from a temp directory in order to drive things like interacting with network services that didnā€™t have any sort of thing you could work with via HTML JavaScript and XMlHTTRequest (this was the very dawn of Ajax)

3 years ago by k__

I know a bunch of devs who simply shipped a Qt webview app when a native client was requested.

Daily Digest

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.