Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI
github.com
github.com
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 )
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.
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.
"Almost everything on computers is perceptually slower than it was in 1983" https://threadreaderapp.com/thread/927593460642615296.html
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.
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.
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.
* 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.
This is part of what I meant when I said "drastically restrict the problem space".
We had them.
I'm just kidding. Don't want to start a fight here.
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.
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.
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.
For C/C++, could use QT Creater or KDevelop too, which I think are pretty good in latency.
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? :)
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.
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.
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.
For searching, use SilverSearcher / fzf
Thanks for sharing!
The intro looks great I will definitely check this out.
Even so, shouldn’t it be able to do that in 16ms?
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.
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.
> 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/
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.
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.
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.
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.
https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-need...
> The next thing is also fairly straightforward: we expect Kotlin to drive the sales of IntelliJ IDEA.
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.
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.
What on earth have we done to ourselves?
That's a big part of what we've done to ourselves. And this makes computers better for a whole lot of people.
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.
https://www.fltk.org/doc-1.3/fluid.html
You pretty much draw the UI in fluid and fill out the callbacks. Yeah it's C++ but it's not particularly esoteric C++.
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.
Also, there was a really fantastic question asked in the last Cosmopolitan thread, but it wasn't answered; what's the answer to it?
Some friend of mine like it :D.
But I'd like that more if it was Scheme.
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.
Electron does not provide that much more desired features than apps from 25 years ago.
It's open source, I've been meaning to poke around and see what they are doing differently.
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.
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.
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.
- 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 :).
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.
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.
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.
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.
- 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.
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.
jart@debian:~/scratch/qtproject$ qmake -project
jart@debian:~/scratch/qtproject$ make
jart@debian:~/scratch/qtproject$ ldd ./qtproject | grep -Po '(?<==> )[^ ]*' | xargs ls -alH | awk '{x += $5} END {print x / (1024 * 1024.)}'
59.5916
why ? it entirely depends on how your linux distro chose to build Qt, not on Qt itself.
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.
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...
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.
IIRC on macOS it consumed less than 15MB.
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/
Electron has been around what? 7 years?
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).
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
This is a perfect analogy. To stretch it, the majority of sports car owners are developers. The vast majority of your users are not.
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.
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.
Also HN: "The MacBook Pro is worthless if I can't get it with at least 64GB of RAM."
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.
(2560 * 1600 * 4) / 1024 / 1024 = 15 MB
So no, that is not huge for a modern GUI program.
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
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.
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?
This is a super-interesting project though.
Agree with your final part, very exciting and gonna be interesting to see where nodegui goes, especially security wise.
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.
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.
That's already GTK+ and Qt, and the big GTK+ and Qt projects aren't switching over to Flutter any time soon.
Edit: NodeGUI here: https://github.com/nodegui/nodegui
yep, basically you have to do :
auto window = QWindow::fromWinId(reinterpret_cast<WId>(/* HWND, NSView, X11 buffer, Wayland surface... /*));
auto widget = QWidget::createWindowContainer(window);
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.
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 ?
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
Atul is licensing NodeGUI as MIT, so I’m licensing Svelte NodeGUI as MIT accordingly.
"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."
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
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.
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.
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.
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.
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?
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?
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?
An example of native UI is libui or WxWidgets.
A similar thing happened to Android.
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.
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.
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.
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)
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.
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.
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.
https://github.com/c-smile/sciter-js-sdk/blob/main/LICENSE
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.
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.
Of course, it could run headless, too. But there is attraction in making it an app that opens like familiar executables.
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.
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?
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.
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.
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!
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).
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.
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).
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.
> Low CPU and memory footprint. Current CPU stays at 0% on idle and memory usage is under 20mb for a hello world program.
20MB!
ex) nw.js, electron.
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.
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.
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.
Really impressive resource-wise, now let's get the UI components / frameworks ported...
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]. :)
Anyway, it was just a misunderstanding based on poor writing on the web page.