It is totally me, seeing as how many electron projects there are, but I have never been able to make anything with it. Not even a POC, I have found it very complex.
Also check out nw.js which is like Electron, but you start in browser context instead of node.js context. Also consider running a node.js server and launching existing chrome with chrome --app=http://localhost or iexplore -k http://localhost
Agreed. I think NW.js is great (https://github.com/nwjs/nw.js). Especially the binary blob feature which can be used to compile JavaScript to V8 bytecode, and obfuscate portions of your source for security purposes.
I've read a tutorial that creates a small desktop application using nw.js and vue, and the package size was 233 mb. This made me decide to use Electron after all.
If you have a working website it takes like 5 lines of code and random electron guide to actually do a POC. If you want to have a standalone APP, you need to have locally working SPA app. That requires rather deeper familiarity with current JS build stack.
Given the React Native for Windows talk at BUILD 2019, and their comparisation how it beats Electron, how Office and other teams are now adopting it, I still hope VSCode will eventually join the party.
They even did a nice graphic.
With UWP C++ being the reference point of 100%, UWP C# gets also 100% (thanks .NET Native), React Native 180% and Electron goes sky high above 700%!
You got me there on GNU/Linux support, which doesn't mean it will not come later. They just need to decide which flavour of Linux desktop one is supposed to support in React Native.
That's my impression too. It seems like a lot of the "native development is hard, so I use Electron" have never once used native C# with Visual Studio.
Or they might not have the bandwidth to deal with n different builds. I've written UIs in native motif, x, mfc, Android, and iOS, but with modern HTML & CSS (especially in the last couple years with flexbox, grid, canvas, svg support) and TypeScript it seems like there's new goodness daily.
That said, I'd love a divorce from Electron if something else would give me a system tray, node runtime, and seamless upgrades, supported cross-platform.
With Electron runtime you can just write a text file on any of the supported platforms and you have a working, running desktop app. No compilation needed.
No need to install SDKs, deal with builds, project files, etc.
I don't think it's very complex. Only look at the target users! :-)
Jokes aside, lack of basic code protection (aside of script minimization and/or obfuscation) it's that prevents me from using Electron/Atom/whatever. I know anyone could decompile a C# application easily, but I find the javascript case worst.
Do you know any commercial applications using any of these solutions? (I'm speaking of shareware / paid software, not "Whatsapp desktop" type)
It's a desktop GUI for Git, along the same lines as Sourcetree. They've added stuff over time like various paid integrations and apparently a Kanban board, but it's always primarily been a Git GUI.
Mailspring is another one I can think of. It's a free email client that offers extra features for pay.
PhotoStructure for Desktop runs on macOS, Windows 10, and Ubuntu Desktop, is packaged with Electron (I'm alpha testing 6.0.0 today), and will be commercially licensed when the closed beta ends.
I'm also preparing a PhotoStructure for Servers build that is electron-less, and uses either docker or snap (it's how I run it on my NAS). I'm looking for more beta testers for this headless build, if you're interested.
Thank you. How do you cope with the code being visible inside the application drectory?
About PhotoSctructure:
- Great application idea, sincerely. My photo library is a big mess and this sounds super handy.
- May I recommend another icon? I find strange that PhotoStructure "for Desktop" has a cloud in it's icon :-)
- Regarding being a tester, thank you, but my current file server is a very stripped down debian box right now (Fujitsu Futro S900).
I have a hobby project in Electron but agree, the forced separation of "main" and "renderer" processes with multiple methods of influencing each other (ipcMain/ipcRenderer, remote, webContents.executeJavascript/send), and the further splitting of the renderer process into multiple similarly-named substructures (webFrame, webview, BrowserWindow, webContents) is a lot to get one's head around right off the bat and make stick, especially if you're the sort who wants to survey and disambiguate all the facilities of the platform beneath you before starting to code, rather than just trusting tutorials and tweaking code snippets towards some degree of satisfaction if and when they 'just work'.
On the Rich Hickey "simple vs easy" scale, Electron is very much leaning to the "easy" side.
Here's a very simple and terrible example. Nothing happens except the time is updated every second in the render process. This runs at 90.3 MB RAM usage on my machine and builds to 165.7 MB.
It's about as bare of a reference as you might find. Have at it. (Also there's no Readme, just consult the package file. I only threw this together when I was finding my way around it this spring)
If they're using old PCs running deprecated versions of Windows then they long ago stopped caring about resource usage and efficiency (energy usage and operator time) and are instead optimising for hardware cost. It's no reason to favour this or that platform for development.
I imagine a big reason that they're on old hardware is cost - just because it's relatively cheap for someone in the West to get a decent modern machine at a reasonable cost doesn't mean that it's the same everywhere, especially when there's big disparities in the purchasing power of the native currency vs. the sellers/manufactures currency. It's not so much an optimization, I imagine most users on legacy hardware don't choose to be, it's more likely that they can't afford more modern hardware or it isn't available for them to purchase.
Another huge reason for users to stay with older operating systems (especially in business and government) is dependencies on legacy software - if an organization relies on software that has never been updated after Windows 95/XP and doesn't function on later versions then they're going to be stuck using legacy machine configurations until the process can be changed to something else.
> stopped caring about resource usage and efficiency (energy usage and operator time)
How do you know that they don't care about how efficiently they can use a machine for whatever they're doing? It's a baseless assumption.
Even if your user percent that's stuck using older hardware/operating systems is in the single digits, that isn't an excuse to ignore their requirements IMO. Doing so is a sign of sloppy engineering, akin to designing a new mode of public transport, for example, that doesn't cater for disabled people.
Also most apps are not the only app running on my system. I might have 16Gb, but I'm currently running multiple browsers with multiple tabs each, a PDF viewer, a spreadsheet application, a music app, an IDE, multiple terminal windows and a search program (Everything).
Spotify manages to use only ~150MB. If it tried to use 1GB I would replace it since I have more important things competing for my limited RAM.
Almost two years ago I have created app (using Electron) that takes xlxs template and data files and generates bunch of xlsx files [1]. It was Electron 1.7.8 and now it is 6.0.0. I guess I need to check it out again.
Every time I hear about Electron, I have mixed feeling about it, is it :
* one the best thing that happened to desktop software as it enable web developers to build desktop portable app
* one of the worst thing that happened, because it makes the desktop world rely on Google and decrease even more the expectations on how much resources an app should consume
Imagine if desktop developer wanted to go into web development. I assume he would learn HTML, CSS, JS.
Why cannot web developers wanting to create desktop app learn new languages and SDKs?
I've spent many years as a web developer, and a bit fewer years as iOS developer. Now I am back with web again, but I still thing way too much of the recent trends are being optimized for the developers at the cost of users.
The main thing that Electron does is solve most of the platform abstraction issues. The only contender that comes close to this is Qt.
However, if you want to hire Qt developers, that's a much smaller pool and then you also need to pay Qt license fees for each one.
If you want to develop truly native applications, now you need to maintain builds for Windows, Mac OS and perhaps even Linux. You need developers familiar with all of these native frameworks.
Optimizing for developers isn't necessarily worse for users, if they can get more done in less time, users benefit. It's just not so obvious. No user will ever complain about a product they aren't using because it won't ship until next year with half the features.
Yep, paying just gets you extra Qt features and allows you to make the whole application closed source. The community version requires you to keep the Qt portion of the application under the LGPL, but you can still keep the rest of your application closed source and just link agains the Qt code.
Thanks to Electron I was able to build an app for Win, Mac, & Linux. Had there not been electron, my app would be only for Windows and no one else.
I strongly suspect I'd never be able to bring the level of polish I could with HTML & CSS to the UI through the standard SDKs -- so the resulting app would be a much worse user experience as well.
The amount of time I'd have to spend learning a new SDK would basically put me off, and I'd likely never have created this app.
Instead I have over 700 people who have purchased my app (~2 purchases per day over the past half year) - https://videohubapp.com/
Sorry for using "never" -- certainly I could spend a lot more time learning the tricks that could get me close.
But UI is not essential for a functioning app, and if the time costs of building a good UI are too high (a lot of new learning and problem solving) I'll spend less time on it.
I think he's referring to this sample (https://doc.qt.io/qt-5/qtdoc-demos-photoviewer-example.html) - replace Image by VideoPlayer, tweak the ui, make some menus, add a few interactions and you're good to go from what is visible on your screenshots - were I still a freelancer I would maybe have quoted two weeks for that ?
That's a Qt Widget example, you should look at Qt Quick for a way to build more modern-looking interfaces. With Qt Quick user interfaces are described in QML, a declarative markup language, and you can write most (or all, if you want) the business logic in Javascript. See for instance:
(Edit: by no means I'm saying that your work is trivial to replicate, apologies if this comment came across like that - just wanted to point out that there's more to Qt than Qt Widget.)
Thank you for the direct link. Over the years I've glanced at Qt, I've been discouraged by the amount of work I'd need to do to accomplish even trivial things that I can with HTML.
The original reply I made was to point out that startup costs decrease number of people starting. Unless you know Qt already, your first project will take much longer than using technologies you already know. It's not at all clear how long learning would take.
I know I can climb the mountain, but I'd rather not. This isn't to discourage others from doing it, it's to explain to those who don't understand why many people prefer to stick to Electron.
They're dismissing your work as trivial because there's a sample that does the first 1% of what it takes to build, polish, sell, and support an app that people actually use. Same kind of person who thinks all the projects that died in their ~/Code folder are "almost done".
Based on other things MS is doing, it tells me they're hiring a lot of young developers who only know web tech and don't give a damn about the user experience.
That isn’t how big companies work. The decision about what to use is up to the 5 or so developers working on an app. Microsoft doesn’t force specific languages or frameworks across all of their devs, and the native SDK devs are working on their own projects.
You understand that many Electron projects are FOSS, right? I understand what you're saying about optimizing for development rather than users, but if Electron didn't exist many of these projects wouldn't exist. If you see a project that you feel would be better as a native app, why don't you build it and release it as FOSS?
@dang should start stickying his comment with links to every previous Electron release submission for people who want to replay all the belabored arguments (dismissals) again and again.
The latter, I have a 3GB laptop. Almost any application I use that is electron makes my laptop scream for help (fan spinning furiously) and freezes it up.
I have to kill the application before it consumes everything.
Electron applications like VS Code are an exception and slightly gives me hope.
I can't speak to VSCode, but I've been probably a hard use case for Electron development as I work in an industry without a ton of resources to throw at development, limited time, and less supportive environment for development (in spite of a pressing need to keep up).
I've found keeping as precious little of the work in the render process as possible has helped a great deal. Send everything to the main process and use the event/messaging system to update the state. Then things that you're used to doing to maintain application performance in a web browser apply. Keep the compute in the back as much as possible.
And depending on the task, offload compute to a native module [if you're capable and] if the expense between NodeJS <> native module is worth it (more intense compute tasks).
There's probably more and more experienced advice out there, but this is my experience so far.
It’s likely just sheer difference in quality of engineering. For most companies that choose Electron, performance was never of any value in the first place and that’s reflected in the engineering regardless of how/what it’s written in. It just happens that bad code is much more egregiously bad with JS/Electron than with other stacks.
That Electron fad will eventually die as HTA and XUL did before it.
With my Web developer hat, I see the future as PWAs and if you really need more than Web APIs allow, by all means create a local daemon that uses whatever browser the user has installed.
All my uses of Electron are forced upon me, if native versions are available and I am allowed to choose, native wins.
PWA is the opposite of what I want. I want signed packages/manifests with well defined content (plus binary transparency). Not each application shipping its own downloader code which caches an ill defined set of files locally.
It's great tool for personal use, to write quick single purpose UIs in webtech that can access DB directly, without the need to write the backend or much with REST APIs.
For personal use, you also don't need multiple runtimes for multiple electron apps. You can just use the single shared one (or even system one; for example archlinux has electron installable via pacman), reducing memory use.
It's also pretty good tool to write your own UI for other people's websites.
I once drove a huge refrigeration truck across Australia. The full cooling system was running all the way, although storage was howlingly empty, save for twenty liters of drinking water, kept there because the fridge in the driver's cabin had broken down.
I love that analogy. The fridge in the driver's cabin is a web widget in a traditional toolkit, for instance https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-markdown... The large cooling system which requires a substantial amount of fuel is Electron.
Can anyone suggest a software niche where Electron has not be used so far?
Here is one I think: 3D printer slicer, to my knowledge there is no slicer which uses electron I think it limits the contributers who can quickly deploy plugins in JavaScript
For slicers there is https://pathio.xyz. Not fully Electron though, which is probably a good thing..
Edit:
https://pathio.xyz/hello-world
"Pathio is built on a mixture of modern web-technology (Electron) and a powerful native slicing engine (written in
C++17)"
It's kind of interesting to see this release and previous ones mention 'performance fixes' (V8 and Blink does all the work) that it brings, yet the job postings for desktop software engineer requiring Electron experience also put data structure and algorithms and what I see here is a runtime that is very expensive in both space + time complexity. It makes no difference in using a different language with a faster runtime to combat this.
Imagine if I were to write a 'next-gen' CAD program or an alternative 3D modeling program in Electron. I'm not so sure if the manufacturing or the games industry would take a second look at that. But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time.
Can't we do better than this? Or do we have to accept and depend on Google to create our desktop software?
There are better alternatives, in almost every possible way. The problem is they aren't that popular. And you can't reuse code (and coders) with web version of your app.
With CEF you can write your business logic in a better language, but the UI suffers from the same problems as Electron since it's basically the same thing.
Among the easiest and best supported is Qt. I think Flutter is also going to serve that space decently well (although in a more Electron-like fashion, meaning no/barely any integration into the platform-specific UX, while Qt imitates OS widgets).
A good manager will ensure everyone has actually read Filthy Rich Clients, is aware of Swing theme component libraries and never does IO on the UI thread.
And for bonus points, that the team gets hold of an Java AOT compiler to native code.
Is it really that much worse than HTML, JS, and CSS? The DOM is generally a mess and CSS isn't easy to use.
Of course JFX is probably a better option now days but for a small GUI if you avoid layout managers like GridBagLayout (built to work with a WYSIWYG) and you are on the JVM seems like an easy option to me
How do you make a good looking app with Tk? I know about Tile and Ttk, but how can I even trust those when the Windows look and feel they mention is that of Windows XP? Launched in 2001, abandoned by Microsoft in 2014 (!)
I wouldn't base any commercial product I'd make on Tk, if it was meant for a large audience. Internal tools where you get to tell you users: "shut up and use the ugly app cause management already paid for it", ok, there you can use it. Otherwise... no.
Ask people off the street instead of HN developers who like to pretend their undesigned weekend project looks good just because it almost works, and you'll find consensus more common than you think. Or even better, how unanimous the consensus is on what looks like shit.
Imagine if I were to write a 'next-gen' CAD program or an
alternative 3D modeling program in Electron.
I'm not so sure if the manufacturing or the games industry
would take a second look at that
Could be possible if electron was only used for the GUI, and the core of your app would be a C++ chromium widgets. Do it!
The ease of providing a styled user interface. In the 2000s, this was something everybody wanted to archive, the term for it was "rich user interface". Already back then, embedding a HTML widget seemed an easy way to archive that.
It's pretty hard and has a lot of problems. It's definitely not as easy as css and doesn't have as many options for styling. Sometimes, when you change one property, 5 other unrelated properties will change as well, and you need to manually set them. CSS is much easier to get a consistent theme for an application.
> You rely on Chromium which is battle-tested and have frequent updates
Chromium has been battle-tested and was wounded severely. Embedding it in your application will not automatically add the regular security patches to it.
Imagine reading the sentence: "Imagine spacex building a rocket with cheap plastic. Why us working in the disposable fork industry are still using this crap material!". And then you realize that this comment gathers a lot of support from the disposable forks engineering community.
Time to deliver new features matters. Skill reusability matters. This is the economic reality that makes electron attractive to all the people that decide to use it to build software.
The alternative to electron is not always a leaner different framework. It may also be not building software because you don't have the resources and skills needed.
I think that is something that tends to be underestimated. The reason Electron is popular is because of the success rate in creating things. While projects that are trying to be better takes far longer or fails outright, making them less common. So it isn't necessarily that people are choosing so much as surviving.
That might be the case economically, but this isn't the future that I or end users want, look where this has gotten modern desktop development, you now have sluggish, slow, bloated applications vying for end user's resources.
e.g. An end user using Discord and Slack has to download 2 Electron applications (~500MB of disk space) and this is for a chat app, Ripcord [0] can do both with less RAM resources and disk space.
> The alternative to electron is not always a leaner different framework.
You can have both, there are newer frameworks popping up such as Flutter, React Native and Reason Native.
> That might be the case economically, but this isn't the future that I or end users want
It might not be the future you or I want, but it is the future that the majority of end users want. Market forces don't always work for getting users what they want (see privacy) but in this case the money is talking. Slack's desktop app is a classic example of being a memory hog, but Slack has been enormously successful.
"want", for sufficiently well-chosen values of "want." ;-)
Every time you hear someone complain about how their new PC is so slow to do $trivial_task, think again. Most users unfortunately don't know any better, nor have the inclination to teach themselves to.
This reminds me of the 'dir' test my friends and I used to gauge computer speed in the DOS era. Listing directories was so common its speed was easy to notice and compare to other machines.
Modern OS's don't really have an equivalent to that. Probably because usage has become more fragmented.
A regular user certainly isn't going to say "I want my Slack app to be built with a lean framework that uses less resources". But they very well might say "It's really frustrating that my new computer is so sluggish all the time", without knowing why.
There seems to be an opportunity here for platform vendors like Microsoft or Apple to be a bit more aggressive about "this application is what's slowing you down" notifications. (With the ability for the user to say "yes, I'm editing a 4-hour movie, don't warn me about this app again".)
Don't Apple already do something similar for battery hogs? May be misremembering, but I'd have thought a similar principle applied.
Half the challenge of course would be dissuading the vendor from excluding their own apps from these notifications.
> There seems to be an opportunity here for platform vendors like Microsoft
> or Apple to be a bit more aggressive about "this application is what's
> slowing you down" notifications.
Once I wanted my desktop's features in a phone. Now I want my phone's features on my desktop.
Microsoft did something similar for every browser that wasn't Edge.
But yes, on OS X, the battery drop-down will list any apps that are consuming significant amounts of energy. For me these are constantly Chrome and Intellij IDEA.
I can't say about you, but your claim about what end users want is quite strong. End users want all the features (including performance) for free and then pick the currently available option that looks best suited for them.
I didn't say that there are no other frameworks. The ones you provided all break the "transferable skill" requirement (React native a bit less so but still).
If you prefer to install ripchord instead of discord and slack nothing prevents you for doing so. Let me write a few comments about it:
- it made sense building it for the author because those two services already existed and already had enough users. Also the author has the skills needed to build it.
- it won't be free
- it is not feature complete compared to the reproduced services
So it might attract users depending of the perceived gain from a faster software vs its price and the missing features. It also has to win over all the people that have already installed the slack & discord clients. If it gains significant market share there are 2 risks: intentional api breaking changes by slack & discord, and them redoing/optimizing their client to win back the lost users. Most probably: they don't care about the client part. They are selling a service and this new client might make some of their users happier.
So we see that even though ripchord exists, it does not mean that electron hasn't helped in making two new services available. The ripchord author might be able to reproduce a client with a better tech, but that doesn't mean he has the skills to create a whole new offer (market research, sales, backend administration, etc).
I am not sure what do you even mean by that. I am not talking about lazyness. I am talking about opportunity cost. Learning an application framework takes time. There is the language, the api, the architecture best practices, the design processes. You might want to learn about accessibility, responsiveness, cross platform issues, software packaging/distribution/update management.
If you skim a tutorial and release an unmaintanable mess because you lacked experience with your tools users are not going to forgive you because thank god you did not use electron.
You might have some time to learn all this. Or not. Maybe you are busy finding funds. Maybe you are pitching companies to get your first prospects.
There is a world beyond people who throw their notebook into the trash after 3 years. There are still plenty of users with 128 GB or even 64 GB. Now imagine Windows taking 30 GB out of these 64 before you even start installing any apps. Those people absolutely care about 500 MB.
You can, today, walk in to a Best buy and buy a Windows 10 machine with 64 or 128gib mmc. You can buy them in most US department stores and people do buy them.
I do. Not necessarily because of dick space but because this bloat on applications with rather limited functionality usually comes with being memory hog, sluggishness and otherwise unpleasant experience.
My main laptop has 4GB ram. I cannot afford to use 500mb for a chat app. Beside, did you even go outside? A lot of people cant afford (or dont need) a computer with more than that. For example lets see in a community where having a lot of ram matters. In the Steam Community, around 12% of people have 4GB or less. https://store.steampowered.com/hwsurvey#cat0_stats_row
I'll turn that question around. Wouldn't it be nice, not to mention cost-effective, to be able to do an office job on a Raspberry Pi? Fifty to seventy bucks a head, all in, and you have a machine that was plenty fast enough 15 years ago. When you commit to giant apps, you commit to hardware that costs twenty to fifty times that amount.
If you need more power, that's fine. But does an administrative assistant, or a lawyer, for that matter? Give me old-fashioned desktop applications, and I can compete with you at hundreds to thousands less per head. How many people doing that does it take to make a software engineer's time worth the trouble?
This is what I tell people who post "See what I made" when it's written in Electron.
I don't hate Electron. I just won't trade _my_ limited CPU, memory, and bandwidth for _your_ inabilility to learn Qt. Your Qt using competitor will get my business.
This is a valid opinion but a bit extreme as is. If the competitor lacks some features that would save you days vs a few minute of execution, you are trading your limited CPU, memory, and bandwith for your (unlimited?) own time.
Qt apps break all the way to being unusable on my windows system when plugging in an external display or RDPing to the machine. I use Kleopatra, Electrum, Qbittorrent, VLC, they all have scaling issues where the text and icons does not scale correctly with the buttons and other components.
Is your external display a much higher dpi than your built in screen and are we basically talking about desktop OS being shitty about handling mixed dpi?
External display has a lower dpi. I don't know if it's the OS or something else but it only happens with QT apps which makes me avoid them if possible.
As ripcord is only free during the beta period, I don't think you'll find many "end users" who would want to pay for it. The vast majority of Discord users being Gamers with big disks and plenty of RAM.
Maybe some of the more technically inclined Slack users might consider switching, if they find the alternatives aren't missing too much functionality
> NOTE: Revery is a work-in-progress and in active development!
Recreating all widgets is a huge task and such a framework needs a lot of dev momentum behind it to be usable in production. I really like everything Revery promises but right now it's just not an option for anything beyond simple apps for personal use.
Disk space has increased by orders of magnitude. Downloading an additional 500MB Of stuff seems like a completely worthwhile trade off for me if it means that the application I’m using is supported on Windows, Mac, and Linux, as opposed to the previous situation where uTorrent was a Windows only app, Transmission was a MAC only app, and then after many years they came over to the other side but with half baked functionality, and no where in there was a Linux option (or if it did arrive, it was even later). Compare that to Slack, or VS Code, which were available on Windows, Mac and Linux almost immediately, all while maintaining feature parity.
Average machines in 2006 were mostly desktops with hard drives of 80/120/160GB. Average machines in 2019 are mostly laptops with 500GB/1TB of storage in many cases much much faster ssds. This is less than one order of magnitude in the last 13 years. I personally would like to use that extra space for useful tools and multimedia not bloated chat apps.
uTorrent is perhaps another bad choice.
uTorrents first public beta release was in late 05 Qbittorrent was released in early 06.
By the time about anyone was aware of uTorrent Qbittorrent was already a thing and as good. uTorrent went on to become first proprietary and ultimately ended up installing malware on users system and mining coin whereas Qbittorrent is still awesome.
Slack with its famously crappy performance and battery destruction is probably another bad choice to make the case although I hear its improved lately. Maybe wait another year to use it as an example so people have time to forget how much it sucked.
I would totally stay with comparing say visual studio code to visual studio and hope your audience doesn't remember Emacs and Jetbrains products are also cross platform without electron.
I don't know if it's improved, or if it's just my newly-acquired fast computer, but PyCharm (JetBrains with a Python sock puppet on its hand) has been pretty great, at least for the smallish projects that I've been working on.
Jetbrains is paid and has probably a larger team behind it. Building those cross platform desktop apps is the business model of their company. Of course they should pick something else than electron. They hire developers that will have the java skills needed to build it.
I wouldn't say that emacs is a shining exemple of desktop UI. Everything is based on text buffers and keyboard commands. I don't see this type of application getting the same scale of adoption as vscode or slack (and this comes someone who has used emacs as an editor for python and org mode files for 3 years).
I agree with you, but man oh man I have not had a good time with react native. We made a tiny little mobile application in it, and due to various libraries exploding with every minor release, I wound up spending hours upgrading and patching and screwing around whenever we needed to add some tiny feature, which inevitably required some kind of update. I don't know if I just got unlucky with my choice of packages, but it's soured me to the whole platform.
End users do want it as seen by the commercial success of Electron based products, including completely free products like VSCode even when Sublime and Visual Studio exist.
Features and functionality almost always overrule performance. I'd rather wait a little longer to do something than not be able to do it at all.
You're absolutely right, electron won't die until something better exists. Not something better in terms of performance or technical debt, something better in terms of quickly bring a cross-platform gui to market.
This is the old problem: the middle manager can wave a sheet of paper around saying, "my team used an agile electron methodology to disrupt the plastic fork industry!" or whatever, and get rewarded. He cannot, however, explain that by using something else, he saved long-term technical debt, maintainability, etc. because those costs are not immediately visible.
I'm kind of hopeful for flutter. God willing, it will solve our problems...
The difference is that Visual Studio 2010 was buggy as hell and is still a better option than... Honestly, every editor I've seen used on JS. It mostly stayed out of the way. It didn't hang when I moved the mouse, for God's sake. I think OP's point is that we're suffering needlessly, which is hard to refute when there were better options around nearly a decade ago.
It's worth mentioning that this madness is mostly an issue in the JS community; everyone else is getting along just fine. And, as with npm, react, angular, electron, etc. etc. the JavaScript programmers act like these issues - already solved countless times elsewhere - are universal constants.
actually game industry are adopting the web like desktop app (in launchers and other client parts (events, etc) using CEF for example).
Web tech is highly dynamic and gives you the ability to change your product very quickly, deliver the value and it is quite cheap in comparison to c++ analogs.
> CAD program or an alternative 3D modeling program in Electron. I'm not so sure if the manufacturing or the games industry would take a second look at that
Why not? Onshape is browser based, and quite a few mechanical engineers and the 3D printer community seem to be happy with how well it works.
Something like Electron isn't primarily for CAD programs or 3D modeling, it is for "information" applications. That is what many millions of dollars have gone into developing and educating people about web technologies.
> Can't we do better than this?
Honestly the answer is probably no. People just don't understand how much work goes into something like this. Who is going to, or even can, spend the time and money to do it?
Mixed feelings about this. On one hand, I've used to work for a company that made software that processed models for 3D printing, and optimizing internal memory structures was an important part of it, as big modes routinely hogged all the memory on our own workstations.
On the other hand, one of the biggest competitors outright states thet their software needs 16gb+ of RAM* I guess Electron wouldn't make much of a difference.
But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time.
I attribute this mainly to the younger generation of developers, most of whom have never experienced computing with fewer resources, nor have any idea of the amount of resources something should take. That can partly be blamed on education and the "premature optimisation" argument that still gets thrown around as a random excuse to do something terribly inefficient.
When a team is short on developer time and code readability is paramount, premature optimization can be a hindrance. But like most things in life, the truth is in the middle: teams should strike a balance between competing priorities rather than throwing around the premature optimization argument.
This is such a boring argument that both enforces gatekeeping, and lacks any idealism about the future of our industry.
Perhaps CPU speed/memory is not quite there yet for Electron to be viable in most projects, but nobody is taking away your ability to fiddle bits. Why does it have to be one or the other?
A JS developer can get access to writing their first 'native' client. If it is too slow, perhaps she will investigate a more memory efficient way. Or perhaps its good enough for the current use case.
Some paradigms will be dead ends, but experimenting with higher level languages and libraries is what moves us forward.
It's equivalent to kicking and screaming in the late eighties that this 'Python' is not efficient and a waste of time.
I know it’s not your main point, but python wasn’t a thing until the nineties (released in 1991 if I trust Wikipedia) and would have been almost always not efficient and a waste of time and resources at that point in time given the state of hardware (also considering that python wouldn’t have been the optimized version that it is now)
At work, I have a very powerful computer because of resource hogs that work makes me use (Rails, Webpack, React, McAfee, Slack, Windows).
My private computer is much less powerful, but still runs noticeably smoother because I don't put any junk on it.
(I cannot, for the life of myself, figure out why applications on Windows cannot play audio consistently without jitter. Might be McAfee or some other corporate shit.)
It's not windows. If you stop everything from running on startup (which means looking in 6 different places) and your CPU is being cooled well, windows itself can run very smoothly.
> I attribute this mainly to the younger generation of developers, most of whom have never experienced computing with fewer resources, nor have any idea of the amount of resources something should take.
I attribute this to the older generation of OS developers and project managers and CEOs, who have not offered easy to use, powerful tools to create cross platform applications.
If the programming language is not memory managed, it doesn't matter (so anything C or C++ based is out).
If it's not cross platform, it doesn't matter (Win32, WPF, Cocoa, etc.).
If the priorities of its developers keep shifting, it doesn't matter (Qt from the old Qt widgets to the new declarative ones).
If it doesn't support high DPI or responsive design, it's out.
And I say this as a middle-aged developer, my first PC was a Pentium 1 and I've also used home computers from the 80's.
The incentives for OS creators are to create walled gardens. Which they've done successfully. But because of that, they can't also bitch and moan about "slow cross platform applications" when they do everything they can to kill or hinder cross platform stacks.
2. As time went on, the value of powerful, cross-platform tools and platforms became more obvious.
3. Since this was later in the evolution of the industry, the people who made it happen were a different generation that didn't prioritize efficiency.
That is to say, perhaps there's no fundamental reason you couldn't have the nirvana of efficiency and portability (best of both worlds), and it's just that no community of developers has actually aimed for that.
Maybe we can, maybe we can't. Regardless, no one has done it.
I'm still holding out on a ReactNative-like solution for all platforms, independent of language. Eg, some type of RPC bridge is opened between a process and a window, and it creates native widgets for each proper platform in the same way ReactNative does; except with no care for the originating language that the process is written in.
Not while priorities are inverted. Right now, the priority is not on the end user so much as it is on developer productivity and iterating as fast as possible.
This is an inaccurate model. As an end user, I want the developers to be super-productive and iterate quickly so they can add the features I want. The priorities of end users are what you dislike. We choose "this has the features I want" over "this is lean and snappy".
There are lean and snappy text editors out there. People choose Evernote and Word, because features. There are lean and snappy audio players out there. People choose iTunes, because features.
There's lean software out there, and there's bloated software our there. Right now, it's (often) the bloated software is popular. Popular software is tautologically popular because it's what the most people use.
This is inaccurate. They don't get to choose iTunes.
Also, a lot of the more popular Electron apps are not as feature rich as some of the native apps, so I don't agree with your assessment. I think they're popular because the people who do seem to like them are loud enough to sway opinion.
> Can't we do better than this? Or do we have to accept and depend on Google to create our desktop software?
We're working on a crossplatform app that runs on macOS, Windows, Chrome OS, Android, and iOS.
The UI runs on a webview provided by each platform and it's the same codebase for all 5 platforms. The native layer is as thin as possible, but there is some functionality we've had to repeat in each platform.
The macOS app weights 15MB. A hello world in Electron weights over 100MB. I think we've done pretty good.
The previous version used Electron for Windows and macOS, and Cordova for Android and iOS. This allowed me to do the 5 platforms on my own but introduced many problems.
> Imagine if I were to write a 'next-gen' CAD program or an alternative 3D modeling program in Electron. I'm not so sure if the manufacturing or the games industry would take a second look at that. But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time.
Specialized industry software have a (moderate) liberty of picking a platform. They can say that they work only on Windows, or Mac, or a flavor of Unix if necessary, based on various market factors and major clients. They can atleast release for one major platform, and hold out for other platforms until they are really big enough.
On the other hand, general purpose software (editors, messaging, etc) – they need to be everywhere. Android, iOS, Windows, Linux, Mac – at the very least. Because users already are multi-device. Even in the best case, a single user wants his/her important apps to sync between phone and laptop. Your general purpose app is dead on arrival if it does not support atleast two platforms.
I think the difference is CAD is already expensive in memory and CPU time, so any increase would likely be very noticeable. With IDE's and messaging clients, pretty much any computer can run even the most inefficient ones fairly well since they aren't doing anything super resource intensive, so it makes sense to prioritize feature development over efficiency improvements which wouldn't really affect the end user very much.
Personally, I dislike the idea of Electron apps and the slight increase in input lag and lack of customization, so I never install them on my personal computer (I just use the website, since that is essentially all the app is anyways), but I can see that for most people it makes sense to trade off efficiency for feature development in this case.
Nobody forces you to use Visual Studio Code, vim and emacs are still around.
As VSC is vastly successful, the analogy with manufacturing or gaming industry obviously does not hold: the software development 'industry' does not only take a good look at VSC, it has already accepted it as viable product.
So Microsoft is right in investing into great IDE features rather than reducing VSCs resource footprint.
I assume that similar arguments can be made for every popular Electron-based application.
An app is better than no app at all. Your "can we do better" scenario means that most of the electron apps we currently have would not exist, especially on an os like Linux. Memory is cheap. CPU is cheap. Disk space is beyond cheap. Developer time and motivation are extremely expensive. Let's see, which one should we optimize for? Yes, for cad, 3d, and games this probably isn't the right tool. But those apps are rare. For most apps, it seems to be. Are you going to pay thousands of dollars for your text editor like people to for cad? Or even $60 for it but buy millions of licenses like videogames sell? No, you're not. You likely expect these tools to be free but insist on criticising the underlying tech. Why not fork these apps yourself and rewrite them natively? Sure is better than the developer deciding not to make the app because cross platform development is too expensive or they don't have the time to learn swift, objective c, c#, and c++ to create "proper" cross platform apps. This argument is frankly tiring and beat to death. If you don't like the apps, don't use them. No one is holding a gun to your head.
Yeah but the list specifically mentions C++, which I think is part of the reason why this category is hard. Python on the other hand is definitely more entry level friendly but it's still Qt. This should be emphasised.
PyQt and PySide take full advantage of the C++ Qt library. Performance is as good as a C++ native Qt app, as long as you have no logical bottlenecks in Python.
This is just a matter of belief unless there is open source code repo which demonstrates the perf comparison shown above by solving the identical problem statement in 3 different technologies.
I'd say that Javascript/Electron is easier if you come from a webdev perspective, from a tabula rasa point of view I highly doubt that the usual react/redux rigamarole that's often used is that easy. Not even sure if I like it that much better than ExtJS, and that's saying something.
Same goes for Swing, I didn't mind writing in it, but the framework parts aren't really easier than Qt etc. Java as a language has fewer footguns than C++, so if you include that, sure...
There's also FPC/Lazarus as a Delphi replacement (the original seems to be driven into the seventh layer of enterprise heck). Easy enough to create small-ish native UIs.
Lazarus is easier than the first two by far and you get self-contained native executables (no runtime requirements or extra DLLs, at least on Windows), native widgets (on Linux you can choose between Gtk and Qt, though the latter does need a "bridge" .so), very low memory consumption (think a handful of MBs for a very simple application and memory requirements do not grow much outside of your own use - to give a ballpark, i just opened Lazarus itself with a simple program and the task manager reports just 36MB of RAM use for the entire IDE) and very good performance.
From the development side you get WYSIWYG UI editing, an IDE that has deep understanding of the code and updates it "live" as you make modifications to the UI (and other "managed" components), very fast compilation times, a very mature and rich framework (which is also very stable as the developers almost never break backwards compatibility meaning your code will compile for years to come) and recently the IDE got an online package manager and installer (repositories existed for years but they were manual to install).
Also the entire IDE can run and be usable even on a first generation Raspberry Pi (though for comfort, especially with the UI designer, it is a better to use something slightly faster).
The negative side is that as it relies on native widgets, it is much harder to create custom themes. Though there are themeable controls available (especially if you are not against paying for them as there are a few companies selling commercial components for Lazarus). Personally i prefer native controls anyway.
Have you ever heard of static linking? Assuming you're using a GUI framework that has a sane license which allows that, it is rather easy to get "self-contained" native executables in most languages.
Lazarus is nice though: Delphi has always been an awesome RAD IDE and Lazarus brings cross-platform support to it.
Lazarus does use static linking for its own libraries and the license allows that. Yes you can do the same with other languages, but this was just a single feature among others, i'm not presenting every single one of them in isolation in a way where if you can find other languages/environments invalidate everything else, i'm presenting these features as a whole. If anything the self-contained part is a minor feature (and not universally available, it really depends on the backend, though for most OSes you can use one that has no external requirements).
Lazarus being much easier to use than the first two while requiring minimal resources and providing an advanced yet lightweight IDE (among other stuff) are more important IMO.
Lazarus could move on to a single window though. I find the free-floating windows rather annoying as they are hidden behind other windows more often than not.
I have read the Free Pascal wiki about that right after wondering why they don't do that by default. I would like to add "... by default" in my original suggestion.
Yeah, I feel that they should actually make it default. By the way, check out Codetyphon [1], if you don't know it already. That is one hell of a component and library collection, and it has a lot of added features for the IDE. Really bad Website, though.
You can configure it like that, i think the main reason that it isn't by default is mainly tradition as many people among the developers and community prefer the multiwindow setup.
But all you need to do is to install the AnchorDockingDsgn package (and optionally the sparta_DockedFormEditor package so that the form designer isn't floating but itself also part of the main window - yes the package names could be better).
I think they should ask you the first time you run it though. It already has a first time setup dialog anyway, showing two buttons with screenshots of the two setups shouldn't be that hard.
Yeah Lazarus is really a RAD environment. Unfortunately I don't like Pascal nor Modern Pascal that much. My holy grail is something of the same quality but using C# which, for me, is the superior language by far.
What do miss from C# compared to Free Pascal? Outside of something like LINQ and lambdas i can't think of any other major difference between the two languages (and lambdas are WIP, i think they already work in the trunk), what do you have in mind?
Pascal has one great benefit, compiler is fast as hell - so fast that it could (incrementally) compile & launch your application in 2-3 seconds on Intel Celeron 333mhz.
Or at least this was true for Delphi, not sure about Lazarus
I hold out hope for Flutter. It was a great experience building an Android and iOS app (good API's, predictable results across a variety of devices) and should translate well to desktop development.
> Javascript and Electron : easy but terrible performance.
Is performance that terrible though? VSCode works ok for me, is it more to do with how people use Electron rather than Electron itself causing the performance downgrade?
I used PyQt and PySlide only on small projects but I don't understand why they would have terrible performance? The occasional call into Python code shouldn't bring down the speed from the Qt baseline.
You have two extremes for GUI development. One is games, where everything is built from the ground up. The other is professional apps like office, photoshop where large dev teams with lots of money build tightly integrated GUIs for each platform.
Then you have the 95% of apps that just need an interface.
For close to four decades OS providers have actively fought against the development of a common cross platform GUI framework that was easy to use.
Now finally we have electron so we can use the only existing cross platform gui platform (html/javascript) that survived in spite of the big players attempts to kill it.
So electron/javascript will dominate. It’s not pretty but it’s the best we have.
As mentioned in comments elsewhere in the thread, there are several newer projects that are trying to fill that need for performant, cross-platform desktop app development.
Javascript and React Native has increasing desktop support. Both the Windows and macOS branches have been seeing a lot of development lately, especially given Microsoft's Office team's investments into React Native for cross-platform UI. To my knowledge, it is only the Linux React Native that is the most lagging right now, and has a ton of "Help Wanted signs" up.
I'm guessing their LTS is whatever Google's released to an extent. Google Chrome is the basis for Electron, it would be a bad move to be over a year behind Chrome, which would lend to poor support from Google Chrome's dev team. At least that's my take on it, I'm not involved with either project. Maybe someone else here has better input over the matter.
They support the last three major releases, and that's it. So right now that's 6.x.y, 5.x.y and 4.x.y. A new major release is released about every 3 months.
To quote the official stance: "If an application has exceptional circumstances and needs to stay on an unsupported series of Electron, developers can silence the end-of-support warning by omitting the final release from the app's package.json" [0]
No mention of Wayland support, which means that desktop applications like Skype and Signal will continue to have a poor user experience on GNU/Linux unless you use Xorg. Using these applications with fractional scaling in Wayland is a bit rough—I guess we are waiting for Google to land patches upstream of Electron in Chromium?
Electron is the true and only available cross-platform desktop build environment these days, it actually makes business sense for many. All alternatives(Qt, whatever) come out short in my opinion.
The major complain of course is its memory/disk space.
I don't see how that's going to be resolved soon even though RAM/Disk is cheap these days, maybe a smaller js engine, or maybe replacing nodejs with something lighter(e.g. golang backend).
Another approach is to run a local daemon(e.g. one go binary) that does all the backend operations(filesystem, network,etc), while use browser as your UI.
I'm more and more confused these days by the downvotes at HN, I found I need be "100% politically correct" for technical discussions here(i.e. nothing negative at all, even for critical thoughts or neutral comments, neither is enough though, the comments actually has to be perfect positive), people are so sensitive these days, including me who actually cares about downvotes, which is a bad sign.
I have no idea why you're being downvoted for this. I like your idea about a golang backend. In fact, the entire application can be packaged within a single golang binary which provides simple distribution and only requires the user have a modern browser installed on their computer. .NET Core recently added self-contained executable support so there are more options available today than just golang.
Not mentioned in the release notes, but if I'm not mistaken this update adds support for Touch ID. I thought that was coming in 5 but it looks like it didn't.
It seems to me that the short term solution for the runtime overhead is to have the core runtime running in the background and the applications running decoupled from it on top. Is there any reasonable mature project going this way ?
I'm surprised Kivy [0] doesn't get more attention for desktop app development. Apps are developed in Python, it's cross-platform and MIT licensed. Running the hello world example uses just ~2.5% cpu and ~57mb memory on a 2015 mbp.
I feel embarrassed to ask such an obvious question, but what would it take to _not_ download electron with every app? I assume the main drawback to doing this is having the correct version. This isn't a big problem for web browsers.
Its always the same complaints about Electron's size/runtime.
Try to build a desktop app using a native language/UI framework of your choice (C#/Java/C++ with whatever fancy UI libs you want) which will even come close to the power or HTML+CSS - hint, you can't. Just trying to implement the layout/cascading behaviors, never mind all the stuff on top, would take forever.
Next add the fact that you can get true cross platform apps with a single code base in reality, not the pseudo lies promised by ReactNative or the even more ridiculous RN on Web, or new pretenders like Flutter.
Electron isn't being used for tiny utilities - its used for apps like Slack/VSCode which really do need to run on multiple platforms and have the exact same UI/UX, which is simply impossible even if you dedicate 3 dedicated teams at 3-5x the cost.
Why don't people complain about how bloated browsers are? Electron is simply V8+Node bundled for desktop use.
276 comments
[ 3.1 ms ] story [ 267 ms ] threadhere it is: https://dev.to/n_tepluhina/building-a-desktop-app-with-vue-n...
They even did a nice graphic.
With UWP C++ being the reference point of 100%, UWP C# gets also 100% (thanks .NET Native), React Native 180% and Electron goes sky high above 700%!
https://youtu.be/TZnajQqqKV8?t=2919
This is how much everyone doing Electron apps is contributing to global warming, including VSCode team.
Xamarin for .NET devs, React Native for C++ devs (think Qt/QML).
Doesn't seem like a direct competitor with Electron then. Right?
http://www.reactnative.com/build-os-x-desktop-apps-using-rea...
You got me there on GNU/Linux support, which doesn't mean it will not come later. They just need to decide which flavour of Linux desktop one is supposed to support in React Native.
Some initial work was already done to make React Native compile for this target: https://github.com/facebook/react-native/pull/25427
That said, I'd love a divorce from Electron if something else would give me a system tray, node runtime, and seamless upgrades, supported cross-platform.
With Electron runtime you can just write a text file on any of the supported platforms and you have a working, running desktop app. No compilation needed.
No need to install SDKs, deal with builds, project files, etc.
Jokes aside, lack of basic code protection (aside of script minimization and/or obfuscation) it's that prevents me from using Electron/Atom/whatever. I know anyone could decompile a C# application easily, but I find the javascript case worst.
Do you know any commercial applications using any of these solutions? (I'm speaking of shareware / paid software, not "Whatsapp desktop" type)
It appears to be a free client for a paid service. Not the type of commercial software I was thinking of.
Mailspring is another one I can think of. It's a free email client that offers extra features for pay.
I'm also preparing a PhotoStructure for Servers build that is electron-less, and uses either docker or snap (it's how I run it on my NAS). I'm looking for more beta testers for this headless build, if you're interested.
https://blog.photostructure.com/introducing-photostructure/ has more background and signup information.
Disclaimer: I'm the author.
About PhotoSctructure: - Great application idea, sincerely. My photo library is a big mess and this sounds super handy. - May I recommend another icon? I find strange that PhotoStructure "for Desktop" has a cloud in it's icon :-) - Regarding being a tester, thank you, but my current file server is a very stripped down debian box right now (Fujitsu Futro S900).
:-)
I'm testing it on an rpi 4, so if you've got ~> 2gb ram, it should run.
Thank you!
https://videohubapp.com/
https://github.com/whyboris/Video-Hub-App -- built with Angular
Great app, by the way.
The thing I built has enough code you can learn from to get you farther: https://github.com/whyboris/Video-Hub-App
On the Rich Hickey "simple vs easy" scale, Electron is very much leaning to the "easy" side.
It's about as bare of a reference as you might find. Have at it. (Also there's no Readme, just consult the package file. I only threw this together when I was finding my way around it this spring)
https://github.com/Robert-Fairley/electron-typescript-starte...
However when I was in South Africa a few years back they were still running with XP and < 2GB RAM with HDDs that I saw in a school and hotel.
Ok, hardware components are cheaper and easier to come by but we shouldn't stop caring about system resource usage.
I imagine a big reason that they're on old hardware is cost - just because it's relatively cheap for someone in the West to get a decent modern machine at a reasonable cost doesn't mean that it's the same everywhere, especially when there's big disparities in the purchasing power of the native currency vs. the sellers/manufactures currency. It's not so much an optimization, I imagine most users on legacy hardware don't choose to be, it's more likely that they can't afford more modern hardware or it isn't available for them to purchase.
Another huge reason for users to stay with older operating systems (especially in business and government) is dependencies on legacy software - if an organization relies on software that has never been updated after Windows 95/XP and doesn't function on later versions then they're going to be stuck using legacy machine configurations until the process can be changed to something else.
> stopped caring about resource usage and efficiency (energy usage and operator time)
How do you know that they don't care about how efficiently they can use a machine for whatever they're doing? It's a baseless assumption.
Even if your user percent that's stuck using older hardware/operating systems is in the single digits, that isn't an excuse to ignore their requirements IMO. Doing so is a sign of sloppy engineering, akin to designing a new mode of public transport, for example, that doesn't cater for disabled people.
Spotify manages to use only ~150MB. If it tried to use 1GB I would replace it since I have more important things competing for my limited RAM.
[1] For curious: https://github.com/daliusd/xlsx-generator
* one the best thing that happened to desktop software as it enable web developers to build desktop portable app
* one of the worst thing that happened, because it makes the desktop world rely on Google and decrease even more the expectations on how much resources an app should consume
What are your opinions ?
However, if you want to hire Qt developers, that's a much smaller pool and then you also need to pay Qt license fees for each one.
If you want to develop truly native applications, now you need to maintain builds for Windows, Mac OS and perhaps even Linux. You need developers familiar with all of these native frameworks.
Optimizing for developers isn't necessarily worse for users, if they can get more done in less time, users benefit. It's just not so obvious. No user will ever complain about a product they aren't using because it won't ship until next year with half the features.
Basically, you need to link dynamically or provide object files. You can't use commercial modules too. But that's only a small portion of Qt anyway.
[1] https://www.lazarus-ide.org/
I strongly suspect I'd never be able to bring the level of polish I could with HTML & CSS to the UI through the standard SDKs -- so the resulting app would be a much worse user experience as well.
The amount of time I'd have to spend learning a new SDK would basically put me off, and I'd likely never have created this app.
Instead I have over 700 people who have purchased my app (~2 purchases per day over the past half year) - https://videohubapp.com/
But UI is not essential for a functioning app, and if the time costs of building a good UI are too high (a lot of new learning and problem solving) I'll spend less time on it.
What "sample" are you talking about? Is this the kind of thing you're comparing my app to? https://doc.qt.io/qt-5/examples-graphicsview.html
https://doc.qt.io/qt-5/qtdoc-demos-photoviewer-example.html
(Edit: by no means I'm saying that your work is trivial to replicate, apologies if this comment came across like that - just wanted to point out that there's more to Qt than Qt Widget.)
The original reply I made was to point out that startup costs decrease number of people starting. Unless you know Qt already, your first project will take much longer than using technologies you already know. It's not at all clear how long learning would take.
I know I can climb the mountain, but I'd rather not. This isn't to discourage others from doing it, it's to explain to those who don't understand why many people prefer to stick to Electron.
Simple QML viedo player.
That should tell you something.
It might change a bit with Flutter & SwiftUI but I still find web & CSS to be a better authoring model.
Note that I've been doing (native) desktop programming before so I can compare.
I have to kill the application before it consumes everything.
Electron applications like VS Code are an exception and slightly gives me hope.
Going to be working on an Electron app, so I'm curious about what optimizations have been made there.
I've found keeping as precious little of the work in the render process as possible has helped a great deal. Send everything to the main process and use the event/messaging system to update the state. Then things that you're used to doing to maintain application performance in a web browser apply. Keep the compute in the back as much as possible.
And depending on the task, offload compute to a native module [if you're capable and] if the expense between NodeJS <> native module is worth it (more intense compute tasks).
There's probably more and more experienced advice out there, but this is my experience so far.
They just run more efficient software on top of electron than others do.
With my Web developer hat, I see the future as PWAs and if you really need more than Web APIs allow, by all means create a local daemon that uses whatever browser the user has installed.
All my uses of Electron are forced upon me, if native versions are available and I am allowed to choose, native wins.
For personal use, you also don't need multiple runtimes for multiple electron apps. You can just use the single shared one (or even system one; for example archlinux has electron installable via pacman), reducing memory use.
It's also pretty good tool to write your own UI for other people's websites.
Can you point to some good examples of these use cases?
You can get data with XMLHttpRequest inside electron from any origin and then just process the returned document with regular web apis.
Sorry, I don't have anything public.
Electron always reminds me of that trip.
Here is one I think: 3D printer slicer, to my knowledge there is no slicer which uses electron I think it limits the contributers who can quickly deploy plugins in JavaScript
Edit: https://pathio.xyz/hello-world "Pathio is built on a mixture of modern web-technology (Electron) and a powerful native slicing engine (written in C++17)"
Imagine if I were to write a 'next-gen' CAD program or an alternative 3D modeling program in Electron. I'm not so sure if the manufacturing or the games industry would take a second look at that. But in our industry, it is seen as normal for our text editors, ide's, git clients and video editing software and our messaging clients to be expensive in memory and cpu time.
Can't we do better than this? Or do we have to accept and depend on Google to create our desktop software?
Language-dependent: - Lazarus/LCL - Common Lisp/McCLIM
Personally I'm a fan of C# with WPF, but while C# is decently cross-platform with .net core WPF is Windows only.
Swing https://en.wikipedia.org/wiki/Swing_(Java)
QT https://www.qt.io/
TK https://docs.python.org/3/library/tkinter.html
wxWidgets https://www.wxwidgets.org/
A good manager will ensure everyone has actually read Filthy Rich Clients, is aware of Swing theme component libraries and never does IO on the UI thread.
And for bonus points, that the team gets hold of an Java AOT compiler to native code.
Of course JFX is probably a better option now days but for a small GUI if you avoid layout managers like GridBagLayout (built to work with a WYSIWYG) and you are on the JVM seems like an easy option to me
http://tktable.sourceforge.net/tile/screenshots/windowsxp.ht...
https://www.tcl.tk/man/tcl8.5/TkCmd/ttk_intro.htm
I wouldn't base any commercial product I'd make on Tk, if it was meant for a large audience. Internal tools where you get to tell you users: "shut up and use the ugly app cause management already paid for it", ok, there you can use it. Otherwise... no.
How about a dated looking Electron "app"?
Cross-platform desktop apps with reason
0. https://sciter.com/
What's the benefit over using a native GUI library?
You rely on Chromium which is battle-tested and have frequent updates
You can hire web developers to sketch, prototype, deliver your GUI. You can connect it to your own website.
You can let your users creates plugins and scripts more easily with web technologies.
You already have most of the codebase if you want to run a Light version of your software online as a SaaS or free app.
Chromium has been battle-tested and was wounded severely. Embedding it in your application will not automatically add the regular security patches to it.
Time to deliver new features matters. Skill reusability matters. This is the economic reality that makes electron attractive to all the people that decide to use it to build software.
The alternative to electron is not always a leaner different framework. It may also be not building software because you don't have the resources and skills needed.
e.g. An end user using Discord and Slack has to download 2 Electron applications (~500MB of disk space) and this is for a chat app, Ripcord [0] can do both with less RAM resources and disk space.
> The alternative to electron is not always a leaner different framework.
You can have both, there are newer frameworks popping up such as Flutter, React Native and Reason Native.
[0] https://cancel.fm/ripcord/
It might not be the future you or I want, but it is the future that the majority of end users want. Market forces don't always work for getting users what they want (see privacy) but in this case the money is talking. Slack's desktop app is a classic example of being a memory hog, but Slack has been enormously successful.
Every time you hear someone complain about how their new PC is so slow to do $trivial_task, think again. Most users unfortunately don't know any better, nor have the inclination to teach themselves to.
Modern OS's don't really have an equivalent to that. Probably because usage has become more fragmented.
Don't Apple already do something similar for battery hogs? May be misremembering, but I'd have thought a similar principle applied.
Half the challenge of course would be dissuading the vendor from excluding their own apps from these notifications.
But yes, on OS X, the battery drop-down will list any apps that are consuming significant amounts of energy. For me these are constantly Chrome and Intellij IDEA.
Well, JetBrains is one of few choices that's even more of a hog than Atom.
I didn't say that there are no other frameworks. The ones you provided all break the "transferable skill" requirement (React native a bit less so but still).
If you prefer to install ripchord instead of discord and slack nothing prevents you for doing so. Let me write a few comments about it:
- it made sense building it for the author because those two services already existed and already had enough users. Also the author has the skills needed to build it.
- it won't be free
- it is not feature complete compared to the reproduced services
So it might attract users depending of the perceived gain from a faster software vs its price and the missing features. It also has to win over all the people that have already installed the slack & discord clients. If it gains significant market share there are 2 risks: intentional api breaking changes by slack & discord, and them redoing/optimizing their client to win back the lost users. Most probably: they don't care about the client part. They are selling a service and this new client might make some of their users happier.
So we see that even though ripchord exists, it does not mean that electron hasn't helped in making two new services available. The ripchord author might be able to reproduce a client with a better tech, but that doesn't mean he has the skills to create a whole new offer (market research, sales, backend administration, etc).
edit: format
At this point what you have can't even be called skill, on?
If you skim a tutorial and release an unmaintanable mess because you lacked experience with your tools users are not going to forgive you because thank god you did not use electron.
You might have some time to learn all this. Or not. Maybe you are busy finding funds. Maybe you are pitching companies to get your first prospects.
My main laptop has 4GB ram. I cannot afford to use 500mb for a chat app. Beside, did you even go outside? A lot of people cant afford (or dont need) a computer with more than that. For example lets see in a community where having a lot of ram matters. In the Steam Community, around 12% of people have 4GB or less. https://store.steampowered.com/hwsurvey#cat0_stats_row
If you need more power, that's fine. But does an administrative assistant, or a lawyer, for that matter? Give me old-fashioned desktop applications, and I can compete with you at hundreds to thousands less per head. How many people doing that does it take to make a software engineer's time worth the trouble?
I don't hate Electron. I just won't trade _my_ limited CPU, memory, and bandwidth for _your_ inabilility to learn Qt. Your Qt using competitor will get my business.
Not to mention a lot of QT apps bundle the entire thing as well, so I have in my PC several versions of qt5win.dll and friends, many exactly the same.
Furthermore QT apps are not a guarantee of fast programs, and often the interfaces look horrible.
I fail to see a huge difference in programming methods, even if the QT runtime clocks at about 50mb instead of 500mb.
Here is an example: https://imgur.com/a/RZZK7nA
The hardware industry has trained them to think, "This machine is slow. It must be getting old. Time to get a new one!"
In reality, they've probably just accumulated applications that run in the background and/or put less developer time into constraining resources.
Cross-platform desktop apps with Reason
Recreating all widgets is a huge task and such a framework needs a lot of dev momentum behind it to be usable in production. I really like everything Revery promises but right now it's just not an option for anything beyond simple apps for personal use.
I was able to find it by:
1. Go to discord
2. Control + Shift + I
3. Application Tab
4. Storge/Local Storage/discordapp.com
5. Refresh with Control + R
6. Token will appear, quickly copy it.
I don't understand what personal information is contained in a discord token, or who it is being given to in this example
uTorrent is perhaps another bad choice.
uTorrents first public beta release was in late 05 Qbittorrent was released in early 06.
By the time about anyone was aware of uTorrent Qbittorrent was already a thing and as good. uTorrent went on to become first proprietary and ultimately ended up installing malware on users system and mining coin whereas Qbittorrent is still awesome.
Slack with its famously crappy performance and battery destruction is probably another bad choice to make the case although I hear its improved lately. Maybe wait another year to use it as an example so people have time to forget how much it sucked.
I would totally stay with comparing say visual studio code to visual studio and hope your audience doesn't remember Emacs and Jetbrains products are also cross platform without electron.
I think instead you should hope they do remember those.
I wouldn't say that emacs is a shining exemple of desktop UI. Everything is based on text buffers and keyboard commands. I don't see this type of application getting the same scale of adoption as vscode or slack (and this comes someone who has used emacs as an editor for python and org mode files for 3 years).
End users do want it as seen by the commercial success of Electron based products, including completely free products like VSCode even when Sublime and Visual Studio exist.
Features and functionality almost always overrule performance. I'd rather wait a little longer to do something than not be able to do it at all.
This is the old problem: the middle manager can wave a sheet of paper around saying, "my team used an agile electron methodology to disrupt the plastic fork industry!" or whatever, and get rewarded. He cannot, however, explain that by using something else, he saved long-term technical debt, maintainability, etc. because those costs are not immediately visible.
I'm kind of hopeful for flutter. God willing, it will solve our problems...
It's worth mentioning that this madness is mostly an issue in the JS community; everyone else is getting along just fine. And, as with npm, react, angular, electron, etc. etc. the JavaScript programmers act like these issues - already solved countless times elsewhere - are universal constants.
https://www.infoq.com/presentations/autocad-webassembly/
What you can do in a browser you can do in Electron App as well because Electron embeds the browser!
Autodesk's demo is in a web browser, good luck trying this when you're offline.
Web tech is highly dynamic and gives you the ability to change your product very quickly, deliver the value and it is quite cheap in comparison to c++ analogs.
Why not? Onshape is browser based, and quite a few mechanical engineers and the 3D printer community seem to be happy with how well it works.
https://www.onshape.com/
> Can't we do better than this?
Honestly the answer is probably no. People just don't understand how much work goes into something like this. Who is going to, or even can, spend the time and money to do it?
On the other hand, one of the biggest competitors outright states thet their software needs 16gb+ of RAM* I guess Electron wouldn't make much of a difference.
[*] https://www.materialise.com/en/software/magics/product-infor...
I attribute this mainly to the younger generation of developers, most of whom have never experienced computing with fewer resources, nor have any idea of the amount of resources something should take. That can partly be blamed on education and the "premature optimisation" argument that still gets thrown around as a random excuse to do something terribly inefficient.
Perhaps CPU speed/memory is not quite there yet for Electron to be viable in most projects, but nobody is taking away your ability to fiddle bits. Why does it have to be one or the other?
A JS developer can get access to writing their first 'native' client. If it is too slow, perhaps she will investigate a more memory efficient way. Or perhaps its good enough for the current use case.
Some paradigms will be dead ends, but experimenting with higher level languages and libraries is what moves us forward.
It's equivalent to kicking and screaming in the late eighties that this 'Python' is not efficient and a waste of time.
I'm using a lot of Electron apps today. Including VS Code. Because it's so much more productive than anything else I've used before.
I bet you have a very powerful computer. Because you value your time.
My private computer is much less powerful, but still runs noticeably smoother because I don't put any junk on it.
(I cannot, for the life of myself, figure out why applications on Windows cannot play audio consistently without jitter. Might be McAfee or some other corporate shit.)
I attribute this to the older generation of OS developers and project managers and CEOs, who have not offered easy to use, powerful tools to create cross platform applications.
If the programming language is not memory managed, it doesn't matter (so anything C or C++ based is out).
If it's not cross platform, it doesn't matter (Win32, WPF, Cocoa, etc.).
If the priorities of its developers keep shifting, it doesn't matter (Qt from the old Qt widgets to the new declarative ones).
If it doesn't support high DPI or responsive design, it's out.
And I say this as a middle-aged developer, my first PC was a Pentium 1 and I've also used home computers from the 80's.
The incentives for OS creators are to create walled gardens. Which they've done successfully. But because of that, they can't also bitch and moan about "slow cross platform applications" when they do everything they can to kill or hinder cross platform stacks.
This happened nearly a decade ago.
1. More value used to be placed on efficiency.
2. As time went on, the value of powerful, cross-platform tools and platforms became more obvious.
3. Since this was later in the evolution of the industry, the people who made it happen were a different generation that didn't prioritize efficiency.
That is to say, perhaps there's no fundamental reason you couldn't have the nirvana of efficiency and portability (best of both worlds), and it's just that no community of developers has actually aimed for that.
Maybe we can, maybe we can't. Regardless, no one has done it.
I'm still holding out on a ReactNative-like solution for all platforms, independent of language. Eg, some type of RPC bridge is opened between a process and a window, and it creates native widgets for each proper platform in the same way ReactNative does; except with no care for the originating language that the process is written in.
Maybe one day.
Not while priorities are inverted. Right now, the priority is not on the end user so much as it is on developer productivity and iterating as fast as possible.
There are lean and snappy text editors out there. People choose Evernote and Word, because features. There are lean and snappy audio players out there. People choose iTunes, because features.
There's lean software out there, and there's bloated software our there. Right now, it's (often) the bloated software is popular. Popular software is tautologically popular because it's what the most people use.
This is inaccurate. They don't get to choose iTunes.
Also, a lot of the more popular Electron apps are not as feature rich as some of the native apps, so I don't agree with your assessment. I think they're popular because the people who do seem to like them are loud enough to sway opinion.
We're working on a crossplatform app that runs on macOS, Windows, Chrome OS, Android, and iOS.
The UI runs on a webview provided by each platform and it's the same codebase for all 5 platforms. The native layer is as thin as possible, but there is some functionality we've had to repeat in each platform.
The macOS app weights 15MB. A hello world in Electron weights over 100MB. I think we've done pretty good.
The previous version used Electron for Windows and macOS, and Cordova for Android and iOS. This allowed me to do the 5 platforms on my own but introduced many problems.
All the best for your endeavours.
Thanks, the same to you!
Specialized industry software have a (moderate) liberty of picking a platform. They can say that they work only on Windows, or Mac, or a flavor of Unix if necessary, based on various market factors and major clients. They can atleast release for one major platform, and hold out for other platforms until they are really big enough.
On the other hand, general purpose software (editors, messaging, etc) – they need to be everywhere. Android, iOS, Windows, Linux, Mac – at the very least. Because users already are multi-device. Even in the best case, a single user wants his/her important apps to sync between phone and laptop. Your general purpose app is dead on arrival if it does not support atleast two platforms.
Comparing these two is like apples and oranges.
Personally, I dislike the idea of Electron apps and the slight increase in input lag and lack of customization, so I never install them on my personal computer (I just use the website, since that is essentially all the app is anyways), but I can see that for most people it makes sense to trade off efficiency for feature development in this case.
As VSC is vastly successful, the analogy with manufacturing or gaming industry obviously does not hold: the software development 'industry' does not only take a good look at VSC, it has already accepted it as viable product.
So Microsoft is right in investing into great IDE features rather than reducing VSCs resource footprint.
I assume that similar arguments can be made for every popular Electron-based application.
* C++ and GTK or other UI framework : hard but excellent performance.
* Java and Swing UI framework : easier but less performant.
* Javascript and Electron : easy but terrible performance.
Which one will prevail?
Using AOT compilation and not doing everything on the UI thread solves the performance issues.
Same goes for Swing, I didn't mind writing in it, but the framework parts aren't really easier than Qt etc. Java as a language has fewer footguns than C++, so if you include that, sure...
There's also FPC/Lazarus as a Delphi replacement (the original seems to be driven into the seventh layer of enterprise heck). Easy enough to create small-ish native UIs.
From the development side you get WYSIWYG UI editing, an IDE that has deep understanding of the code and updates it "live" as you make modifications to the UI (and other "managed" components), very fast compilation times, a very mature and rich framework (which is also very stable as the developers almost never break backwards compatibility meaning your code will compile for years to come) and recently the IDE got an online package manager and installer (repositories existed for years but they were manual to install).
Also the entire IDE can run and be usable even on a first generation Raspberry Pi (though for comfort, especially with the UI designer, it is a better to use something slightly faster).
The negative side is that as it relies on native widgets, it is much harder to create custom themes. Though there are themeable controls available (especially if you are not against paying for them as there are a few companies selling commercial components for Lazarus). Personally i prefer native controls anyway.
Have you ever heard of static linking? Assuming you're using a GUI framework that has a sane license which allows that, it is rather easy to get "self-contained" native executables in most languages.
Lazarus is nice though: Delphi has always been an awesome RAD IDE and Lazarus brings cross-platform support to it.
Lazarus being much easier to use than the first two while requiring minimal resources and providing an advanced yet lightweight IDE (among other stuff) are more important IMO.
(Thank you for the hint though.)
[1] https://www.pilotlogic.com/sitejoom/index.php/downloads/cate...
But all you need to do is to install the AnchorDockingDsgn package (and optionally the sparta_DockedFormEditor package so that the form designer isn't floating but itself also part of the main window - yes the package names could be better).
I think they should ask you the first time you run it though. It already has a first time setup dialog anyway, showing two buttons with screenshots of the two setups shouldn't be that hard.
Or at least this was true for Delphi, not sure about Lazarus
Is performance that terrible though? VSCode works ok for me, is it more to do with how people use Electron rather than Electron itself causing the performance downgrade?
https://github.com/google/flutter-desktop-embedding
But I think they will focus on mobile first so the time when we can use Flutter for desktop programming is still far far far away.
Also you forgot, PyQt and PySide: easy but terrible performance.
Then you have the 95% of apps that just need an interface.
For close to four decades OS providers have actively fought against the development of a common cross platform GUI framework that was easy to use.
Now finally we have electron so we can use the only existing cross platform gui platform (html/javascript) that survived in spite of the big players attempts to kill it.
So electron/javascript will dominate. It’s not pretty but it’s the best we have.
[1] https://github.com/zserge/webview
* Revery (language: Reason) - https://www.outrunlabs.com/revery/
* WebView (language: C/C++/Golang) - https://github.com/zserge/webview
* Dear ImGui (bindings exist for many languages!) - https://github.com/ocornut/imgui
* Flutter (language: Dart) - https://flutter.dev/
None have really stood out yet to replace Electron, but the future seems bright.
* chromium
* node.js
* v8 ?
To my understanding chromium includes V8, and node.js is built on top of it.
3.0.0 was released 10 months ago. If the current frequency of releases stays constant any version reaches end of life after about 9 months.
https://electronjs.org/releases/stable
I'm guessing their LTS is whatever Google's released to an extent. Google Chrome is the basis for Electron, it would be a bad move to be over a year behind Chrome, which would lend to poor support from Google Chrome's dev team. At least that's my take on it, I'm not involved with either project. Maybe someone else here has better input over the matter.
To quote the official stance: "If an application has exceptional circumstances and needs to stay on an unsupported series of Electron, developers can silence the end-of-support warning by omitting the final release from the app's package.json" [0]
[0] https://electronjs.org/docs/tutorial/support#supported-versi...
If you want iOS or iPadOS, you need to be Native. And you can now port it to Mac with ease.
The days company ship crappy Desktop software with Electron needs to come to an End.
The major complain of course is its memory/disk space.
I don't see how that's going to be resolved soon even though RAM/Disk is cheap these days, maybe a smaller js engine, or maybe replacing nodejs with something lighter(e.g. golang backend).
Another approach is to run a local daemon(e.g. one go binary) that does all the backend operations(filesystem, network,etc), while use browser as your UI.
https://github.com/electron/electron/issues/2003
https://github.com/electron/electron/pull/16707#issuecomment...
Welcome to 2016, electron apps!
This should help BitWarden be a more competitive alternative to 1Password for Mac users.
[1] https://www.outrunlabs.com/revery/
[0] https://github.com/kivy/kivy
Try to build a desktop app using a native language/UI framework of your choice (C#/Java/C++ with whatever fancy UI libs you want) which will even come close to the power or HTML+CSS - hint, you can't. Just trying to implement the layout/cascading behaviors, never mind all the stuff on top, would take forever.
Next add the fact that you can get true cross platform apps with a single code base in reality, not the pseudo lies promised by ReactNative or the even more ridiculous RN on Web, or new pretenders like Flutter.
Electron isn't being used for tiny utilities - its used for apps like Slack/VSCode which really do need to run on multiple platforms and have the exact same UI/UX, which is simply impossible even if you dedicate 3 dedicated teams at 3-5x the cost.
Why don't people complain about how bloated browsers are? Electron is simply V8+Node bundled for desktop use.