22 ms·

Show HN: Svelte NodeGUI, a lightweight Electron alternative with native UI

624 points by LinguaBrowse 6y ago

LinguaBrowse 6y ago
Maintainer here – Happy to answer any questions!
- boromi 6y ago
  Any Win 10 fluent examples? Perhaps WinUI integation?
  - LinguaBrowse 6y 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 https://github.com/nodegui/nodegui
    - ComputerGuru 6y 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 6y 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).
- nguyenkien 6y ago
  Off topic, any plan to make ot work with react native?
  - LinguaBrowse 6y 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 6y 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 ?
- glutamate 6y 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 6y 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 6y 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 https://wiki.qt.io/Licensing-talk-about-mobile-platforms
- mrwoggle 6y ago
  I know QT is dual licensed for application development. How's the licensing here?
  - LinguaBrowse 6y ago
    Some clarification on that from the maker of the parent project, NodeGUI, here: https://twitter.com/a7ulr/status/1225498258233053184?s=21 https://twitter.com/a7ulr/status/1225498258233053184?s=21 Atul is licensing NodeGUI as MIT, so I’m licensing Svelte NodeGUI as MIT accordingly.
  - flipcoder 6y ago
    From Qt's page https://www.qt.io/licensing/open-source-lgpl-obligations 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 6y 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 https://github.com/chromium/chromium/search?q=%22kde.org%22
      - varajelle 6y 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.
- jjcm 6y ago
  Does this use the native OS’s current default browser renderer? If so is windows using edge or chromium under the hood?
  - dgreensp 6y ago
    There's no browser component. Qt (https://www.qt.io/ https://www.qt.io/) is the granddaddy of native cross-platform GUI.
- pfraze 6y 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 6y ago
    Qt supports this! so you should be covered.
- norswap 6y 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 6y 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.
- himujjal 6y ago
  I might go a little offtopic here. Any plans to integrate https://github.com/c-smile/quickjspp 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.
- bmn__ 6y 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.
- esperent 6y 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?
- esperent 6y 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?
Gys 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago
danenania 6y 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 6y 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 6y 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 6y 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 https://www.todesktop.com/cli
  - jiofih 6y ago
    Both the App Store and Microsoft Store deal with installs and updates, no need for custom wrappers. Not sure about Linux.
karteum 6y 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 https://tonsky.me/blog/disenchantment )
- mixedCase 6y ago
  It's definitely not. It's just a different toolkit that the one you already have in memory, so it can't "cheat".
- afavour 6y ago
  That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhere in the middle. OT but a bone to pick with that article: > Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters. Sometimes I feel like people forget that.
  - setr 6y ago
    However, most of that should be done in the background — it shouldn’t affect your actual text input speed. Auto-format is more along the lines of something that could be blocking, but we’re not dealing with latex problems as to be significant
    - andylynch 6y ago
      Even putting that aside, just showing text on a screen is much slower on modern PCs then older ones, since you have a far more complicated graphics stack and latency at several added steps. I remember an article a couple of years ago where someone rigged up a camera to measure key press to screen update on different machines and the results were eye opening. edit: found it http://danluu.com/input-lag/ http://danluu.com/input-lag/. The Apple ][ ties for first place with an iPad Pro.
tpmx 6y 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 6y ago
  Its UI runtime is Qt and its JS runtime is Node.js. No Chromium here :) it makes super-small, low-memory apps.
  - crazygringo 6y 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 https://en.wikipedia.org/wiki/Synecdoche
    - tpmx 6y 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.
- danenania 6y ago
  Looks like it's node + QT, not chromium.
  - tpmx 6y ago
    Yeah.
    - nawgz 6y ago
      Seems weird to slander a community instead of stating what happened, which is that the extraneous "other" made the meaning ambiguous.
crazypython 6y ago
Styling with CSS is interesting.
endisneigh 6y 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.
- beaconstudios 6y 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 6y ago
    Stuff like global keyboard shortcuts still isn't possible though. And you're stuck with the browser's notification system.
- danenania 6y 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 6y 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.
- julienb_sea 6y 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.
jackconsidine 6y 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?
- zeroc8 6y 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.
- omneity 6y 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 https://www.monitoro.xyz
  - jackconsidine 6y 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
