karteum 45 days ago [-]
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 )

afavour 45 days 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 45 days 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 45 days 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/. The Apple ][ ties for first place with an iPad Pro.

fao_ 45 days 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

underwater 45 days 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 45 days 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.

jart 45 days ago [-]
One thing that's illuminating is go to chrome://settings/content/all and sort by "data stored" to see how much local storage websites use. Stuff like vice.com needing 100mb of space on your hard drive for who knows what purpose.
jrochkind1 45 days ago [-]
Wow, thanks for the tip, never occured to me to do that.

There were websites I had never heard of using hundreds of megs. Also acehardware.com for some reason using hundreds of megs.

Also Github "community" forums and Travis "community" forums (I don't use travis anyore) using hundreds of megs. Are some websites just caching the entirety of every page you look at in local storage? How rude.

esperent 45 days ago [-]
> The Apple ][ ties for first place with an iPad Pro.

* When used with an Apple Pencil (30ms). When used with touch it drops to 70ms.

Also, it's worth noting that there's a very limited list of devices tested there and it heavily skews Apple.

jart 45 days ago [-]
Are you referring to this submission? https://news.ycombinator.com/item?id=23369999 Outstanding article. Total shame it only got 100 upvotes.
moosingin3space 45 days ago [-]
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.
makapuf 45 days ago [-]
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 and render arial and images or even monospaced fonts which are perfectly readable (I do that all day long on my code editor)
skipnup 45 days ago [-]
And then comes unicode and all the simplicity is gone again as the rest of the world uses more than 26 letters.
moosingin3space 39 days ago [-]
> until we embrace screens and render arial and images or even monospaced fonts that are perfectly readable

This is part of what I meant when I said "drastically restrict the problem space".

tshaddox 45 days 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_ 45 days ago [-]
The question isn't about throughtput but latency.
abraxas 45 days 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 45 days 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 45 days 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 45 days ago [-]
Easier to write? I’m curious are there any sample apps like this that I can read?
abraxas 45 days ago [-]
Sure. Check out the tutorial that has remained pretty much the same since I used it to learn FLTK + GL 23 years ago:


You pretty much draw the UI in fluid and fill out the callbacks. Yeah it's C++ but it's not particularly esoteric C++.

EvilEy3 45 days ago [-]
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?
pkphilip 44 days ago [-]
Yes, in 1998 there were full fledged IDEs which allowed for GUI development. Delphi, Visual C++, Visual Basic Powerbuilder, NeXT Objects,.... I would actually say that it was easier to develop apps in 1998 than it is now.
AZ-X 44 days ago [-]
The earth didn’t betray you. It shows facts every day. The reflection in news is upon human’s mind.
xvilka 45 days 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.

45 days ago [-]
unknown2374 45 days 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.

zant 45 days 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? :)

davidkunz 44 days ago [-]
Hi, I use Neovim with basically the same features as VSCode. I made a video series on how to configure it: https://youtu.be/CcgO_CV3iDo?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...
sgoody 39 days ago [-]
Hey, thanks for this. I'm a long-time Vim user, but I've never gotten around to adding in some slick IDE-like featuers (I've made half an attempt to get code completions working, but often lose interest if it doesn't work first time).

The intro looks great I will definitely check this out.

zant 44 days ago [-]
Wow looks super promising. Definitely worths a try.

Thanks for sharing!

smichel17 45 days 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.

jrochkind1 45 days ago [-]
That's what you do? Why?
bobmaxup 45 days ago [-]
How is writing something in vim faster? You can have the same bindings in many IDEs.
smichel17 45 days ago [-]
This thread has been specifically about responsiveness. Latency, not throughput. Also, the bit about no plugins was a little white lie. I really meant "no plugins for IDE-like functionality (language server, etc)". While many IDEs offer basic vim keybindings, I don't know any that would let me import my .vimrc wholesale and work exactly the same. I'd love an IDE that embeds neovim as the text editor.

Anyway, if you don't care about all that, you can get a similar effect by turning off intellisense (or equivalent) in your IDE while you write, then turn it back on at the end to get what you just wrote to compile. I do this sometimes in Android Studio.

IggleSniggle 45 days ago [-]
There is an IDE that embeds neovim as a text editor, kind of.

The VSCode Neovim extension makes neovim run as its backend, while giving you all the IntelliSense etc of VSCode. I can’t tell exactly you how it affects responsiveness as I only toy around with it, but it does feel noticeably better in some aspects...yet maybe occasionally glitchy?

Anyway it’s pretty interesting, especially if you’re already using neovim anyway.

linknoid 45 days ago [-]
The VsVim plugin for Visual Studio makes an attempt at supporting everything in the .vimrc (or _vimrc) file. Compatibility is not 100%, so certain things just fail, but it's a lot more than just basic key bindings.
eska 45 days 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.
agrippanux 45 days ago [-]
The vim plugin CoC uses the same engine for code completion as Code. It’s pretty trivial to set up.

For searching, use SilverSearcher / fzf

higerordermap 45 days 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.

naikrovek 45 days 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 45 days ago [-]
Before the second character is typed...
spacechild1 45 days 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.
throwanem 45 days ago [-]
Emacs does those things too, these days. It's still snappier than anything else I've tried recently.
GuB-42 45 days 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 45 days ago [-]
cough vim cough

I'm just kidding. Don't want to start a fight here.

throwanem 45 days 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.

45 days ago [-]
anthk 45 days ago [-]
>all sorts of things we never had a couple of decades ago

We had them.

badsectoracula 45 days 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/

[1] http://runtimeterror.com/tech/fowl/

[2] https://www.lazarus-ide.org/

jbluepolarbear 45 days 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.
badsectoracula 45 days ago [-]
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 provides is more than enough - VA does provide a bit more, but for me wasn't worth the slowdown.

jbluepolarbear 45 days ago [-]
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.

pjmlp 45 days ago [-]
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.

jbluepolarbear 45 days ago [-]
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.
pjmlp 45 days ago [-]
Visual Studio has been pretty modern, specially when compared against traditional UNIX offerings.

Anyone measuring typing speed as productivity measurement is doing it wrong.

Writing code is around 50% of daily activities.

Visual Assist doesn't do nothing when I have to write documentation, architecture diagrams, meetings to decide roadmap items, demos at customer review meetings,....

On top of that, none of the OS SDK replacements offer better UI or debugging capabilities across the platform tooling, they just play "catch-me if you can" with what I can get on day 0 of each OS SDK release.

JetBrains wants to be Borland, yet they don't sell any of the platforms, or languages.

I guess Kotlin and Android marriage will help them, as they are trying to make it their "Delphi", lets see how it plays out if Fuchsia ever happens.


> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA.

jbluepolarbear 45 days ago [-]
I don’t think JetBrains is going anywhere soon; been using their products for almost a decade.

I don’t measure my productivity by how much code I can write, that was just an example.

The way I work designing systems and architecture, I have already made the solution in my head and basically the “coding” part is just trying to get that info out as fast as possible. I have a similar thing to eidetic memory, but I am so ADHD what gets remembered can be random or missing stuff. I remember all code I’ve ever written, seen, or thought about and tools that allow me to basically brain dump this info greatly improve my production, leadership, confidence, and architectural designs.

andi999 45 days ago [-]
It is about the feedback-response loop. If I type a character and it doesn't appear (what feels) instantaneous I start to feel physically sick. I have build up some tolerance but I think when I tried Julia with Atom three years ago, I gave up after 15 minutes (atom too much latency if I remember correctly and Julia as well)
Aeolun 45 days ago [-]
> It's doing autocomplete suggestions, linting code as I type

Even so, shouldn’t it be able to do that in 16ms?

dsr_ 45 days 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 45 days 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.

pjmlp 45 days ago [-]
I bet some of those UI coded in Delphi versions targeting Windows 95 would be way less than 20MB.
qw 45 days ago [-]
Many years ago I wrote a simple Delphi application that used the standard rich text editor. The size was less than 150kB
canadianfella 44 days ago [-]
It outrages you somewhat?
jart 45 days 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 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.
kazinator 45 days ago [-]
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.
jart 45 days ago [-]
Very impressive. But it didn't have a metacircular evaluator! sectorlisp does.
kazinator 45 days ago [-]
I see there is a metacircular evaluator in the repository (lisp.lisp), but I don't see where that is pulled into the image.

In the BASIC heyday, there existed compilers for BASIC (some of them written in BASIC). These didn't ship in the ROM images either, they were third-party apps.

pjmlp 45 days ago [-]
And the compiled ones also included some form of records.
kitd 45 days 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 45 days 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?


jart 45 days 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.
gravypod 45 days ago [-]
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

jart 45 days ago [-]
I used Blinkenlights to simulate x86 boot. I wrote it! https://justine.lol/blinkenlights/index.html
anthk 45 days ago [-]
> built a LISP interpreter too,

Some friend of mine like it :D.

But I'd like that more if it was Scheme.

pqb 45 days 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/

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

EvilEy3 45 days ago [-]
Compose is alpha tech. Even more alpha than it is on Android.

Electron has been around what? 7 years?

lhorie 45 days 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-execut...

lhorie 45 days 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 45 days ago [-]
A node OS X build is 13mb, 20mb on Linux.
lhorie 45 days 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.
klingon79 45 days 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 45 days 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.
conradev 45 days 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.

45 days ago [-]
pier25 45 days 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.

mhh__ 45 days 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.
jcelerier 44 days 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 45 days ago [-]
It's definitely not. It's just a different toolkit that the one you already have in memory, so it can't "cheat".
fouric 45 days 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 45 days 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.

fouric 45 days 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 44 days 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.

fouric 43 days ago [-]
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 majority of users of such programs.

jcelerier 43 days ago [-]
> you can fit 100 20MB apps into 2GB.

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.

texasbigdata 45 days 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?
badsectoracula 45 days ago [-]
> 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 resources, so even if RAM is cheap and plentiful it doesn't automatically mean that every application should feel entitled to it.

(and also even during the DOS days we had TSRs which had to be RAM conscious too)

Klonoar 45 days ago [-]
>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 redlining it.

badsectoracula 45 days ago [-]
> Yes, you shouldn't be a bad neighbor, but the OS will generally move things around to accommodate you as necessary.

I'm not sure what you mean with that. The OS will not "move things around" to the point where the resource abuse wont be noticeable, all it can do is swap stuff to the disk, perhaps compress some RAM and maybe unload any cold code (though code doesn't that that much RAM) and all that take time, slowing down the system.

