I'm currently developing a web app and while my nw.js/electron version is around 50 MB and uses 200+ MB of memory, loading it in Firefox it's a 600kB bundle, fully renders in less then half a second, and uses a whopping 8 MB of memory in Firefox. Actually less the HN! So while I think this project is cool, if you consider using it, also consider making a in browser web app. Also remember that the browser is more then just a HTML renderer. You have stuff like speech recognition, text-to-speech, user input, sound api, 2d/3d api, support for a bunch of mobile sensors like accelerometer, etc.
I think you're failing to include the firefox memory usage in that second example. the 200+MB memory of electron is because it includes the browser. Your 8MB file also needs firefox to run, so in a naked desktop environment the user first has to spin up 170MB+ of firefox before they can run your 8MB app.
But you do not need to have five full Firefox's running for using five web-app's.
Another benefit of web apps, is that with some effort it can run everywhere, where as an app container like electron needs to have separate builds for each platform.
Mozilla had an experimental project called qbrt that was like electron but used the locally installed Firefox, exactly like you're describing. Hasn't been updated in quite a while though
When you say consider using an “in browser” web app what do you mean by that precisely? Do you mean consider if you can get by using browser based offline/local capabilities and not go outside the sandbox?
See my other comment on rebuilding FF, not sure if you meant anything overlapping.
You would have to run non-sandboxed features via a server, which can run on the user machine! Chrome, Firefox, Opera, IE, Edge supports starting the browser in "chrome"-less or "app" mode, so the program will feel native. You could also run the server part in the cloud! And use "add to desktop" to get the "chrome"-less mode which is currently supported on Chrome and Firefox on Android. Or just run the app in a browser tab :)
I feel like there's room for an Electron variant that's just "less electron". As in, I don't need all of Chrome to do my thing; just the HTML rendering engine and JavaScript interpreter.
The thing that makes it 50gb is all the web sockets and ie4-comparable-iframe-shims that nobody ever uses on the desktop. Lop all that stuff and see how big the install is and how much memory it uses. My guess is it would be a lot less.
I know one of the whole appeals of Electron is the single target, plus being able to take advantage of Node, but I feel like some OS-intergration would be nice. Basically, PWAs for desktop.
On Mac you could have a PWA-like target that is backed by the built in Safari, so all you need to distribute is your app (HTML + JS + CSS) itself and it just uses the OS-provided browser runtime.
I'd welcome optimizations, but do we really care if an app is 50MB, in 2018?
I see a lot of bashing against Electron because of the size and memory consumption of Electron apps, but at least on Linux Electron is a blessing. Many times it's either an Electron app or no app at all, as many companies wouldn't bother supporting Linux if Electron didn't make it so cheap and easy.
With that in mind, with many laptops coming with 128GB of storage and 8GB of RAM nowadays, it it really that big a concern?
Even less for developers: my laptop has 1TB HDD + 256GB SSD, and 24GB of RAM. I can definitely spare 50MB of disk space and 200MB of RAM.
> but do we really care if an app is 50MB, in 2018?
> my laptop has 1TB HDD + 256GB SSD, and 24GB of RAM. I can definitely spare 50MB of disk space and 200MB of RAM.
How much cache does your laptop have? All this RAM usage completely thrashes any caches anywhere. Page caches, disk cache, etc.
Slack alone takes a heavy toll on my laptop. Combine it with any heavy website on FF (which has gone insane on mac since Quantum) and the laptop is ready for take-off.
Not to mention that we are slowly putting a ±$1k price tag on "comfortable computing". People who spend <$300 on a computer are absolutely screwed, even though they have orders of magnitude more power than a device which took humanity to the moon (to use a hackneyed comparison).
I find using developer computers as a measuring stick a painfully elitist perspective. In an ideal world, software developers would be banned from spending more than $250 on hardware. Ever. [for their current workstation]. That would do more to change the face of software than any processor improvement ever did.
> Many times it's either an Electron app or no app at all, as many companies wouldn't bother supporting Linux if Electron didn't make it so cheap and easy.
I agree with this. However, focusing on first order consequences can be deceptive. Perhaps it is precisely the existence of Electron that suffocates any budding competition for more performant but slightly more involved alternatives?
Make WPF-like replacement that works on Windows, macOS, Linux, Android, iOS and their browsers and we will all switch. You are demanding that we all become mega crops with N teams duplicating the same code in with native frameworks and that just won't happen because a) we don't have cash laying around b) users don't know the difference between 10 MB app and 200 MB app, only us do.
> How much cache does your laptop have?
Enough. How much bandwidth does my ram have? Enough that it can fill cpu caches in I don't notice time. I still have 12 year old Conroe with spinning hard disk laying around and it never had any problem running VS Code so there's that data point.
I dont mind running 1 electron app on my desktop, where battery isnt an issue, but imagine if every app you run all day was electron. How long would a battery last? How much more energy is being consumed across the world because of it? If your making a get-in-get-out type of app, its a no-brainer, but if your making a live communications app, a text editor for professional text enterers, an image editor for artist, that's supposed to run all day, I think its worth considering something more efficient. It'd be a hard comparison to make right, but I'd like to see if electron apps don't undo all the energy saving changes done by chip manufactures.
By my old standards I have a supercomputer on my lap. I want it to perform like a supercomputer. I don't what all that power to get eaten by programmers using inefficient technologies.
In this age of portable devices and the battle to get decent battery life out of your machine, Electron apps strike me as counterproductive. There's more to it then just memory usage, I think.
My laptop is high spec, but each running an Electron app probably reduces my battery life by 20-40 minutes, and if I'm running 3-4 that's a significant drain.
The difference in battery life between Chrome + Slack + Atom at work, and Safari + Sublime at home is huge. Quitting Slack often gives me an hour more battery.
>but do we really care if an app is 50MB, in 2018?
What happens when every developer decides user resources are practically infinite, so every application uses as much of everything it wants to all the time?
What does the current landscape of javascript on the web look like? Not exactly a model of efficiency and speed, for more or less that reason.
> I can definitely spare 50MB of disk space and 200MB of RAM
Yeah, once. For a game, or a movie. But not 100 times for utilities I am actively using. Imagine, any given application can be run together with dozens, hundreds of others. Just like any given website is rarely the only website that's open.
Looking towards resources you can waste is the wrong approach. Look for waste you can do without, period.
My question to those who are more informed than me is the following: why isn't the runtime distributed separately, like the JRE? It would essentially allow for smaller apps while keeping the advantages of Electron. It's an obvious thing so I'm sure there are reasons I'm not considering.
So to me, the issue with Electron is that I'm already running Chrome, so I should be able to take advantage of that. In particular, if I have N electron apps, I want 1 Chrome running. I don't want to run certain applications inside the browser, I want the separate app icon, etc. Is there anything that is being done in Chrome/FF to support that kind of thing? That way it's up to the site consumer's preference how they wish to consume the app, by having a native browser consumer and not starting their own little Chrome each time. And for the developer, they're basically shipping "containerized" code around, modulo some features being unavailable in browser vs native, which could be feature detected.
Why? To save a little disk space? There are a lot of downsides to that. Microsoft thought DLLs were a good idea once.
I know Chrome has better isolation but it’s still not as idiot proof and most importantly, as cheap to support as having your own totally independent app.
If a user contacts you with a bug, you immediate know for a fact it has nothing to do with any new chrome update or possible problems chrome may be having and vastly narrow down the problem space.
Given that chrome gives each tab its own heavy weight forked process, it is also pretty irrelevant conceptually. OP didn't explain what advantage he thought he'd get out of it being the same process he already runs other than saving some MB of exe cache. Perhaps that's all he wants.
What would be the disadvantages of just using a custom build of firefox for apps that bundles non-sandboxed libraries as needed?
So for example, firefox.exe could actually be built to be my app.exe, with the generic browser UI replaced with specific app menus.
The build could have options for bundling any library, or provide a simple OS essentials abstraction library with a web sockets or local web server http interface.
It would be a single use custom UI browser “app” with the same potential power as an OS native app but easily portable.
Benefits
- I think FF is a ~50MB download so after stripping out a little generic browser functionality, simple utility apps should be about the same
- One of the biggest problems with these ideas normally is the actual multi-platform deployment can become the hardest part of a cross platform app, yet FF has a polished multi platform install/setup solution already fully figured out and maintained.
There is theory and practice. similar concepts, but for so long we’ve heard big hassles with electron solution real life deployment solutions (some companies only don’t even deploy electron multi platform, if it were that simple more would).
Also with memory usuage which was mentioned elsewhere in this discusssion.
The idea is maybe it could be done better. On the other hand maybe Electron has made great strides over last year or so, it would depend on how much progress has been made.
Cross platform code is great but in the end doing that while getting something out the door end to end multiplatform as fast as possible is key, while at the same time not having performance significantly worse than it would normally be for the same code in an off the shelf browser.
I think the whole 'hot-module-reloading' thing is pretty compelling, but its possible to do apart from a JS environment (see flutter for instance). The library that Vuido runs on, libui, has bindings to all kinds of languages:
There is a movement to use the same tech on desktop as you would on the web, but is anything moving in the opposite direction? Will there be a web version of QT or something? That would be great.
> Will there be a web version of QT or something? That would be great.
There is a Web(Assembly) version of Qt, currently as a technology preview. It's not great IMO, because it's inaccessible to screen readers and other assistive technologies. The lack of accessibility is because the current solution for web application accessibility, setting ARIA attributes on HTML elements, isn't a good fit for rendering to canvas or WebGL. Maybe the browser vendors will provide an alternative. Then again, maybe they won't, and Qt will have to work around that impedance mismatch. In the meantime, I recommend that developers continue developing web applications using web technologies directly.
I don't use these technologies but looking at the screenshot in the post, it triggers some memories of Adobe's Flex XML declarative UI making. It feels like the same technologies just continue to be reinvented. Flex and Air were gonna be the future everybody was talking about it... And here we are now.
awesome. this is clearly an early proof-of-concept but I'll keep my eye on the project. I'm also hopeful for weex (like react native for vue). despite moving from alibaba to become an apache foundation incubator project, it has a long way to go in terms of documentation -- nativescript seems to be winning that particular battle in the vue world right now. it's exciting to see a desktop project come along. vue makes a lot of sense for native apps because its transition engine really lends itself to a "native feel" without a lot of development overhead[1]. great work.
I think the coolest thing about this is that it's using libui [1], so whether you're trying to work on Proton Native, or Vuido, or any other flavor of NodeJS-to-Native-GUI [2], we'll hopefully end up contributing to a single library. (PS: libui has bindings to other languages as well [3]!)
Why don’t I see more “native” applications just running through a locally hosted web server? It’s the best of both worlds: file system access with your server, and a great environment for developing a UI (any browser).
Nice. For those who don't care about native UI : has anyone tried to ship a react-like library used in the OS native browser ? That way you avoid Electron bloat, you just need to take care of the design for different native browsers.
Speaking just for myself...I like that Slack has the same look and feel no matter what platform I bring it up on. I prefer a unified cross-platform experience over a unified platform experience. I want my OS to disappear. I am probably biased by regularly targeting multi platform myself.
This causes me to favor other lowest common denominator idioms as well, like python 2.7 over 3, unconfigured vim, bash on windows, etc. When this isn’t possible, I favor technologies that allow me to synchronize configurations across platforms quickly and easily.
Every comment you've made has been about publii - leading me to believe you're associated with it. HN is supportive of people pitching their products - but I would suggest you disclose your association in comments - otherwise it's just plain spammy.
Yes, you are right. I use and love this app. I'm trying help publii team to promote their product. Their team is just two people, so any help is appreciated, especially that this is free, open source soft. What wrong with my comments? There are only a few and always on the subject. I don't understand your point of view.
One question: why would you use the awful clusterfuck that is JavaScript on the desktop where you’ve got the freedom to choose from dozens of lovely languages that actually are a pleasure to use?
JS is a necessary evil on the web, but why inflict such pain to yourself when you’re able to use something else?
Why do you speak English when you could be speaking French? Because it's what you know, and lucky for you it's everywhere and you don't need to learn French.
I'm making some assumptions about you as a person but you take my point I hope. People use JavaScript over other languages because they already know it and, hey, look, you can use it anywhere. Sure, it might be more efficient to go and learn python or C++ or assembly or whatever but most people are happier to leverage the skills they already have than go and learn a new language for one app.
I'm a JavaScript coder by profession and in my extremely limited spare time I want to build things, and if i use JavaScript it maximizes my time.
Exactly. People mock me for using Python and MongoDB at hackathons but I have won my first Hackathon cause I spent my time getting code done and not thinking too hard about it.
It was a lot of fun and the first time we ever worked with any Telecoms / VoIP companies. Also planning on competing on TADHack Global this time joining forces with another team. Didn't win much since others won as well, apparently you could use all the vendors, we only used one.
I don't know about that, this one was at the college I used to work at before and I got to mentor two young developers and I continue to mentor one of them. Not everything is as bad as people might think, and some developers work different from others. We saw some amazing projects out of TADHack Mini.
Lastly: Nobody has our code but we ourselves. It really depends on who hosts the Hackathon and the purpose of it. We've heard of businesses being bootstraped directly out of this specific Hackathon.
Also, "you can use it anywhere" really does apply to Javascript in a way that it doesn't to other languages (at least, not until there's full WASM<->DOM integration and a good set of compilers that uses that).
But don’t you believe in using the right tool for the job?
JavaScript is barely acceptable on the web, but again it’s a necessary evil as you can’t easily use anything else.
But why use an inadequate tool on the desktop? The perceived time you save upfront would backfire later on.
Now I’m not saying go and spend a year learning another language just to make a side project (by all means use JS or whatever you’re familiar with), but if you’re making a production-grade app, PLEASE use the right tool for the job and it ain’t JS.
I, for one, am sick of JS & Electron contaminating apps I use daily like Spotify, Slack, Signal, Telegram, etc. I wouldn’t mind it too much if this was a niche thing and there were alternatives, but there aren’t. JS on the desktop should die.
The right tool for the job is very opinionated. Clearly an awful lot of desktop devs think js is the right tool for the job because electron is everywhere and projects like this very one we're commenting on exist.
My opinionated view on "the right tool" comes down to the distinction between foreground and background apps.
I do think electron is not the right tool for the job when it comes to Spotify, because Spotify is something that mostly runs in the background and should be super performant.
On the other hand I use vscode all day every day, and I'm happy for it to use as much ram and cpu as it does because its always in the foreground - it's the main thing I'm using when I use it
Edit: I should add I think we need to find more comparisons to continue this electron debate though. Vscode is always the hero and slack and Spotify are always the villain
I'm there with you being sick of Electron apps on the desktop. The problem is, compared to the JS ecosystem, GUI apps development on desktop with any native technology I know is super bloated, slow and crappy. While I've just started trying to use Elm recently, and the speed of iteration when using it totally amazed me, so that now I cannot longer say that I don't understand why people do that. As much as it pains me.
I couldn't agree more. Ever since switching from Slack to wee-slack I have never run out of memory on my laptop, which used to be a problem every once in a while when running so many instances of electron.
Also Telegram (at least the Linux desktop client) is not electron, it is QT. Maybe some problems that people link exclusively to electron are not limited to just that platform.
I don't really think JS is bad. I actually prefer it to most languages.
It's fast, concise, flexible, and has lots of modern features. It has some weak spots, but all languages do. When people are so ideological about the language it tells me they either haven't used it much or they are unrealistic about flaws in other languages.
I actually used it, and hated it quite a bit (although ES6 solves most of my gripes with it).
I understand and appreciate the necessity of JS on the web. JS is also the perfect tool for that job as it’s been designed with the web & browsers in mind, closely tied to HTML & CSS, and while it has overheads those are a necessary evil in an environment where it’s commonplace to execute untrusted code.
But it’s however completely inadequate for the desktop. Your users already trust you since they run your binary Electron wrapper, so the “untrusted code” argument goes out the window. You’re basically taking on an extreme overhead (in terms of battery life and RAM usage) for no benefit at all. HTML/CSS is not that great either, IMO native elements provided by the OS deliver a much better UX and actually behave consistently across the entire OS.
> you’ve got the freedom to choose from dozens of lovely languages that actually are a pleasure to use?
Well there's your problem. If my choice is to wrap my existing SPA in electron in one day vs a 6 month make-and-maintain-a-copy-in-another-language, then I think the choice is obvious.
Then you have a dozen languages to choose from? All of them are lovely except JavaScript? That sounds pretty biased. If I'm going to write a desktop application and take advice from strangers, I need to know that my advisor completely understands where I'm coming from and where I'm trying to go. I don't want to get burnt because a hater is trying to give me unthoughtful "literally anything but" bad personal vendetta advice thinly vailed with technical concern trolling.
Then I have to pick one of 12 languages? I don't need "well literally anything but", I need a well written set of tutorials and/or case study demonstrating that one option is superior to JS and is written to bring JS devs to an understanding of if the tool being presented is what they need to use or not.
Normally I would agree, but GUI development with Vue is such a lovely experience. It takes advantage of many of the newer JS features to make this possible (automatic data binding via property get/set interception, for example). As a consequence it's hard to imagine providing the same in another, better language.
No, it is something that has been doing "automatic data binding via property get/set interception, for example" since 2008, so it is easy to see it in an language that isn't JavaScript.
Yeah, I've worked with XAML and such in .NET-land. DependencyProperties are nowhere near as painless and transparent as the state of things in Vue. Doing computed propeties, trying to use converters in a sane way, setting up templates for repeated items - all quite clunky and arcane. This falls out of doing interception at the library level rather than the language level, I think.
Like what? A chat client that uses 1+ GB of RAM and melts batteries faster than a flamethrower? No thanks!
It almost looks like this Electron/JS trend was started by CPU manufacturers who realised that current CPUs have more than enough power for everyday tasks, and needed a way to create demand for even faster CPUs. I’d say Electron (and JS in general) was pretty effective at that.
> manufacturers who realised that current CPUs have more than enough power for everyday tasks, and needed a way to create demand for even faster CPUs
Lol.
It's a common trend across software. Try comparing office 2003 to office 2013. Office 2003 starts instantly on a modern desktop and uses minimal RAM. Office 2013 takes a good four or five seconds to fire up and uses a few hundred mb memory. And they both do exactly the same thing. With cpu speeds and ssd proliferation there's no incentive to keep things low footprint any more.
Not at this scale though. Office 2013 uses maybe 2x or 3x the amount of RAM compared to Office 2003.
A chat client like Slack routinely uses up to 1GB while a native equivalent would use 100MB or less. We’re talking about a 10x increase here - that’s unacceptable.
Slack is essentially fancy IRC, so we can take any IRC client as a baseline for how much RAM it should really use.
Let’s take HexChat (https://hexchat.github.io/) for example - it does most of what Slack does, plus has advanced features not available on Slack like a Lua, Python & Perl plug-in API. It used less than 100MB or RAM after running for days on a Linux machine.
Slack is usually well into the GB of RAM after running for a few days.
The keyword here is fancy. Hexchat is an IRC client, sure, but it is minimalist. That would be like comparing a text file to a PDF and asking why the PDF needs so much more RAM when they're basically the same.
I feel like you're mutating the argument from "electron uses 10x RAM compared to native apps" into "an IRC client doesn't need to use so much RAM"
The proper comparison would be either a full, feature complete native Slack client with all the same bells and whistles that runs under 100mb, OR an electron port of hexchat with its text only interface that uses 1GB+
Well, I would understand a chat client taking more RAM should I ask it to pare & display some HTML, or videos, or PDFs. I'm not. I'm using Slack just like IRC - 3 users and a single channel even. No images, no videos, no HTML, no link previews, etc. That thing still absolutely melts down my CPU and RAM.
I get what you're saying, but we already know that electron (specifically embedding a whole browser with DOM) is the culprit. There are some native UI toolkits with bindings available for NodeJS, if slack was refactored to replace electron with one, it would probably peak at 2x as much RAM than HexChat rather than averaging 10x to 100x.
100x now? You're saying there are electron apps in the wild using 10GB of memory? I was trying to argue that the 10x claim was an exaggeration but you've just leapfrogged that.
The world's largest computing markets dont use desktops. India and China are 80% mobile traffic. These people have never seen a desktop or a laptop in their life, but use the web and mobile apps with a lot of comfort.
The JS developer ecosystem is very popular as a consequence of the mobile-first ecosystem. And I think it is a great thing that desktop SDK are evolving to be JS first.
I'm currently developing a web app and while my nw.js/electron version is around 50 MB and uses 200+ MB of memory, loading it in Firefox it's a 600kB bundle, fully renders in less then half a second, and uses a whopping 8 MB of memory in Firefox. Actually less the HN! So while I think this project is cool, if you consider using it, also consider making a in browser web app. Also remember that the browser is more then just a HTML renderer. You have stuff like speech recognition, text-to-speech, user input, sound api, 2d/3d api, support for a bunch of mobile sensors like accelerometer, etc.
I think you're failing to include the firefox memory usage in that second example. the 200+MB memory of electron is because it includes the browser. Your 8MB file also needs firefox to run, so in a naked desktop environment the user first has to spin up 170MB+ of firefox before they can run your 8MB app.
But you do not need to have five full Firefox's running for using five web-app's.
Another benefit of web apps, is that with some effort it can run everywhere, where as an app container like electron needs to have separate builds for each platform.
Agreed that's definitely a drawback.
Mozilla had an experimental project called qbrt that was like electron but used the locally installed Firefox, exactly like you're describing. Hasn't been updated in quite a while though
The extra memory usage of electron is a shame.
When you say consider using an “in browser” web app what do you mean by that precisely? Do you mean consider if you can get by using browser based offline/local capabilities and not go outside the sandbox?
See my other comment on rebuilding FF, not sure if you meant anything overlapping.
You would have to run non-sandboxed features via a server, which can run on the user machine! Chrome, Firefox, Opera, IE, Edge supports starting the browser in "chrome"-less or "app" mode, so the program will feel native. You could also run the server part in the cloud! And use "add to desktop" to get the "chrome"-less mode which is currently supported on Chrome and Firefox on Android. Or just run the app in a browser tab :)
I feel like there's room for an Electron variant that's just "less electron". As in, I don't need all of Chrome to do my thing; just the HTML rendering engine and JavaScript interpreter.
The thing that makes it 50gb is all the web sockets and ie4-comparable-iframe-shims that nobody ever uses on the desktop. Lop all that stuff and see how big the install is and how much memory it uses. My guess is it would be a lot less.
I know one of the whole appeals of Electron is the single target, plus being able to take advantage of Node, but I feel like some OS-intergration would be nice. Basically, PWAs for desktop.
On Mac you could have a PWA-like target that is backed by the built in Safari, so all you need to distribute is your app (HTML + JS + CSS) itself and it just uses the OS-provided browser runtime.
That would be cool. It's sort of like the idea behind Firefox OS
I'd welcome optimizations, but do we really care if an app is 50MB, in 2018?
I see a lot of bashing against Electron because of the size and memory consumption of Electron apps, but at least on Linux Electron is a blessing. Many times it's either an Electron app or no app at all, as many companies wouldn't bother supporting Linux if Electron didn't make it so cheap and easy.
With that in mind, with many laptops coming with 128GB of storage and 8GB of RAM nowadays, it it really that big a concern?
Even less for developers: my laptop has 1TB HDD + 256GB SSD, and 24GB of RAM. I can definitely spare 50MB of disk space and 200MB of RAM.
> but do we really care if an app is 50MB, in 2018?
> my laptop has 1TB HDD + 256GB SSD, and 24GB of RAM. I can definitely spare 50MB of disk space and 200MB of RAM.
How much cache does your laptop have? All this RAM usage completely thrashes any caches anywhere. Page caches, disk cache, etc.
Slack alone takes a heavy toll on my laptop. Combine it with any heavy website on FF (which has gone insane on mac since Quantum) and the laptop is ready for take-off.
Not to mention that we are slowly putting a ±$1k price tag on "comfortable computing". People who spend <$300 on a computer are absolutely screwed, even though they have orders of magnitude more power than a device which took humanity to the moon (to use a hackneyed comparison).
I find using developer computers as a measuring stick a painfully elitist perspective. In an ideal world, software developers would be banned from spending more than $250 on hardware. Ever. [for their current workstation]. That would do more to change the face of software than any processor improvement ever did.
> Many times it's either an Electron app or no app at all, as many companies wouldn't bother supporting Linux if Electron didn't make it so cheap and easy.
I agree with this. However, focusing on first order consequences can be deceptive. Perhaps it is precisely the existence of Electron that suffocates any budding competition for more performant but slightly more involved alternatives?
Make WPF-like replacement that works on Windows, macOS, Linux, Android, iOS and their browsers and we will all switch. You are demanding that we all become mega crops with N teams duplicating the same code in with native frameworks and that just won't happen because a) we don't have cash laying around b) users don't know the difference between 10 MB app and 200 MB app, only us do.
> How much cache does your laptop have?
Enough. How much bandwidth does my ram have? Enough that it can fill cpu caches in I don't notice time. I still have 12 year old Conroe with spinning hard disk laying around and it never had any problem running VS Code so there's that data point.
> Make WPF-like replacement that works on Windows, macOS, Linux, Android, iOS and their browsers and we will all switch.
Literally Xamarin.Forms, though without the Linux support still (and browsers, of course, because native apps aren’t web apps).
I dont mind running 1 electron app on my desktop, where battery isnt an issue, but imagine if every app you run all day was electron. How long would a battery last? How much more energy is being consumed across the world because of it? If your making a get-in-get-out type of app, its a no-brainer, but if your making a live communications app, a text editor for professional text enterers, an image editor for artist, that's supposed to run all day, I think its worth considering something more efficient. It'd be a hard comparison to make right, but I'd like to see if electron apps don't undo all the energy saving changes done by chip manufactures.
By my old standards I have a supercomputer on my lap. I want it to perform like a supercomputer. I don't what all that power to get eaten by programmers using inefficient technologies.
In this age of portable devices and the battle to get decent battery life out of your machine, Electron apps strike me as counterproductive. There's more to it then just memory usage, I think.
My laptop is high spec, but each running an Electron app probably reduces my battery life by 20-40 minutes, and if I'm running 3-4 that's a significant drain.
The difference in battery life between Chrome + Slack + Atom at work, and Safari + Sublime at home is huge. Quitting Slack often gives me an hour more battery.
Yes, we do.
Besides, without Electron, we'd have more native Windows apps, and running Win32 under Wine on Linux is still often better than Electron.
>but do we really care if an app is 50MB, in 2018?
What happens when every developer decides user resources are practically infinite, so every application uses as much of everything it wants to all the time?
What does the current landscape of javascript on the web look like? Not exactly a model of efficiency and speed, for more or less that reason.
Not everyone is rich to buy such laptops.
Also I don't know any no technical friend using more than 4GB on their computers.
If it's not a hipster's binary (I'm looking at you golang and docker), yes, we do care.
> I can definitely spare 50MB of disk space and 200MB of RAM
Yeah, once. For a game, or a movie. But not 100 times for utilities I am actively using. Imagine, any given application can be run together with dozens, hundreds of others. Just like any given website is rarely the only website that's open.
Looking towards resources you can waste is the wrong approach. Look for waste you can do without, period.
My question to those who are more informed than me is the following: why isn't the runtime distributed separately, like the JRE? It would essentially allow for smaller apps while keeping the advantages of Electron. It's an obvious thing so I'm sure there are reasons I'm not considering.
Here's a link to the libui library that Vuido is based upon:
https://github.com/andlabs/libui
Both libui and Vuido are works in progress but seemed quite promising and are being actively developed.
So to me, the issue with Electron is that I'm already running Chrome, so I should be able to take advantage of that. In particular, if I have N electron apps, I want 1 Chrome running. I don't want to run certain applications inside the browser, I want the separate app icon, etc. Is there anything that is being done in Chrome/FF to support that kind of thing? That way it's up to the site consumer's preference how they wish to consume the app, by having a native browser consumer and not starting their own little Chrome each time. And for the developer, they're basically shipping "containerized" code around, modulo some features being unavailable in browser vs native, which could be feature detected.
Yes, PWAs. That is how it should be.
“I want 1 Chrome running”
Why? To save a little disk space? There are a lot of downsides to that. Microsoft thought DLLs were a good idea once.
I know Chrome has better isolation but it’s still not as idiot proof and most importantly, as cheap to support as having your own totally independent app.
If a user contacts you with a bug, you immediate know for a fact it has nothing to do with any new chrome update or possible problems chrome may be having and vastly narrow down the problem space.
Given that chrome gives each tab its own heavy weight forked process, it is also pretty irrelevant conceptually. OP didn't explain what advantage he thought he'd get out of it being the same process he already runs other than saving some MB of exe cache. Perhaps that's all he wants.
Either way these solutions are all rubbish.
To save RAM usage and preventing constant cache thrashing.
What would be the disadvantages of just using a custom build of firefox for apps that bundles non-sandboxed libraries as needed?
So for example, firefox.exe could actually be built to be my app.exe, with the generic browser UI replaced with specific app menus.
The build could have options for bundling any library, or provide a simple OS essentials abstraction library with a web sockets or local web server http interface.
It would be a single use custom UI browser “app” with the same potential power as an OS native app but easily portable.
Benefits
- I think FF is a ~50MB download so after stripping out a little generic browser functionality, simple utility apps should be about the same
- One of the biggest problems with these ideas normally is the actual multi-platform deployment can become the hardest part of a cross platform app, yet FF has a polished multi platform install/setup solution already fully figured out and maintained.
This is exactly what Electron / CEF is, except the tooling already exists for CEF, and there’s already a large ecosystem of libraries.
There is theory and practice. similar concepts, but for so long we’ve heard big hassles with electron solution real life deployment solutions (some companies only don’t even deploy electron multi platform, if it were that simple more would).
Also with memory usuage which was mentioned elsewhere in this discusssion.
The idea is maybe it could be done better. On the other hand maybe Electron has made great strides over last year or so, it would depend on how much progress has been made.
Cross platform code is great but in the end doing that while getting something out the door end to end multiplatform as fast as possible is key, while at the same time not having performance significantly worse than it would normally be for the same code in an off the shelf browser.
> Vuido aims to be what Qt used to be, before it became almost as bloated as Electron,
Really?!?
I had to laugh at this one.
Interesting, this reminds me of Proton Native. Both are based on libui.
Proton discussion: https://news.ycombinator.com/item?id=16978901
libui: https://github.com/andlabs/libui
I'm thinking you didn't read the post because the first two sentences are about this being based on Proton Native
Inspired by, not based on, I think.
FTA: "Just like Proton Native, Vuido is based on libui, which is currently an alpha version, but I think that it looks very promising."
That's not the point.
It's a good shift away from the crap that is Electron.js but once we are using a native toolkit, why not use a native language too? ;-)
I think the whole 'hot-module-reloading' thing is pretty compelling, but its possible to do apart from a JS environment (see flutter for instance). The library that Vuido runs on, libui, has bindings to all kinds of languages:
https://github.com/andlabs/libui#language-bindings
Link to repo: https://github.com/mimecorg/vuido
I’m glad this exists, I didn’t want to setup a whole React thing.
There is a movement to use the same tech on desktop as you would on the web, but is anything moving in the opposite direction? Will there be a web version of QT or something? That would be great.
> Will there be a web version of QT or something? That would be great.
There is a Web(Assembly) version of Qt, currently as a technology preview. It's not great IMO, because it's inaccessible to screen readers and other assistive technologies. The lack of accessibility is because the current solution for web application accessibility, setting ARIA attributes on HTML elements, isn't a good fit for rendering to canvas or WebGL. Maybe the browser vendors will provide an alternative. Then again, maybe they won't, and Qt will have to work around that impedance mismatch. In the meantime, I recommend that developers continue developing web applications using web technologies directly.
Yes, see http://blog.qt.io/blog/2018/04/23/beta-qt-webassembly-techno...
Maybe it's because I've done a lot of webapps. But I always found her html/css way easier to use than qt
Webassembly?
I don't use these technologies but looking at the screenshot in the post, it triggers some memories of Adobe's Flex XML declarative UI making. It feels like the same technologies just continue to be reinvented. Flex and Air were gonna be the future everybody was talking about it... And here we are now.
There is also just JavaScript in Qt which is more mature and probably similarly - if not better - performing.
https://doc.qt.io/archives/qt-4.8/qdeclarativejavascript.htm...
awesome. this is clearly an early proof-of-concept but I'll keep my eye on the project. I'm also hopeful for weex (like react native for vue). despite moving from alibaba to become an apache foundation incubator project, it has a long way to go in terms of documentation -- nativescript seems to be winning that particular battle in the vue world right now. it's exciting to see a desktop project come along. vue makes a lot of sense for native apps because its transition engine really lends itself to a "native feel" without a lot of development overhead[1]. great work.
1. https://css-tricks.com/native-like-animations-for-page-trans...
unfortunately being based on libui it is limited to barely be usable. libui does not even have a listbox.
It is being actively worked on, though: https://github.com/andlabs/libui/issues/310
Can't you add it?
I think the coolest thing about this is that it's using libui [1], so whether you're trying to work on Proton Native, or Vuido, or any other flavor of NodeJS-to-Native-GUI [2], we'll hopefully end up contributing to a single library. (PS: libui has bindings to other languages as well [3]!)
[1] https://github.com/andlabs/libui
[2] https://github.com/parro-it/libui-node
[3] https://github.com/andlabs/libui#language-bindings
> NodeJS-to-Native-GUI
I feel I have to find a better name for libui-node
Yes, libui is starting to look quite interesting.
Why don’t I see more “native” applications just running through a locally hosted web server? It’s the best of both worlds: file system access with your server, and a great environment for developing a UI (any browser).
Nice. For those who don't care about native UI : has anyone tried to ship a react-like library used in the OS native browser ? That way you avoid Electron bloat, you just need to take care of the design for different native browsers.
There's this
https://github.com/zserge/webview
Basically a webview which can use a c++ backend and a js/html front-end, cross platform
Confirm me if I'm wrong, but didn't you just invent GTK?
You're wrong. Libui uses GTK on linux, but uses native toolkits on windows and MacOS.
So wxWidgets but in C. I wish it used snake_case (similar to Gtk).
This is a cool project, although I'm starting to not like the look of native apps anymore.
This will hopefully appease the electron haters but I suspect someone will still complain about this being JavaScript
> I'm starting to not like the look of native apps anymore.
Can you please explain why? On which platform, specifically?
Speaking just for myself...I like that Slack has the same look and feel no matter what platform I bring it up on. I prefer a unified cross-platform experience over a unified platform experience. I want my OS to disappear. I am probably biased by regularly targeting multi platform myself.
This causes me to favor other lowest common denominator idioms as well, like python 2.7 over 3, unconfigured vim, bash on windows, etc. When this isn’t possible, I favor technologies that allow me to synchronize configurations across platforms quickly and easily.
you all need mote tk in your life.
maybe it's time for jsTk?
Please no! Tk is inaccessible to blind users with screen readers, at least on Windows. This has been the case for decades.
thanks. Didn't know about that. only made small tools for myself with tk till now.
My main problem with Tk is you have to theme it on Linux and I couldn't find compatible themes for GTK and Qt.
I think, mixing of both technologies is a key to have a really powerful desktop app; just look at Publii app https://getpublii.com
Every comment you've made has been about publii - leading me to believe you're associated with it. HN is supportive of people pitching their products - but I would suggest you disclose your association in comments - otherwise it's just plain spammy.
Yes, you are right. I use and love this app. I'm trying help publii team to promote their product. Their team is just two people, so any help is appreciated, especially that this is free, open source soft. What wrong with my comments? There are only a few and always on the subject. I don't understand your point of view.
Unless they're your competitor and you're trying to make them look bad, this just isn't an effective way to shill a service on HN.
One question: why would you use the awful clusterfuck that is JavaScript on the desktop where you’ve got the freedom to choose from dozens of lovely languages that actually are a pleasure to use?
JS is a necessary evil on the web, but why inflict such pain to yourself when you’re able to use something else?
Why do you speak English when you could be speaking French? Because it's what you know, and lucky for you it's everywhere and you don't need to learn French.
I'm making some assumptions about you as a person but you take my point I hope. People use JavaScript over other languages because they already know it and, hey, look, you can use it anywhere. Sure, it might be more efficient to go and learn python or C++ or assembly or whatever but most people are happier to leverage the skills they already have than go and learn a new language for one app.
I'm a JavaScript coder by profession and in my extremely limited spare time I want to build things, and if i use JavaScript it maximizes my time.
Exactly. People mock me for using Python and MongoDB at hackathons but I have won my first Hackathon cause I spent my time getting code done and not thinking too hard about it.
Exactly. What did you win with out of interest?
I participated in this years TADHack Mini in Orlando:
http://blog.tadhack.com/2018/03/12/tadhack-mini-orlando-2018...
It was a lot of fun and the first time we ever worked with any Telecoms / VoIP companies. Also planning on competing on TADHack Global this time joining forces with another team. Didn't win much since others won as well, apparently you could use all the vendors, we only used one.
TADHAck Global is this year in October for anyone interested: https://tadhack.com/2018/global/
Attendance to hackathons deserves mocking in its own... :)
Can you please explain why? Genuinely curious.
The first two bad things that come to mind: squeezing free time from developers and making hype out of it for peer pressure.
I don't know about that, this one was at the college I used to work at before and I got to mentor two young developers and I continue to mentor one of them. Not everything is as bad as people might think, and some developers work different from others. We saw some amazing projects out of TADHack Mini.
Lastly: Nobody has our code but we ourselves. It really depends on who hosts the Hackathon and the purpose of it. We've heard of businesses being bootstraped directly out of this specific Hackathon.
Also, "you can use it anywhere" really does apply to Javascript in a way that it doesn't to other languages (at least, not until there's full WASM<->DOM integration and a good set of compilers that uses that).
But don’t you believe in using the right tool for the job?
JavaScript is barely acceptable on the web, but again it’s a necessary evil as you can’t easily use anything else.
But why use an inadequate tool on the desktop? The perceived time you save upfront would backfire later on.
Now I’m not saying go and spend a year learning another language just to make a side project (by all means use JS or whatever you’re familiar with), but if you’re making a production-grade app, PLEASE use the right tool for the job and it ain’t JS.
I, for one, am sick of JS & Electron contaminating apps I use daily like Spotify, Slack, Signal, Telegram, etc. I wouldn’t mind it too much if this was a niche thing and there were alternatives, but there aren’t. JS on the desktop should die.
The right tool for the job is very opinionated. Clearly an awful lot of desktop devs think js is the right tool for the job because electron is everywhere and projects like this very one we're commenting on exist.
My opinionated view on "the right tool" comes down to the distinction between foreground and background apps.
I do think electron is not the right tool for the job when it comes to Spotify, because Spotify is something that mostly runs in the background and should be super performant.
On the other hand I use vscode all day every day, and I'm happy for it to use as much ram and cpu as it does because its always in the foreground - it's the main thing I'm using when I use it
Edit: I should add I think we need to find more comparisons to continue this electron debate though. Vscode is always the hero and slack and Spotify are always the villain
I'm there with you being sick of Electron apps on the desktop. The problem is, compared to the JS ecosystem, GUI apps development on desktop with any native technology I know is super bloated, slow and crappy. While I've just started trying to use Elm recently, and the speed of iteration when using it totally amazed me, so that now I cannot longer say that I don't understand why people do that. As much as it pains me.
I couldn't agree more. Ever since switching from Slack to wee-slack I have never run out of memory on my laptop, which used to be a problem every once in a while when running so many instances of electron.
Also Telegram (at least the Linux desktop client) is not electron, it is QT. Maybe some problems that people link exclusively to electron are not limited to just that platform.
I don't really think JS is bad. I actually prefer it to most languages.
It's fast, concise, flexible, and has lots of modern features. It has some weak spots, but all languages do. When people are so ideological about the language it tells me they either haven't used it much or they are unrealistic about flaws in other languages.
> haven't used it much
I actually used it, and hated it quite a bit (although ES6 solves most of my gripes with it).
I understand and appreciate the necessity of JS on the web. JS is also the perfect tool for that job as it’s been designed with the web & browsers in mind, closely tied to HTML & CSS, and while it has overheads those are a necessary evil in an environment where it’s commonplace to execute untrusted code.
But it’s however completely inadequate for the desktop. Your users already trust you since they run your binary Electron wrapper, so the “untrusted code” argument goes out the window. You’re basically taking on an extreme overhead (in terms of battery life and RAM usage) for no benefit at all. HTML/CSS is not that great either, IMO native elements provided by the OS deliver a much better UX and actually behave consistently across the entire OS.
> you’ve got the freedom to choose from dozens of lovely languages that actually are a pleasure to use?
Well there's your problem. If my choice is to wrap my existing SPA in electron in one day vs a 6 month make-and-maintain-a-copy-in-another-language, then I think the choice is obvious.
Then you have a dozen languages to choose from? All of them are lovely except JavaScript? That sounds pretty biased. If I'm going to write a desktop application and take advice from strangers, I need to know that my advisor completely understands where I'm coming from and where I'm trying to go. I don't want to get burnt because a hater is trying to give me unthoughtful "literally anything but" bad personal vendetta advice thinly vailed with technical concern trolling.
Then I have to pick one of 12 languages? I don't need "well literally anything but", I need a well written set of tutorials and/or case study demonstrating that one option is superior to JS and is written to bring JS devs to an understanding of if the tool being presented is what they need to use or not.
Normally I would agree, but GUI development with Vue is such a lovely experience. It takes advantage of many of the newer JS features to make this possible (automatic data binding via property get/set interception, for example). As a consequence it's hard to imagine providing the same in another, better language.
.NET has been doing it since 2008.
Is this something that's had good crossplatform support since 2008 or more recently?
No, it is something that has been doing "automatic data binding via property get/set interception, for example" since 2008, so it is easy to see it in an language that isn't JavaScript.
Additionally, Xamarin is older than VueJS.
Yeah, I've worked with XAML and such in .NET-land. DependencyProperties are nowhere near as painless and transparent as the state of things in Vue. Doing computed propeties, trying to use converters in a sane way, setting up templates for repeated items - all quite clunky and arcane. This falls out of doing interception at the library level rather than the language level, I think.
It would be a bigger deal if it was not windows only.
Xamarin never was Windows only.
And Mono was a thing before .NET Core came into the scene.
ES6 (or 7) is a much better language than a bunch. Adding in the types through flow or typescript, and now it's a pragmatist's heaven.
Incredibly pragmatic, which is perhaps the most important thing possible.
an approach that assesses the truth of meaning of theories or beliefs in terms of the success of their practical application
You can have your ideal language, we'll just keep building great stuff in a good enough language.
> Great stuff
Like what? A chat client that uses 1+ GB of RAM and melts batteries faster than a flamethrower? No thanks!
It almost looks like this Electron/JS trend was started by CPU manufacturers who realised that current CPUs have more than enough power for everyday tasks, and needed a way to create demand for even faster CPUs. I’d say Electron (and JS in general) was pretty effective at that.
> manufacturers who realised that current CPUs have more than enough power for everyday tasks, and needed a way to create demand for even faster CPUs
Lol.
It's a common trend across software. Try comparing office 2003 to office 2013. Office 2003 starts instantly on a modern desktop and uses minimal RAM. Office 2013 takes a good four or five seconds to fire up and uses a few hundred mb memory. And they both do exactly the same thing. With cpu speeds and ssd proliferation there's no incentive to keep things low footprint any more.
> It's a common trend across software.
Not at this scale though. Office 2013 uses maybe 2x or 3x the amount of RAM compared to Office 2003.
A chat client like Slack routinely uses up to 1GB while a native equivalent would use 100MB or less. We’re talking about a 10x increase here - that’s unacceptable.
Have you sources for this 10x claim? Do you actually have a native slack client that uses 100mb because I'd love to see it.
Slack is essentially fancy IRC, so we can take any IRC client as a baseline for how much RAM it should really use.
Let’s take HexChat (https://hexchat.github.io/) for example - it does most of what Slack does, plus has advanced features not available on Slack like a Lua, Python & Perl plug-in API. It used less than 100MB or RAM after running for days on a Linux machine.
Slack is usually well into the GB of RAM after running for a few days.
> Slack is essentially a fancy IRC
The keyword here is fancy. Hexchat is an IRC client, sure, but it is minimalist. That would be like comparing a text file to a PDF and asking why the PDF needs so much more RAM when they're basically the same.
I feel like you're mutating the argument from "electron uses 10x RAM compared to native apps" into "an IRC client doesn't need to use so much RAM"
The proper comparison would be either a full, feature complete native Slack client with all the same bells and whistles that runs under 100mb, OR an electron port of hexchat with its text only interface that uses 1GB+
Well, I would understand a chat client taking more RAM should I ask it to pare & display some HTML, or videos, or PDFs. I'm not. I'm using Slack just like IRC - 3 users and a single channel even. No images, no videos, no HTML, no link previews, etc. That thing still absolutely melts down my CPU and RAM.
I get what you're saying, but we already know that electron (specifically embedding a whole browser with DOM) is the culprit. There are some native UI toolkits with bindings available for NodeJS, if slack was refactored to replace electron with one, it would probably peak at 2x as much RAM than HexChat rather than averaging 10x to 100x.
100x now? You're saying there are electron apps in the wild using 10GB of memory? I was trying to argue that the 10x claim was an exaggeration but you've just leapfrogged that.
That's what Vuido is for, now there's no Electron.
ES6 an typescript are wonderful languages and have little resemblance to the jquery-esque JavaScript era.
Think C# rather than jquery.
But you could just use C# instead on the desktop, and be happier.
The world's largest computing markets dont use desktops. India and China are 80% mobile traffic. These people have never seen a desktop or a laptop in their life, but use the web and mobile apps with a lot of comfort.
The JS developer ecosystem is very popular as a consequence of the mobile-first ecosystem. And I think it is a great thing that desktop SDK are evolving to be JS first.
Are there good cross platform UI solutions in C#?
Xamarin.Forms and Avalonia.
Avalonia has no accessibility support, so it's unusable for blind people via screen readers, among others.
Yes, it is very important, yet unless it is a government project, it gets ignored by project delivery acceptance requirements.
Stockholm syndrome?