Electron 6.0
electronjs.org
electronjs.org
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.
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
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
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.
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.
> 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.
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.
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.
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.
> 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.
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...
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.
* 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.
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 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://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...
* 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.
* 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.
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.
[1] For curious: https://github.com/daliusd/xlsx-generator
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.
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.
* chromium
* node.js
* v8 ?
To my understanding chromium includes V8, and node.js is built on top of it.
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)"
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.