> RAM is an afterthought for most of these applications for a reason.

Yes and that reason is disinterest from the application developers for RAM usage.

> This attitude is like buying a sports car and never redlining it.

Sports cars have nothing to do with this, i do not see the relevance.

michaelmrose 45 days ago [-]
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.

fouric 45 days ago [-]
> 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 byte of RAM for caching is tiny compared to the value of you using it for an application you care about.

The above also has nothing to do with wasting RAM. If you've spent any significant amount of time developing programs for actual users (read: not programmers), you'll know that development is a complex, multi-variable tradeoff - and one of the biggest trade-offs is RAM usage for performance, so if you solely optimize for minimal RAM usage, you'll always (except for the most trivial of programs written specifically as a counterexample to this claim) end up sacrificing performance.

The wastefulness of 1 GB of RAM usage varies wildly depending on whether you're running a video editing program on a large file (hey, that's not that bad!) or a simple textual chat application. 20 MB for a graphical tool is an acceptable tradeoff in the vast majority of use-cases.

michaelmrose 44 days ago [-]
> Let me repeat it again

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.

oarsinsync 45 days ago [-]
> 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.

Klonoar 44 days ago [-]
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.

oarsinsync 44 days ago [-]
> Most users have enough RAM unless they're running on some absurdly low 4GB< device, which is just nowhere near as common these days.