rado 6y ago
Calculator demo doesn't run, makes some cmake errors.
- gigel82 6y 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...
davej 6y 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 https://github.com/nodegui/nodegui-plugin-webview
butz 6y ago
Would it be possible to use Deno for JS runtime? That should add some sandboxing limitations for apps.
- LinguaBrowse 6y 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.
gigel82 6y 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 6y 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 6y 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 6y 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?
jart 6y 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 https://en.wikipedia.org/wiki/KHTML
- anthk 6y 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.
- capableweb 6y 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 6y 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.
f430 6y 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.
- ZachS 6y 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 6y 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.
- capableweb 6y 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 6y 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 6y 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.
porphyra 6y 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 6y 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.
ognarb 6y ago
Something similar: https://www.kdab.com/declarative-widgets/ https://www.kdab.com/declarative-widgets/
c-smile 6y ago
Same demo in VanilaJS and Sciter.JS : https://github.com/c-smile/sciter-js-sdk 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 6y 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 6y ago
    The license looks ok: https://github.com/c-smile/sciter-js-sdk/blob/main/LICENSE 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.
    - anilgulecha 6y 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.)
fuckccp 6y ago
If you can’t reuse/share a lot of web technologies/stacks/libraries. Why would you not go for flutter instead
ssss11 6y 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.
chovybizzass 6y ago
how about deno?
singularity2001 6y 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 6y 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/ https://tauri.studio/en/ [2] https://news.ycombinator.com/item?id=26194990 https://news.ycombinator.com/item?id=26194990
- Schampu 6y 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.
sonthonax 6y 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.
- techdragon 6y ago
  That was sort of half doable with the horribly insecure Microsoft Hypertext Applications https://en.wikipedia.org/wiki/HTML_Application 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)
- Stratoscope 6y 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: http://forums.apricitysoftware.com/t/why-is-markdownpad-spawning-3-instances-of-awesomiumprocess-exe/172/8 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.
baybal2 6y 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. 20MB!
- j-krieger 6y 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 6y ago
    At least, that will be a shared system framebuffer, not applications own memory.
radiKal07 6y ago
I think Flutter Desktop is also a good alternative to Electron
majkinetor 6y ago
Will wait for MAUI.

624 points by LinguaBrowse 6y ago

LinguaBrowse 6y ago

Maintainer here – Happy to answer any questions!

boromi 6y ago
Any Win 10 fluent examples? Perhaps WinUI integation?
- LinguaBrowse 6y 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 https://github.com/nodegui/nodegui
  - ComputerGuru 6y 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 6y 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).
nguyenkien 6y ago
Off topic, any plan to make ot work with react native?
- LinguaBrowse 6y 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 6y 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 ?
glutamate 6y 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 6y 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 6y 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 https://wiki.qt.io/Licensing-talk-about-mobile-platforms
mrwoggle 6y ago
I know QT is dual licensed for application development. How's the licensing here?
- LinguaBrowse 6y ago
  Some clarification on that from the maker of the parent project, NodeGUI, here: https://twitter.com/a7ulr/status/1225498258233053184?s=21 https://twitter.com/a7ulr/status/1225498258233053184?s=21 Atul is licensing NodeGUI as MIT, so I’m licensing Svelte NodeGUI as MIT accordingly.
- flipcoder 6y ago
  From Qt's page https://www.qt.io/licensing/open-source-lgpl-obligations 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 6y 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 https://github.com/chromium/chromium/search?q=%22kde.org%22
    - varajelle 6y 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.
jjcm 6y ago
Does this use the native OS’s current default browser renderer? If so is windows using edge or chromium under the hood?
- dgreensp 6y ago
  There's no browser component. Qt (https://www.qt.io/ https://www.qt.io/) is the granddaddy of native cross-platform GUI.
pfraze 6y 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 6y ago
  Qt supports this! so you should be covered.
norswap 6y 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 6y 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.
himujjal 6y ago
I might go a little offtopic here. Any plans to integrate https://github.com/c-smile/quickjspp 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.
bmn__ 6y 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.
esperent 6y 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?
esperent 6y 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?

Gys 6y 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 6y 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 6y 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 6y 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 6y 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 6y ago

danenania 6y 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 6y 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 6y 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 6y 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 https://www.todesktop.com/cli
- jiofih 6y ago
  Both the App Store and Microsoft Store deal with installs and updates, no need for custom wrappers. Not sure about Linux.

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

