
How Four Native Developers Wrote an Electron App - joeyespo
https://githubengineering.com/how-four-native-developers-wrote-an-electron-app/
======
ridiculous_fish
GitHub calls this electron app "the new native" on
[https://desktop.github.com](https://desktop.github.com). But the app does not
look or feel native. It has an active appearance even when it's in the
background, content lags the window frame during resize, menu items are
enabled even when they don't apply or work, some buttons with the default
appearance don't respond to return, you can't drag and drop text, many context
menus are broken, rubber band scrolling doesn't work, the title bar text is
absent, selection modifier keys don't work properly...

If native is to mean anything, it can't mean this. Calling it "the new native"
is an affront, because its UI regresses in so many places relative to real
native apps.

~~~
HappyTypist
It's not just UI but performance as well. For native apps, UI (hover state,
clicks, etc) react in 0-1 frames. For Electron apps, these range from 3-10
frames.

~~~
rjeli
Don't worry, just wait a few years and the processors will be fast enough for
native-like performance.

~~~
sha666sum
In other words, in a few years everyone will need to replace their perfectly
good computers because of software bloat.

~~~
fludlight
You just summed up the history of the industry.

------
imran3740
The problem with Electron apps is that they're all running their own little
Chromium-like instance, hogging up hundreds of MB of RAM, clogging up the
process table with all its helper processes, using up CPU when idling. I get
the easy cross-platform solution part, but this is just horrible UX.

I'm reminded of this article [0], about just how bad Electron is compared to
native apps.