Citation needed. My experience with people outside the tech bubble is that they don’t know what RAM is, and will not consider it when purchasing a computer. Most of these people now also live primarily on a phone or tablet too, because their computers are too slow.

jug 45 days ago [-]
In case this discussion is still about a 20 MB RAM NodeGUI application, I don't think this is a comparable situation because DOS was really not about developing cross-platform applications with a Turing complete styling language. It was about building text mode tools that ran on x86 and nothing else. I swear even the "bloated" Windows 10 will have absolutely no trouble running a Win32 Console application at < 1 MB RAM consumption but that's not what this is about.
badsectoracula 44 days ago [-]
My reference of DOS was tongue-in-cheek and i made it because it only allowed a single program to run (ignoring TSRs) at any time so programs using all the memory wasn't much of a problem.
reaperducer 45 days ago [-]
HN: "RAM is cheap and plentiful."

Also HN: "The MacBook Pro is worthless if I can't get it with at least 64GB of RAM."

square_usual 45 days ago [-]
Those don't seem contradictory to me. RAM is cheap and plentiful, and getting 64GB of RAM is easy, but Apple just doesn't want to sell that config right now. You can still get a 64GB config on another system.
jbverschoor 45 days ago [-]
Everyday users don’t get Ram upgrades. Many programmers are elitist snobs without any consideration for the end user
AZ-X 45 days ago [-]
Go back to Year 2000, Jobs may laugh and agree with disagree. Now Year 2021, HN: “Noodle JS is centenary and memories are around it”
ric2b 45 days ago [-]
> If you don't use it, its value is almost zero

But the value is also zero if you're using extra for no benefit. Actually it's negative, because it prevents other programs from using it.

You should try to use all your RAM, yes, _but in ways that are actually useful_. The OS can always use leftover RAM for caching frequently used files if you don't have a better use for it.

agumonkey 45 days 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 :)
OOPMan 45 days 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

bflies 45 days ago [-]
20 compared to the typical 80mb electron footprint is 4x better.
mrwoggle 45 days ago [-]
I just made hello world window in qt. It's 28 kB. edit: typo
jart 45 days 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.

    [email protected]:~/scratch/qtproject$ qmake -project
    [email protected]:~/scratch/qtproject$ make
    [email protected]:~/scratch/qtproject$ ldd ./qtproject | grep -Po '(?<==> )[^ ]*' | xargs ls -alH | awk '{x += $5} END {print x / (1024 * 1024.)}'
That's bigger than I expected to be honest.
jcelerier 45 days 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 45 days ago [-]
Id say its fair game if building hello world links those gstreamer and openssl.
jcelerier 45 days 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 45 days ago [-]
Because application can't run without those libraries. It's like comparing Java application without taking JVM into account.
jcelerier 45 days ago [-]
> It's like comparing Java application without taking JVM into account.

no, it's not. The "equivalent" of the JVM would be the libQt5{Core,Gui,Widgets...}.so ; but here we are talking about the operating-system-provided libraries, so it is like comparing with a Java application, with the JVM, and also for instance all the MS Windows system libraries, or all the macOS frameworks like CoreFoundation, etc etc.

makapuf 44 days ago [-]
OK, so in this context the app is X MB. If all distros link those libs with libre cote and ui, for all intents and purposes, it takes X MB. If some dont, then lets discuss it (but if you can link to gstreamer and openssl to build a hello world, the issue is not entirely on the distro shoulders)
fabiospampinato 45 days ago [-]
The thing is nobody actually uses hello world programs, by the time you build a real application the difference in RAM usage between that and a good Electron app for example blurs significantly.
tonyarkles 45 days ago [-]
Looking at a few things on my machine right now:

- Emacs (with 251 open files and IRC running): 100MB

- Activity Monitor: 98MB

- Word: 227MB

- Spotify: 465MB

- Slack: 526MB

- Thunderbird (not Electron, but a similar weird browser hybrid thing): 663MB

- Teams (which appears to be Electron): 747MB

I'm not seeing too much of a blur here. The worst chat app (Teams) is using ~7x the RAM of my primary code editor that also is doing chat :).

AZ-X 45 days ago [-]
Get-Process WINWORD

PM(K) ----- 51600

fabiospampinato 45 days ago [-]
What some people actually build with Electron doesn't really say much about what people _can_ build with Electron.

You can't just compare Emacs with Spotify here, I can't even scroll a list in Spotify without seeing it disappearing on me momentarily, that says more about Spotify's engineers or project managers than it says about Electron.

Teams and Slack kind of address the same problem and I'm seeing wildly varying numbers reported by you, without knowing anything about how you are using those apps those numbers are meaningless in my opinion, and if you think they are meaningful then clearly you can achieve different results despite addressing the same use case with the same technology stack.

Also there's "chat" and "chat", there's a reason ~nobody uses IRC anymore compared to Slack, they are not the same thing, and it's not just that Slack is easier to use.

jcelerier 45 days ago [-]
> What some people actually build with Electron doesn't really say much about what people _can_ build with Electron.