mixedCase 6y ago
It's definitely not. It's just a different toolkit that the one you already have in memory, so it can't "cheat".
afavour 6y ago
That blog post does speak to me, but 20MB for a program with a truly functional, modern UI doesn't outrage me that much. IMO there's a tradeoff: we could be writing all our programs in C, still. But it would be enormously difficult and there'd be way more bugs. On the other end of the spectrum we can be lazy, use web tech everywhere and never optimise our ballooning JS codebases. This feels like it's at least somewhere in the middle. OT but a bone to pick with that article: > Modern text editors have higher latency than 42-year-old Emacs. Text editors! What can be simpler? On each keystroke, all you have to do is update a tiny rectangular region and modern text editors can’t do that in 16ms. It’s a lot of time. A LOT. That isn't what my text editor is doing, though. It's doing autocomplete suggestions, linting code as I type... all sorts of things we never had a couple of decades ago and are huge productivity boosters. Sometimes I feel like people forget that.
- setr 6y ago
  However, most of that should be done in the background — it shouldn’t affect your actual text input speed. Auto-format is more along the lines of something that could be blocking, but we’re not dealing with latex problems as to be significant
  - andylynch 6y ago
    Even putting that aside, just showing text on a screen is much slower on modern PCs then older ones, since you have a far more complicated graphics stack and latency at several added steps. I remember an article a couple of years ago where someone rigged up a camera to measure key press to screen update on different machines and the results were eye opening. edit: found it http://danluu.com/input-lag/ http://danluu.com/input-lag/. The Apple ][ ties for first place with an iPad Pro.

tpmx 6y 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 6y ago
Its UI runtime is Qt and its JS runtime is Node.js. No Chromium here :) it makes super-small, low-memory apps.
- crazygringo 6y 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 https://en.wikipedia.org/wiki/Synecdoche
  - tpmx 6y 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.
danenania 6y ago
Looks like it's node + QT, not chromium.
- tpmx 6y ago
  Yeah.
  - nawgz 6y ago
    Seems weird to slander a community instead of stating what happened, which is that the extraneous "other" made the meaning ambiguous.

crazypython 6y ago

Styling with CSS is interesting.

endisneigh 6y 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.

beaconstudios 6y 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 6y ago
  Stuff like global keyboard shortcuts still isn't possible though. And you're stuck with the browser's notification system.
danenania 6y 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 6y 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.
julienb_sea 6y 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.

jackconsidine 6y 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?

zeroc8 6y 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.
omneity 6y 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 https://www.monitoro.xyz
- jackconsidine 6y 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

rado 6y ago

Calculator demo doesn't run, makes some cmake errors.

gigel82 6y 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...

davej 6y 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 https://github.com/nodegui/nodegui-plugin-webview

butz 6y ago

Would it be possible to use Deno for JS runtime? That should add some sandboxing limitations for apps.

LinguaBrowse 6y 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.

gigel82 6y 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 6y 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 6y 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 6y 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?

jart 6y 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 https://en.wikipedia.org/wiki/KHTML

anthk 6y 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.
capableweb 6y 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 6y 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.

f430 6y 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.

ZachS 6y 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 6y 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.
capableweb 6y 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 6y 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 6y 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.

porphyra 6y 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 6y 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.

ognarb 6y ago

Something similar: https://www.kdab.com/declarative-widgets/ https://www.kdab.com/declarative-widgets/

c-smile 6y ago

Same demo in VanilaJS and Sciter.JS : https://github.com/c-smile/sciter-js-sdk 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 6y 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 6y ago
  The license looks ok: https://github.com/c-smile/sciter-js-sdk/blob/main/LICENSE 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.
  - anilgulecha 6y 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.)

fuckccp 6y ago

If you can’t reuse/share a lot of web technologies/stacks/libraries. Why would you not go for flutter instead

ssss11 6y 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.

chovybizzass 6y ago

how about deno?

singularity2001 6y 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 6y 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/ https://tauri.studio/en/ [2] https://news.ycombinator.com/item?id=26194990 https://news.ycombinator.com/item?id=26194990
Schampu 6y 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.

sonthonax 6y 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.

techdragon 6y ago
That was sort of half doable with the horribly insecure Microsoft Hypertext Applications https://en.wikipedia.org/wiki/HTML_Application 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)
Stratoscope 6y 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: http://forums.apricitysoftware.com/t/why-is-markdownpad-spawning-3-instances-of-awesomiumprocess-exe/172/8 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.

baybal2 6y 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. 20MB!

j-krieger 6y 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 6y ago
  At least, that will be a shared system framebuffer, not applications own memory.

radiKal07 6y ago

I think Flutter Desktop is also a good alternative to Electron

majkinetor 6y ago

Will wait for MAUI.