[0]: [https://josephg.com/blog/electron-is-flash-for-the-
desktop/](https://josephg.com/blog/electron-is-flash-for-the-desktop/)

~~~
vvanders
My gut wants to agree but then I see things like VSCode that shows it can be
done with discipline and proper engineering.

I also don't think you'd see nearly the level of extensions and language
support if they didn't go with an electron based solution.

~~~
Amezarak
I like VS Code and I don't want to crap on it, but I frequently experience
massive UI lag on Windows - i.e., I start typing and the letters show up five
seconds later. I think maybe it's related to source control? The same laptop
runs Visual Studio fine.

~~~
kej
Out of curiosity, do you get this regardless of file type? I've noticed
something similar but only in Python files, and I had assumed I had
misconfigured my setup somehow. Just curious if your experience was similar.

~~~
Amezarak
I see it in text files and Rust code, which are the only ones I've edited so
far in VSC.

------
lucb1e
TL;DR:

"because it's easier"

I'm disappointed by the article. Thought it was going to detail how Electron
is actually a good choice, not how they had two separate teams for the
different platforms and wanted to get rid of doubly-implementing features (not
wanting double work is the obvious requirement and leading reason for going
Electron).

I mean, _git itself is cross-platform and not Electron_. How more obvious does
it need to get? It even has a GUI. Telegram Desktop is a modern example that
did it. And Libreoffice. And Firefox and Thunderbird. And Audacity. And
FileZilla. And everything else traditionally written in the open source
community.

Java applications aren't great either. Due to their platform-independentness
things like selecting and context menus seem to be re-implemented by every
platform ifnot every project, leading to a lot of inconsistency and ugliness.
But at least they aren't as sluggish as the web crap dubbed into being native
that Electron is.

There are lots of good options but all the engineering blog is able to give
for a reason is that it was the easiest.

~~~
roryisok
Anyone know what the telegram Desktop team uses?

~~~
mhotchen
C++:
[https://github.com/telegramdesktop/tdesktop](https://github.com/telegramdesktop/tdesktop)

------
MarkMc
_> To maintain parity across the codebases, we had to implement and design the
same features twice. If we ever wanted to add Linux support, we’d have to do
it all a third time....Now we can share our logic and UI across all platforms,
which is fantastic_

I wonder whether they considered Java with SWT. For the past 10 years I've
been developing an accounting application for Windows and Mac using SWT, and
it's been a blessing to have such a simple, stable, cross-platform UI library.

It's also possible to implement plaform-specific behaviour. For example,
standard SWT doesn't allow a native toolbar on Mac, but with a few 'if (mac)'
statements I made my application look exactly like all other Mac apps:
[http://imgur.com/a/l83yI](http://imgur.com/a/l83yI)

I'd say about 95% of my UI code is platform independent.

~~~
Scarbutt
I think having to install a JRE is no go for lots of devs, unless you bundle
the JRE but still lots of devs will complain because Java.

I wonder how Jetbrains manage to handle all the anti-JVM/Java crowd.

BTW, where can I trial your software?

~~~
MarkMc
Yes I bundle the JRE with the download. In the old days I created a custom JRE
with all the cruft stripped out but these days it's not too much to ask uses
to download 50Mb. Hopefully with Jigsaw I can easily produce much smaller JREs
in future.

You can try it here:
[https://www.solaraccounts.co.uk/](https://www.solaraccounts.co.uk/)

~~~
tonyedgecombe
Off topic but did you ever get round to supporting multiple currencies?

~~~
MarkMc
Not yet. A workaround is to set up a second business with a second currency.

------
nkkollaw
Electron apps are made for developers, but it's users who they're built for
and who have to use it.

What I mean is, Electron apps make their life easier for a handful of
programmers, to the detriment of thousands or in many cases million of users.

As a freelance developer, I think Electron is great for the little apps I
build for clients for internal use. Companies like GitHub, Spotify, etc. have
the resources to do much better than that. I have no idea why they settle for
lousy performance just to use web technologies.

~~~
SomeStupidPoint
Short-term thinking: they save money of dev effort and assume their users will
just tolerate their worse apps.

It's easy to sell yourself on the idea of cutting costs and growth potential
to maximize returns _now_ when you're an entrenched market player in a
dominant position (as I would argue both GitHub and Spotify are).

Heck, it might even work.

~~~
nkkollaw
Sure, I know they're saving money, but unless you _have_ to use something
(Spotify, Skype), many people will choose a competitor instead of your app.

One such case is Atom—which from what I know is what Electron was created for:
many people use Sublime Text instead. Not because of functionality, but just
because Atom is super-slow in comparison, and it won't open or let you work
productively with files bigger than 2-5MB.

I would argue that the money they save by not going native, they lose from
people using better software.

------
cleeus
> If you’re making a native app, your tech stack choices are pretty limited.
> On the macOS side, you’ll use Xcode, Swift, and AppKit. On Windows, you’ll
> use Visual Studio, C#, and WPF or UWP.

Or you could use C++ and Qt and suddenly have Windows,Mac and Linux support in
one codebase. And the Qt mobile story is looking better with every release.

~~~
imron
When I was developing the Linux version of a piece of software I make
([https://www.chinesetextanalyser.com/](https://www.chinesetextanalyser.com/))
I started out with Gtk but it was a massive PITA to work with.

I switched to Qt and was pleasantly surprised at how nice it was to use.

------
ClausSualC
I don't know what's worst these days, WannaCry ransomware or Electron apps,
both makes me cry. Yet, WannaCry is native so I don't hate that as much as
Electron apps.

------
kristianp
Sourcetree, a git/hg client, was written in c# for windows and Objective-C for
Mac: [https://community.atlassian.com/t5/Questions/What-
technologi...](https://community.atlassian.com/t5/Questions/What-technologies-
are-used-to-develop-SourceTree/qaq-p/442029)

~~~
vram22
Is C# good for writing GUI apps on Windows? I saw someone in a recent HN
thread about Kotlin mention C#, and say that it works on many platforms
(including for GUI's, maybe). But my question is limited to Windows.

~~~
WorldMaker
C# with XAML is your best bet for writing GUI apps on Windows. UWP is the
present of Windows GUI app development and just glancing at documentation you
can quickly see that C# and XAML are front and center. You can do C++ and XAML
if you wish/must, but C# is generally a better idea. (UWP supports .NET Native
which AOT compiles C# UWP applications.)

C# and XAML can be used in WPF on versions of Windows prior to 10, if you need
to support that. The C# is mostly compatible in both GUI systems, the XAML is
very close, but subtly different, between the two.

(At Build last week, Microsoft announced the XAML Standard initiative to
better standardize XAML across platforms. They also announced desktop support
for Xamarin Forms, the XAML renderer for common subset of native controls
across non-Windows platforms, to support macOS, Linux Gtk, and even WPF.)

~~~
nozzlegear
> _You can do C++ and XAML if you wish /must, but C# is generally a better
> idea._

Just want to point it out for those that didn't know, UWP apps can also be
built with "native" JavaScript:

[https://docs.microsoft.com/en-us/windows/uwp/get-
started/cre...](https://docs.microsoft.com/en-us/windows/uwp/get-
started/create-a-hello-world-app-js-uwp)

~~~
WorldMaker
I didn't mention it because HTML is great and all (and in fact right now more
of my projects are HTML/JS), but XAML is a superior "native" GUI experience in
Windows. Especially with things like Fluent Design's recently announced
Acrylic material which doesn't have an easy-to-use HTML equivalent (yet?).

It would be great if there was an easier transition point from HTML/JS to
XAML/JS or at least XAML/C#, for better more "native UI toolkit", but right
now it feels like there is too much of a wall separating the rendering
engines. HTML/JS can still feel quite native UI, but the gap is widening,
especially once Fluent Design starts to become more common.

~~~
nozzlegear
I agree completely, C# and XAML are definitely the way to go. I only wanted to
mention JS as I've built a few UWP apps with it and it was a relatively
painless experience. That was back when WinJS was a thing though, so at the
time JS apps were very much "native" in design too.

Like you said though, it looks like JS apps are about to be left behind with
Fluent/Acrylic in the Fall update. It seems like Microsoft is pushing the
"Hosted Web App" for UWP instead of plain JS apps, even if they're still
supported.

~~~
WorldMaker
Yeah, JS is still the easiest way to build a native app and get the most
cross-platform bang for the buck with the most UI shared (HTML is HTML and
browser inter-compatibility is strong these days).

The push at build was even past the Hosted Web App to Progressive Web Apps in
the Fall update when Edge has broader Service Worker support, etc. PWAs build
on the footprint of the Hosted Web App, but include some of the standards
efforts that others such as Google have also been pushing to the Progressive
Web App space, including things like Service Worker-based caching (rather than
Hosted's Manifest-based caching).

Hosted Web Apps and PWAs still have access, when installed, to the UWP APIs
and it would be great if there were some APIs to composite things like Acrylic
or certain XAML elements into an HTML page, in a Progressive way (fallback to
HTML elements when the XAML ones aren't available).

I think, however, the focus for doing JS with Native UI has shifted over to
React Native, which should have full support for all of that.

------
em3rgent0rdr
Even though they rewrote to cross-platform API, they still don't provide linux
support yet...

I also worry about performance and file size with Electron. Why couldn't they
just use a native cross-platform toolkit from the start?

~~~
LeoNatan25
Cheaper that way. Get some web "devs" to also write a "desktop" "app" in
React.

------
akhatri_aus
Can't drag and drop a repository into the app. It's often the small things &
little touches that are the problem with non native apps.

~~~
aroman
I mean, this is just as easy to do with electron as it is with a native app.
The fact that they didn't implement doesn't mean it isn't possible :-)

~~~
ridiculous_fish
Is it actually the case that this is "just as easy to do?"

~~~
adnzzzzZ
[http://ourcodeworld.com/articles/read/288/how-to-handle-
drag...](http://ourcodeworld.com/articles/read/288/how-to-handle-drag-and-
drop-file-feature-in-electron-framework)

Second result I found on Google

~~~
ridiculous_fish
Based on that link, Electron drag and drop seems extremely limited compared to
what native APIs provide:

1\. No way to declare what drop types you accept

2\. No way to validate the contents of the drop before it occurs

3\. No way to provide a visual indication of the action of the drop (copy,
move, link...)

4\. No way to generate a file drag

5\. No drag promises

6\. No custom drag images

This seems like the typical web development story: quick to build a low-
quality implementation, impossible to build a good one.

~~~
bhanu423
How to solve the issues above: Just listen to 'ondrop' event on body and store
the path of the file and call event.preventDefault() to prevent the file
loading. Now I think all of your issues are solved:

>1: You can now filter the extensions as per your requirements

>2: Now you can load the file separately and verify the content as per your
satisfaction using the fs module available in electron

>3: You can use: ondragover and ondragend events to facilitate ui feedback

>4: Not sure what you mean by file drag, but I cannot think of anything that
cannot be implemented here.

>5: Not sure what do you want here.

>6: Not inbuilt but can be built easily.

Editors like atom and vscode have very good file-drop functionality and have
image viewer apart from many other goodies. Depending on your familiarity with
js, these things are more or less trivial to implement. Github team must have
a different feature-set in mind that unfortunately didn't had drag and drop
functionality for their first release. If anyone really wants the feature, the
better way is to leave a feedback in app or open a issue (not sure if either
exists).

------
qarioz
> JavaScript. It’s the lingua franca of programming.

I don't know how I feel about that statement. One one side I want to scream
"C", but with each passing day it's getting there.

------
relyks
Why is Java not considered as a cross-platform solution?

~~~
flukus
Java on the desktop died because it didn't provide a native enough look and
feel and it performed too slowly. Now we just don't care about look and feel
and pretend every user has 16GB of RAM like the developer machines do.

~~~
pjmlp
Java on the desktop died because most developers were too lazy to learn how to
use Swing properly, while writing everything on the UI thread.

~~~
pssdbt
Example of a properly done Swing app? Not trolling, genuinely curious to see
what that looks like (code + result). I also assumed it was because they
perform terribly and look non-native.

~~~
pjmlp
Bitwig Studio, [https://www.bitwig.com/en/bitwig-
studio.html](https://www.bitwig.com/en/bitwig-studio.html)

Booksmart. [http://www.blurb.com/booksmart](http://www.blurb.com/booksmart)

Ultramixer, [http://www.ultramixer.com](http://www.ultramixer.com)

jAlbum, [https://jalbum.net/en/](https://jalbum.net/en/)

VRL Studio, [http://vrl-studio.mihosoft.eu/](http://vrl-studio.mihosoft.eu/)

Centigrade UI Components, [http://www.centigrade.de/en/products/bizlaf-stock-
look-and-f...](http://www.centigrade.de/en/products/bizlaf-stock-look-and-
feel)

Synthetica UI Components,
[http://www.javasoft.de/synthetica/](http://www.javasoft.de/synthetica/)

JGoodies UI Components, [http://www.jgoodies.com/products/smart-
client/](http://www.jgoodies.com/products/smart-client/)

SQL Developer from Oracle is also quite ok.

The sample applications developed on the "Filthy Rich Clients" book,
[http://filthyrichclients.org/](http://filthyrichclients.org/)

You can watch the related JavaONE 2008 session at

[http://www.oracle.com/technetwork/java/j1sessn-
jsp-155597.ht...](http://www.oracle.com/technetwork/java/j1sessn-
jsp-155597.html)

Oh and MATLAB is also a Swing application.

------
IncRnd
You are pushing the maintenance and testing from your teams onto your users.
Sure, you can easily have a multiplatform app this way, but your users suffer
for that. It _should_ be the other way around, instead of transferring the
cost of software engineering onto users.

------
pjmlp
Thankfully I stopped using the Github app long time ago, rather using the
native Tortoise one.

------
wjh_
Okay so, as much as we all want to complain about how awful Electron is for
battery life and just general efficiency, the facts are that it most likely is
going to stay - at least for a little while, considering how much is being
invested in it.

Instead of complaining about what it does, perhaps we could be trying to make
it more efficient, or make an alternative that solves the same problems
(perceived or otherwise) in a better way?

------
codesternews
This app has really have bad ui performance. Just check sourcetree. Atlassian
has done wonder full job at creating and making it. No offense but, They now
even have a chance to compete with it.

~~~
LeoNatan25
Check out Tower. Best git UI software for Mac.

~~~
SyneRyder
Tower is now also available for Windows too (as a native app):
[https://www.git-tower.com/](https://www.git-tower.com/)

------
cheez
I don't understand...

You have 4 developers.

Git isn't that hard.

C++ isn't that hard.

Just write it in C++ and use Qt. I know, I know. It isn't cool.

------
flukus
> If you’re making a native app, your tech stack choices are pretty limited.
> On the macOS side, you’ll use Xcode, Swift, and AppKit. On Windows, you’ll
> use Visual Studio, C#, and WPF or UWP.

I'm not sure they know what native means because c# is not native code and WPF
is not a native UI.

> To maintain parity across the codebases, we had to implement and design the
> same features twice. If we ever wanted to add Linux support, we’d have to do
> it all a third time. All this meant we had twice the work, twice the bugs,
> and far less time to build new features.

Nothing forced them not to share logic from the start, they could have done
that and still had a native UI on each platform. It only doubles the work if
100% of the work is in the UI.

~~~
microcolonel
Yeah, I'm genuinely surprised that "four native developers" didn't realize
that there is one native language which works great on all three platforms,
and has direct bindings to all of the platform UI toolkits...

~~~
flukus
There isn't one that I know of. A language like c++ though would compile to a
native library on each platform and allow them to share logic between 3 front
ends in the same or a very similar language.

~~~
microcolonel
That's mostly what I meant. I don't particularly think it's a good idea to
share UI code between platforms as different as macOS and Windows. I'm sure
there will be serious integration regressions with the new version.

------
z3t4
You can do an Electron app without electron!

This is how you run different browsers in chrome-less mode: iexplore -k %URL%,
firefox -chrome %URL%, chrome --app="%URL%"

Launch nodejs, then launch the browser, and for the features not supported in
the browser, have it talk to nodejs. You now have both a desktop app and a
cloud app if you like. You could basically have the exact same code running on
for example Github.com and on the desktop.

There are advantages with Electron/nw.js though, like only having to support
_one_ "browser" that makes it possible to use bleeding edge features.

------
murukesh_s
I think this is great, especially for the electron ecosystem as github
engineers are directly involved in making production apps on the stack(other
than atom)

The cross platform advantage(time & maintenance effort) that electron gives is
immense. The overhead is very minimal and we can build some great apps like
vscode and the likes have shown.

~~~
stephenr
> The overhead is very minimal

Compared to what exactly? Because compared to an app built using the platform
SDK's, Electron is never "minimal" in anything, except perhaps "integration"
or "accessibility".

~~~
murukesh_s
Don't want to create a flame war, but let's look at real world stats, at least
for me, the overhead is very minimal. Look at the screenshot of my macbook pro
2013. I am running vscode for 100% of my development time. In the graph, I
have sorted the processes by CPU Time (Not just CPU). That is the average
amount of CPU used by each process over time. I have also included memory
usage. While the total memory comes to around 400mb, it's still lesser than
some Java based IDEs. For an app that I use as my main IDE, the resource usage
(CPU) is very minimal.

cpu usage
[https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0](https://www.dropbox.com/s/x743mmnqvnffja1/cpu.png?dl=0)

memory usage
[https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0](https://www.dropbox.com/s/twss8stdl12j83n/memory.png?dl=0)

~~~
stephenr
> it's still lesser than some Java based IDEs

Once you have Java based IDE's like the IntellJ/IDEA family etc in the mix,
you can't really call editors like VSCode/Atom/etc an IDE. The functionality
is nowhere near the same.

I don't _like_ relying on a Java tool. IDEA Ultimate uses a _lot_ of memory.
But it has a _lot_ of functionality too, which is why I accept the JVM
overhead. If someone produced a fully featured IDE (or even plugins e.g. for
Xcode) for macOS that was a true native app, I'd use that. But that doesn't
exist.

The options for me are: true native editors (Coda, TextMate, CotEdit, etc),
web-page-as-an-app, slightly more featured editors (VS Code, Atom), fully
featured IDEs (IntelliJ IDEA, maybe ActiveState KomodoIDE, possibly a
NetBeans/etc setup).

~~~
murukesh_s
> But it has a lot of functionality too, which is why I accept the JVM
> overhead

This is something that can be replicated with additional plugins. To be
honest, I have used Eclipse and Netbeans extensively. They do have additional
features, but not a lot.

If I am not wrong, VSCode ships with a debugger and syntax highlighter built-
in. There are tons of other plugins to add the extra functionality like GIT
integration, built-in terminal, more syntax highlighting etc (Nowadays, you
name it you have it). Even if you add 10 such plugins you are noway near a JVM
based IDE on memory consumption. Also Netbeaans is very very slow, atleast in
perception. Eclipse feels snappy, due to the use of SWT, but its a memory hog.

~~~
stephenr
I'm talking about stuff like:

\- Static analysis of code

    
    
      - Find calls to methods
    
      - Find usage of Classes/Interfaces/Variables
    
      - Alert when classes don't properly implement interfaces/abstract methods
    
      - Detect language-level syntax/feature changes/compatibility
    

\- Code refactoring

    
    
      - Rename variables/classes/interfaces
    
      - Change method signatures
    
      - Pull/push methods to parent/child classes

~~~
murukesh_s
Most of the above features dont need constant monitoring, so adding a plugin
for that purpose won't add any large overhead. And many plugins do similar
tasks in Atom/VSCode with minimal overhead. Even for continuous monitoring of
filesystem, node.js is very fast(there are many native plugins).

Disclaimer: I am developing an IDE using electron for a visual programming
language. I have worked on JRE based IDE toolkits before (SWT/Swing). Both the
runtime performance and developer experience appear better to me. You can of
course get better performance if you directly write in the platforms native
stack, but my point is that JRE is only as good as a properly architected
Electron stack.

~~~
stephenr
> Most of the above features don't need constant monitoring

The above features flat out aren't available in the Electron based editors
people like to call IDE's now.

Im not talking about how possible it is to implement them - I'm explaining why
I accept the overhead of a JVM based IDE, but won't accept an Electron one:
the JVM one (JetBrains IDEA) _has_ those features, none of the other options
on macOS have them.