no, it does. anyone can build incredible apps on any tech, given infinite budget and time. What matters is how the average app behaves, and for electron it is much worse than the average Qt app for instance.

fabiospampinato 45 days ago [-]
That argument makes no sense to me, do you think you'd change your mind on Electron if access to it were restricted only to very intelligent and motivated people who made very good apps then?

The average Qt app would probably be close to the average Electron app if Qt attracted the same kinds of people, i.e. Electron is basically just easier to use and/or the developers picking it think they are getting more value out of it.

jcelerier 45 days ago [-]
> That argument makes no sense to me, do you think you'd change your mind on Electron if access to it were restricted only to very intelligent and motivated people who made very good apps then?

but that's not the world we live in - everything has to be considered in that context and not in the abstract, in order to make any sense. Consider musical instruments - you can technically make great music with literally anything. But if, say, 80% of what people are doing with a given instrument ends up sucking, the problem lies more in the instrument than in the people, even if a very talented (and dedicated) 20% is able to make symphonies with it.

tonyarkles 44 days ago [-]
I’ll flip this around. Can you think of any Electron apps that aren’t hugely bloated as examples of Electron-done-right?
fabiospampinato 44 days ago [-]
I think vscode is pretty good.
tonyarkles 44 days ago [-]
Just opened it up and it's... ok. Have 4 files open (all from the same project):

- VSCode itself 453MB

- cpptools (language server under the hood) 573MB

In the mean-time, I've been doing most of my work all day in Emacs and it has bloated up to 126MB :).

Edit: I will admit that the cpptools stuff is very nice. I do most of my C++ work in Emacs, but when I'm dealing with weird template type stuff I'll switch over to VSCode for the nice affordances it offers.

Edit 2: Just tried using VS Code to debug something that I can't quite grok.

    IntelliSense process crash detected.
    IntelliSense process crash detected.
    IntelliSense process crash detected.
Ahhh well, I can't really blame it on this one :D
fabiospampinato 44 days ago [-]
I can't speak about the LSP, other than that that sounds about right to me, maybe you have a lot of free ram or some extensions installed? I would expect the memory usage to be lower than that otherwise.

You can't really compare Emacs with VSCode here, among other things you can basically get vscode to run in the browser without many problems etc. It's like saying that one can edit text with nano which is 150kb, sure but that's only part of what vscode provides you.

tonyarkles 44 days ago [-]
Heh the embarrassing thing for Teams in this case is that I’m signed into one team that doesn’t really use it for anything but conference calls, while I’m also signed into 8 or 9 heavily used Slack groups.
inetknght 45 days ago [-]
I disagree. I remember using lots of GUI apps within a 96MB budget 25 years ago -- even browsers.

Electron does not provide that much more desired features than apps from 25 years ago.

MaxBarraclough 45 days ago [-]
> Electron does not provide that much more desired features than apps from 25 years ago.

That's true, but advanced GUI features aren't Electron's selling point. It's used because it offers easy portability and the ability to leverage web-dev skills.

fouric 45 days ago [-]
What does Electron offer in terms of portability that SDL2 doesn't have?
MaxBarraclough 45 days ago [-]
SDL is intended for gaming and similar applications, it isn't intended for general purpose GUI development. That's what toolkits like Qt and GTK are for. These toolkits do compete with Electron.

With the disclaimer that I don't know a lot about this: Electron has solid support for both desktop and mobile targets. I don't think Qt's mobile support is as good, but I might be mistaken.

alvarlagerlof 45 days ago [-]
The larger point is ease of use
fouric 45 days ago [-]
Fine, "What does Electron offer in terms of easy portability that SDL2 doesn't have?"
opheliate 45 days ago [-]
Accessibility would be my immediate thought, although I'm not massively experienced in terms of GUI programming, so I could be off the mark here.

With something like SDL2, I would have to interface with each operating system's accessibility API directly, in such a way that's not easily portable, unless I bring in a separate library. Even something like GTK has this problem on platforms other than Linux. With Electron, I know that my program will be accessible wherever Chromium's rendering of HTML is accessible, which is a lot more places than anything I'm going to be able to bodge together.

fabiospampinato 45 days ago [-]
You can make a very decent Electron app with roughly (roughly = ~2x or less) that amount of RAM too if written well, for that you get pretty much a codebase that you can use everywhere, which on it's own is _massive_.
ficklepickle 45 days ago [-]
I've noticed Signal Desktop only uses 100mb. That is quite good for an electron app. A simple server-side node process will use at minimum ~20mb, which obviously does not include a browser.

It's open source, I've been meaning to poke around and see what they are doing differently.

tuxychandru 45 days ago [-]
Signal desktop runs as multiple processes. Did you add up all their memory consumption? On my Debian laptop, Signal processes consume about 700 MB of RSS in total, immediately after starting.
fabiospampinato 45 days ago [-]
There's no secret really, just don't import junk dependencies like most people do and spend some time inspecting your memory usage every now and then, with very little effort you'll probably cut down on your memory usage significantly by doing that. With a lot more effort often you can probably even make something faster than uses less memory than a supposedly native app (if they spent less time than you optimizing it).
korijn 45 days ago [-]
NodeGui (which is used here) is also running on Qt.
danenania 45 days ago [-]
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?

davej 45 days ago [-]
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.

capableweb 45 days ago [-]
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.

davej 45 days ago [-]
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

jiofih 45 days ago [-]
Both the App Store and Microsoft Store deal with installs and updates, no need for custom wrappers. Not sure about Linux.
davej 45 days ago [-]
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.

jiofih 45 days ago [-]
Hmm I really don’t think so. You might be thinking of tech people, not the general public.
heavyset_go 44 days ago [-]
All of the non-technical people I know are capable of installing software on desktop computers without using app stores.
hanniabu 45 days ago [-]
I have a mac laptop and windows desktop and I never use the app stores.
IggleSniggle 45 days ago [-]
I have used each of them exactly once. In both cases, it was to purchase an OS upgrade.
jiofih 45 days ago [-]
You’re the HN audience.
m00x 45 days ago [-]
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.
rudedogg 45 days ago [-]
There was a lot of criticism, especially of the Web version, in https://news.ycombinator.com/item?id=26332944
heavyset_go 44 days ago [-]
> 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.

m00x 42 days ago [-]
IshKebab 45 days ago [-]
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.

jart 45 days ago [-]
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
capableweb 45 days ago [-]
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.
jart 45 days ago [-]
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.
anthk 45 days ago [-]
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.
ssss11 45 days ago [-]
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.
LinguaBrowse 45 days ago [-]
Maintainer here – Happy to answer any questions!
norswap 45 days ago [-]
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).
akiselev 45 days ago [-]
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.
pfraze 45 days ago [-]
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!
hawthornio 45 days ago [-]
Qt supports this! so you should be covered.
mrwoggle 45 days ago [-]
I know QT is dual licensed for application development. How's the licensing here?
LinguaBrowse 45 days ago [-]
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.

flipcoder 45 days ago [-]
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."

empyrical 45 days ago [-]
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

varajelle 45 days ago [-]
The "Anti-Tivoization" clause is only applicable for hardware that are distributed with GPL/LGPL software included. It does not concern the app store.

The use of LGPLv2 on the iOS AppStore seems to be controversial. But nothing changes with LGPLv3 in that respect as far as I know.

heavyset_go 44 days ago [-]
> which make it incompatible with the iOS AppStore thus forcing you to use the commercial version of Qt in those situations.

Not necessarily. If you're able to distribute versions of your app to iOS users so that they can link it against their own Qt libraries, you'd be in compliance with the LGPL.

I've seen companies that distribute via the App Store, but also provide object files with instructions to link them against user supplied Qt libraries and to get them on iPhones/iPads.

himujjal 45 days ago [-]
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.

glutamate 45 days ago [-]
There are other projects like this - But what would really set it apart would be mobile (iOS and Android) support. Can we do anything to support that happening?
LinguaBrowse 45 days ago [-]
Qt does have an implementation that targets mobile. I don’t know how the licensing works, but in theory there should be a way to rely on Qt for mobile to extend support to iOS and Android. Way out of my own expertise, though!
heavyset_go 45 days ago [-]
Qt for Android and Qt for iOS can be used under the LGPL[1]. The issue for iOS, though, is that Apple's App Store violates the terms of the LGPL. To comply with the LGPL, you must make available to iOS users versions of your app that can be linked against user-provided Qt libraries.

If you use the Qt commercial license for either, then you don't need to worry about your app conforming to the LGPL.

[1] https://wiki.qt.io/Licensing-talk-about-mobile-platforms

esperent 44 days ago [-]
I'm really happy to have found this at I'm in the early stages of building an app. My plan is to release a web only version first and then desktop clients later depending on demand.

So, my question is, how much work is there to convert a web app built with Svelte to a Svelte NodeGUI app? Will most things just work, or should I expect to have to rebuild a lot of functionality?

Second, my app will make use of WebGL (or possibly WebGPU in the future) and have done wasm components. Do these work with NodeGUI?

esperent 44 days ago [-]
I'm really happy to have found this at I'm in the early stages of building an app. My plan is to release a web only version first and then desktop clients later depending on demand.

So, my question is, how much work is there to convert a web app built with Svelte to a Svelte NodeGUI app? Will most things just work, or should I expect to have to rebuild a lot of functionality?

jjcm 45 days ago [-]
Does this use the native OS’s current default browser renderer? If so is windows using edge or chromium under the hood?
dgreensp 45 days ago [-]
There's no browser component. Qt (https://www.qt.io/) is the granddaddy of native cross-platform GUI.
bmn__ 45 days ago [-]
1. Is there any way to load a UI file made with designer-qt5, perhaps with example code?

2. Thank you for backing up your claims about a native implementation by actually providing one, unlike your competitors Tauri and Wx who constantly lie about the topic.

nguyenkien 45 days ago [-]
Off topic, any plan to make ot work with react native?
LinguaBrowse 45 days ago [-]
No plans, but what kind of integration would you have in mind?

I actually happen to be struggling to get React Native in the NativeScript runtime right now – running it in the Node.js runtime would be if anything even more challenging. But there are other ways to make the two work together.

bsaul 45 days ago [-]
I’ve always been wondering what nativescript really was about, and how it compared to react native and other platforms (and also, why do i barely read about it on HN or elsewhere, as it seems to offer a cross-platform dev environment).

The project’s webpage has way too many tech listed to be of any help, and the video mentions a framework, an IDE, a debugging environment...

Do you have a good link where i could get a better understanding of the tech, and how it’s used in real world project ?

boromi 45 days ago [-]
Any Win 10 fluent examples? Perhaps WinUI integation?
LinguaBrowse 45 days ago [-]
The parent project, NodeGUI, has some Windows screenshots and examples – I’m not familiar enough with Fluent or WinUI, but basically the UI runtime is Qt5, so integrating it into genuine Windows apps is out of scope (but may well be possible with the right expertise). I assume it would involve some kind of Qt-hosting view. I’m unsure whether Qt5 can host Windows UI components.

Edit: NodeGUI here: https://github.com/nodegui/nodegui

ComputerGuru 45 days ago [-]
WinUI 3 improves the ability to embed fluent UI “xaml islands” in Win32 apps (like Qt processes) but it’s extremely convoluted and requires a lot of boilerplate (that I believe Qt could theoretically abstract over being at a high-enough level).
jcelerier 45 days ago [-]
> I’m unsure whether Qt5 can host Windows UI components.

yep, basically you have to do :

    auto window = QWindow::fromWinId(reinterpret_cast<WId>(/* HWND, NSView, X11 buffer, Wayland surface... /*));
    auto widget = QWidget::createWindowContainer(window);
and then you can use the widget like any other Qt widget, put it in a layout, etc... (of course caveats may apply when you start doing transparency or other fun things).
Gys 45 days ago [-]
> 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?

LinguaBrowse 45 days ago [-]
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.
ComputerGuru 45 days ago [-]
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.

avel 45 days ago [-]
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?
quarantine 45 days ago [-]
I would say so. Just like GTK is native on GNOME but definitely not on Windows. "native" (to me) really just means whatever the system is designed for.
nine_k 45 days ago [-]
Then Windows 10 apparently lacks a native GUI toolkit, because it's certainly not "designed for" just one.

A similar thing happened to Android.

MaxBarraclough 45 days ago [-]
> Then Windows 10 apparently lacks a native GUI toolkit, because it's certainly not "designed for" just one.

Windows 10 has several native GUI toolkits. The same thing happened in MacOS, which transitioned from Carbon to Cocoa.

If the widgets are drawn by a toolkit that isn't bundled with the OS, it's a non-native GUI. Of course, this isn't always a bad move.

gigel82 45 days ago [-]
One could argue Win32 is still the de-facto GUI toolkit in Win10. Things like .NET Windows Forms and (non-WinUI3) UWP are actually rendered with Win32 common controls.
jart 45 days ago [-]
WIN32 isn't de facto it is the canonical API for Windows. It always has been, since like the 1980's.
ComputerGuru 45 days ago [-]
Indeed, but with some exceptions. .NET SWF shipped with extremely kludgy drawn clones of toolbars and menu bars instead of using the native ones (although the native ones were later exposed) and the result is that those particular controls on SWF apps did not age gracefully (DPI problems, system theme mismatch, scroll acceleration issues, etc). That’s the kind of thing Qt would also face with drawn components skinned to look like the real deal.
flipcoder 45 days ago [-]
Native usually means standard or specific to the particular system. I would say yes to those questions.
mrwoggle 45 days ago [-]
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.
heleninboodler 45 days ago [-]
Part of the point of "native" is that each platform gets its own consistent look and feel and behavior for its own UI widgets. Back when I worked at Adobe, we had our own internal cross-platform UI framework for Illustrator/Photoshop and they were consistent across the supported platforms, but they didn't look like "native" controls, and that can end up being a pretty big headache (e.g. when accessibility and keyboard navigation don't just automatically work the way the native controls do, that's your problem to fix or punt). They also just generally look "different" and a lot of people consider that a bad thing.
LinguaBrowse 45 days ago [-]
React Native does extend from platform UI components such as UIView, so that one at least is uncontroversially “native”.
jart 45 days ago [-]
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.
wruza 45 days ago [-]
Nativeness lies more in behavior than in looks. E.g. an input (an edit for old folks) has a very specific popup menu on every system, text selection works in a specific way (think what happens when you double/triple click, move with ctrl or lose or gain focus). Tab order and focusability is important as well. If they get that correctly, by e.g. using borderless system text areas or grabbing a menu from common control internals, it’s not a big deal if they draw some borders or animations by themselves. It’s just pixels in the end, sometimes better than native (which is just crap too often, like windows tables, lists, popdown controls).

But really, native look and feel only left on macOS. Windows lost its traditions around vista, linux never ever had one true way to do UI, and browsers almost exterminated everything else.

kuschku 45 days ago [-]
Swings Platform LaF was still much closer than current browsers ever get.
dschuessler 45 days ago [-]
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...
sonthonax 45 days ago [-]
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.

Stratoscope 45 days ago [-]
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:


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.

techdragon 45 days ago [-]
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)

k__ 45 days ago [-]
I know a bunch of devs who simply shipped a Qt webview app when a native client was requested.
c-smile 45 days ago [-]
Same demo in VanilaJS and Sciter.JS : https://github.com/c-smile/sciter-js-sdk (see screenshots there).

Binary is ~5MB, and that is HTML/CSS + QuickJS + NodeJS runtime.

Versus 50MB+ of NodeGUI that is Node.JS + QT.

And SvelteJS works in Sciter.JS out of the box too.

anilgulecha 45 days ago [-]
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.

esperent 44 days ago [-]
The license looks ok:


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.

anilgulecha 43 days ago [-]
That's just the sdk shim. The underlying engine looks to be closed. (My question was unrelated to commercial use - that's only one potential benefit of FOSS.)
porphyra 45 days ago [-]
Looks very slick, but I am extremely stressed out by the inconsistent font sizes and button spacing across platforms in the example calculator app.
benrbray 45 days ago [-]
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.
endisneigh 45 days ago [-]
Is there a way to have some small application that talks to the machine via a set of HTTP apis?

I envision something where you can just use your regular web app, have the user install the "Desktop Connector" which would be listening at say, port 8000 - then your web app can talk to the desktop via those APIs, instead of installing an Electron or related.

I must be missing/forgetting something crucial since that seems like the most straightforward solution imaginable.

ficklepickle 45 days ago [-]
Dell uses this exact technique on Windows to launch/interact with their driver installation tool from the web. That has decent UX because it comes pre-installed. But, generally, users aren't accustomed to this pattern and any user education requirement is often a non starter in many market segments.

It also has security implications if you are exposing OS functionality to websites. I remember Dell having a bad one a couple years ago.

There is also an antivirus browser extension that works in a similar way. It installs a native C++ executable that the extension interacts with. That has a huge security footprint. IIRC they rolled their own parser (HTML?, JSON?) and it went predictably bad.

There are lots of implications to consider. I'd like to see progressive web apps fill this niche on the desktop. They have various mechanisms for persistence of data and WASM will increase the practical use cases. Hopefully the APIs available to PWAs in the future will allow all sorts of new use cases.

julienb_sea 45 days ago [-]
I mean you are basically just describing a standard local development setup, so in a lot of ways this is trivial. The trouble would be trying to package that up in user-friendly manner. It's definitely more work than it's worth, in a world where most people have computing resources to spare on a heavy framework like Electron.
danenania 45 days ago [-]
There's nothing stopping you from doing this with a server on localhost. You just need to think a bit about security (and be extra careful if you're running a websocket server since they don't do origin checks by default).
LinguaBrowse 45 days ago [-]
Yep, you could make an HTTP server using Express.js, and a minimal GUI to go with it!

Of course, it could run headless, too. But there is attraction in making it an app that opens like familiar executables.

beaconstudios 45 days ago [-]
the HTML5 JS APIs provide most desktop functionality you could want to access from the browser - does that cover what you mean? Reading location, video & audio, interacting with local files, that sort of thing.
frosted-flakes 45 days ago [-]
Stuff like global keyboard shortcuts still isn't possible though. And you're stuck with the browser's notification system.
marcthe12 45 days ago [-]
Yes it possible. The main issue basically as all app basically on one domain localhost so USC can be bad
jiofih 45 days ago [-]
Chrome used to have a local socket API when chrome apps were still a thing.
jackconsidine 45 days ago [-]
Very 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 suggestions?

omneity 45 days ago [-]
It’s unfortunate but the component library situation is really Svelte’s weak point currently.

At Monitoro[0] we bit the bullet and implemented the vast majority of our components from scratch. Apart from the obvious time to develop and test, and the trailing bugs that are hard to solve for small closed source projects, the experience wasn’t that bad.

Ultimately what helped us the most is writing our components using a state machine-like pattern, mixed with TailwindCSS to make styling easier.

In our case, the effort was worth it as we anyway needed several super specific components, and now that we’re over the hill we have complete control on our UX.

(Also having built component libraries/design systems before in different UI frameworks, doing it in Svelte was one of the best experiences so far)

There are some efforts in the Svelte ecosystem but they’re small and do not have much firepower behind, thus limited or of relatively low quality.

[0]: https://www.monitoro.xyz

jackconsidine 45 days ago [-]
Word, thanks! I think it's interesting because Svelte community support is pretty big. The repo's consistently been on Github's Trending repos for the past 2.5 years and it has an impressive number of stars
capableweb 45 days ago [-]
> been on Github's Trending repos for the past 2.5 years and it has an impressive number of stars

Wow, must mean the project is real important. I agree that svelte is interesting, but focusing on metrics and popularity is the wrong approach to new technology.

jackconsidine 45 days ago [-]
You can't judge a technology by its popularity. But I was judging the ecosystem by its popularity and those things are very highly correlated. More people bookmarking a project mean in theory it should have better 3rd party library support.
capableweb 45 days ago [-]
You're judging the ecosystem based on the stars/trendiness of Sveltes repository? That feels even more wrong and you're doing a lot of extrapolation here.
LinguaBrowse 45 days ago [-]
In terms of IDE support, VS Code with the Svelte extension is the best around!

A component library is a bit much to come until Svelte NodeGUI gets a bit more attention. Even Svelte web projects are underpopulated on component libraries, I believe. But it’s worth trying out the built-in primitives first!

zeroc8 45 days ago [-]
No suggestions, unfortunately. The lack of a comprehensive UI component library a la PrimeReact/NG/Vue really is a showstopper. Doesn't have to be free. But component providers do not seem to care about Svelte.
byproxy 42 days ago [-]
gigel82 45 days ago [-]
I've been following react-nodegui since it was announced and I really like it. In terms of memory usage it's the cat's meow; now there's a question of adoption and component / UI libraries for the ecosystem.

Perhaps a way to bootstrap that would be to align closer to react-native; at that point, we could use (js) components and libraries from react-native land.

The QT licensing question is also somewhat iffy; you need to put front and center what that implies for users of your library (do they need to open source their use of react-nodegui by extension of QT's licensing requirements for example).

kall 45 days ago [-]
Since you seem to be familiar with both, can you say something about what react-nodegui offers compared to react native?

Is it just way simpler to use, like electron? Or does QT offer a more consistent cross platform experience? Or is it more mature than react-native-macos? Or for when you want to run on linux?

All things that could be appealing to me if it did that.

gigel82 45 days ago [-]
react-nodegui is much simpler to use and more compatible because there's just node underneath, whereas react-native has varying js engines per-platform and a large library straddling the native-js bridge that reinvents things like Promise or XHR (it also cannot use native node modules). This reinvention also adds to the bloat (the calculator sample uses around 50Mb RAM with react-native-windows vs. 15Mb with react-nodegui, but it's a Store / UWP app whereas nodegui is win32 so it's not apples-to-apples).

However, react-native does have a sizeable addon ecosystem including UI frameworks (nowhere near web, but definitely more than nodegui's zero).

I didn't try react-native-macos, but I am using react-native-windows, which is functional enough and lets us share code between iOS, Android and Windows (I want to try react-native-macos but it looks like it doesn't get as much investment as windows).

kall 45 days ago [-]
Thank you. A more lightweight model is very appealing to me. I just started a react-native-macos experiment, and it's not as smooth as iOS. The tooling alone on a multi platform, non expo RN app... Does react-nodegui offer straightforward builds like electron-builder?
davej 45 days ago [-]
It would be nice to have the ability to weave in WebViews with the native UI. I see this lib but it's still marked as WIP: https://github.com/nodegui/nodegui-plugin-webview
crazypython 45 days ago [-]
Styling with CSS is interesting.
butz 45 days ago [-]
Would it be possible to use Deno for JS runtime? That should add some sandboxing limitations for apps.
LinguaBrowse 45 days ago [-]
I’d need to pass that question on to Atul (who made the parent project, NodeGUI). As long as Deno supports the same native API bindings as Node does (does it?), I imagine that it wouldn’t be out of the question.
singularity2001 45 days ago [-]
Is there any electron like framework which uses the native webview libraries (webkit etc) instead of shipping their whole browser for each application?
hybridtupel 45 days ago [-]
I guess Tauri [1] is like what you are looking for. Was featured here a a few days ago [2].

[1] https://tauri.studio/en/

[2] https://news.ycombinator.com/item?id=26194990

Schampu 45 days ago [-]
There is a WebKit based HTML renderer called Ultralight. It works by creating hooks and intercepting the rendering calls of WebKit in order to allow embedding it easily.

Unfortunately the license of Ultralight is questionable, and it's not open-source either by bypassing the WebKit license (which is very questionable as well since WebKit itself is BSD-licensed).

Having such a project as a free open-source variant would be a huge game changer in my opinion.

ognarb 45 days ago [-]
baybal2 45 days ago [-]
How is it "light" weight?

> Low CPU and memory footprint. Current CPU stays at 0% on idle and memory usage is under 20mb for a hello world program.


j-krieger 45 days ago [-]
So what? If you stored each Pixel on a modern WQHD monitor, that would be 15mb. Its almost like people on HN dont know what theyre talking about
baybal2 45 days ago [-]
At least, that will be a shared system framebuffer, not applications own memory.
radiKal07 45 days ago [-]
I think Flutter Desktop is also a good alternative to Electron
majkinetor 45 days ago [-]
Will wait for MAUI.
chovybizzass 45 days ago [-]
how about deno?
fuckccp 45 days ago [-]
If you can’t reuse/share a lot of web technologies/stacks/libraries. Why would you not go for flutter instead
rado 45 days ago [-]
Calculator demo doesn't run, makes some cmake errors.
gigel82 45 days ago [-]
The react-nodegui calculator example runs fine for me; on Win10 x64 it uses 14.4Mb of RAM and spawns a single process.

Really impressive resource-wise, now let's get the UI components / frameworks ported...

tpmx 45 days ago [-]
So is it Chromium-based or not? "which makes it CPU- and memory-efficient when compared to other Chromium-based solutions like Electron"
LinguaBrowse 45 days ago [-]
Its UI runtime is Qt and its JS runtime is Node.js. No Chromium here :) it makes super-small, low-memory apps.
crazygringo 45 days ago [-]
Yes, I suppose people could be understandably be confusing V8 with Chromium.

It's using the same JavaScript engine as Chromium, which is of course developed by Chromium and is part of it, but without the rest of Chromium, as Node.js always has.

It's a great example of synecdoche [1]. :)

[1] https://en.wikipedia.org/wiki/Synecdoche

tpmx 45 days ago [-]
V8 is tiny compared to the operating system known as chromium.

Anyway, it was just a misunderstanding based on poor writing on the web page.

mkl 45 days ago [-]
The word "other" probably shouldn't be there. It seems to wrap Qt. From the NodeGUI page: "it is a wrapper for a native C++ widget toolkit QT".
zachrip 45 days ago [-]
They're making use of yoga (a layout engine) so I assume that it is not web based (because why would you use yoga otherwise).
danenania 45 days ago [-]
Looks like it's node + QT, not chromium.
tpmx 45 days ago [-]
nawgz 45 days ago [-]
Seems weird to slander a community instead of stating what happened, which is that the extraneous "other" made the meaning ambiguous.
f430 45 days ago [-]
How do you deal with zero day vulnerabilities? To me the biggest concern using browser-as-a-desktop solution is that there will be quite a lag between when Chrome patches zero days vs when it gets released.

ex) nw.js, electron.

capableweb 45 days ago [-]
> To me the biggest concern using browser-as-a-desktop solution

Then this project sounds perfect for you because it's not a browser, it's Qt5 but called via APIs that JS developers are used to.

f430 45 days ago [-]
Isn't it rendering html5/javascript like a browser would? it would be great if somebody could take time to reply and explain things in a calm logical manner without reaching for downvotes
Aeolun 45 days ago [-]
I think nobody wants to tell you since it’s something that is easily found on the linked site.

To answer your question, there is no more HTML involved in this than in a React Native app. The result looks like HTML, but it’s really used to compose native OS widgets.

f430 45 days ago [-]
my bad i saw the github but couldn't find any code examples other than someone smiling
ZachS 45 days ago [-]
What sort of vulnerabilities are you worried about? You're running trusted code, connecting to a trusted service via https. Not browsing arbitrary websites. I doubt many vulnerabilities would affect this.
f430 45 days ago [-]
> trusted service via https

you think that would stop a zero day vulnerability? if you have browser that won't be updated for a long time and its connected to the internet, it is a huge attack surface.

Unless you were running local static file without ever talking to the internet.