How Four Native Developers Wrote an Electron App | Hacker News Reader

How Four Native Developers Wrote an Electron App

githubengineering.com

119 pointsjoeyespo172 comments

GitHub calls this electron app "the new native" on 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.

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.

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

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

You just summed up the history of the industry.

And by then we'll have our pick of Neutrino, Electrode, and Amber as the new, shiny, laggy way to build "native" apps.

Perhaps you've missed the memo?

https://www.technologyreview.com/s/601441/moores-law-is-dead...

https://arstechnica.com/information-technology/2016/02/moore...

This is not true, nor has it been historically. Since 2001, you can make hover effects in <16ms.

You didn't say anything that disagrees with the parent.

Except if you mean that you could do it since 2001 on web pages in < 16ms -- which is clearly not the case.

However it is a beta release which implies some rough edges.

What is rubber band scrolling?

Edit: thanks for the replies.

It's the bounce you see if you try to scroll past the end of some content. See this image for an example http://blog.christoffer.me/content/images/2015/12/2_touch_ad...

When you scroll past the very top or very bottom of a page and it bounces and springs back.

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/

I avoid Electron apps for the above reasons. On a laptop they will eat your battery dry.

It reminds me of "Adobe Air", all over again.

is anything being done to improve this? would it be reasonable to expect this to change in the future?

No. JS is not statically typed and that prevents the vast majority of optimizations and better memory efficiency(native types underneath).

Not to mention the levels of indirection that also impact java and c# performance, despite 20 years of people saying "compilers will improve".

The level of indirection is minimal, basically c++ with garbage collection. That's why they're statically typed.

Both perform within a small margin of native code, with the major exceptions of vector instructions that aren't supported by all CPU's

In an artificial benchmark they are pretty similar, but in real world idiomatic code they are very different to c++. Nearly everything is on the heap so you've got pointers everywhere, dynamic data structures are used everywhere, virtual functions (particularly with java) and interfaces. There's is a reason java was so much slower than native code 20 years ago and that gap has been bridged by CPU progress more then compiler progress.

You are forgetting the crappy programmers as well.

I lost count how many times I have reviewed code where a for loop is used instead of System.arrayCopy().

Or the times I have seen code that my CS data structures teacher would probably give a plain 0, even if done in C.

It's probably for the best those people aren't writing c/c++ ;)

I'd love to make them code in rust, their inability to write code, to even copy/paste it will save so many maintenance problems.

This just isn't true. There's many Java ports of C/C++ applications and benchmarks are usually within 30%.

For the easy tasks. Try a CPU heavy C/C++ app -- like an audio/video editor, number crunching of any kind, etc.

Like I said, the major exception is SIMD instructions. AV and heavy math are a tiny fraction of applications. For these you can use JNI.

There is precedent for this in Netty where they use a native poll mode driver and everything else Java, and it performs about as fast as pure C code on Techempower benchmarks

note: the article mentions that the app is written in TypeScript which _is_ statically typed and therefore many of these optimizations are at least possible if not in place

He was probably talking about runtime optimizations done by CLR and JVM; this kind of optimizations is impossible even when you use TypeScript.

I see somebody has never heard of JIT compilers.

Natives apps are native for a reason, right? If there one extra layer of abstraction to run your code, there is going to be a performance hit.

The complaint is that the layer of abstraction is too thick.

Other cross platform solutions are not nearly as heavy (though they might have other issues).

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.

The editor that became known for consuming nontrivial amounts of CPU for blinking the cursor, something computers could do since they replaced paper tapes with screens.

That issue was limited to mac, as far as I know

*became known to you for a big that consumed nontrivial amounts of CPU

- Many people know VS Code before that

- It was a bug, not something inherent to Electron

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.

oh heck, I get that in Visual Studio, IntelliJ, and XCode. Not saying I'm in love with electron apps, but they have their place. (I once wrote a trivial app using Adobe Air, also consumed hundreds of megs of ran, all the same issues as Electron...it just seems like the nature of the beast)

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.

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

Do you have any kind of anti-virus tool running? I experienced several slowdowns for autocompletion in VSCode, which turned away once Avira was deactivated. I think VsCode (and especially some plugins like the language services) are working with lots of files in the background, which got slowed down due to the filtering of these tools.

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

VSCode just makes an tolerably-fast Electron app. Still doesn't solve the CPU usage, battery hungrinees, and memory hoginess of the platform.

I created an issue reporting the main problem caused by Electron for them: https://github.com/desktop/desktop/issues/1641

Maybe they'll figure something out.

Nice. I came here to ask, "What exactly is Chrome doing while using CPU when the app is idle?" Answering this would leave the memory usage and installer size issues but make the architecture tenable for more applications.

This would be fine for an app you ran occasionally but for something that's likely to be running all day it isn't good.

Usefulness amd usability trumps efficiency every time in any user facing application.

Electron enables a very large population of programmers and designers to produce useful applications using very evolved UI tech which can be multiplatform with nothing more than zipping with the right runtime - much easier than "native" or arcane cross platform UI libraries.

So of course people will develop useful stuff on it amd people will use it.

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.

Anyone know what the telegram Desktop team uses?

C++: https://github.com/telegramdesktop/tdesktop

Git itself isn't quite cross-platform - it's very backwards-compatible on *nix, yes, but it would be a stretch to call it native Windows software. There's a reason the Git for Windows project bundles MSYS2 ;)

Today I learned! Thanks :)

> 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

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

I haven't touched Java UIs since university - back then we were taught about AWT and Swing. I remember being unhappy with AWT because it never worked right and was inflexible - and I was equally unhappy with Swing because it never looked or felt native - and for some reason window resize redrawing was done slowly. I first heard about SWT more recently and it brought back my faith in the native desktop, but I've never used it.

In your experience, how well does SWT handle the differences between platforms (fundamental things like macOS vs Windows' menu-bars, to smaller things such as the arrangement of buttons in a dialog)?

What is the graphics performance like too?

Yes AWT/Swing was bloated, buggy and slow - Sun's poor UI implementation really doomed Java on the desktop.

But then IBM came along and did it right: SWT is super fast and lightweight because it simply calls underlying native API like Cocoa or Win32. It's always been super fast even when I started 10 years ago.

Layout of components on screen is straightforward and much easier than Swing. (Just use GridLayout 90% of the time). I have to specify different margins and fonts for Mac and Windows and you will need to change the order of the OK/Save and Cancel buttons, but that's not a big problem. (In fact there is a library called JFace which can do alot of this stuff for you, but it comes with a lot of baggage so you may just be better off with pure SWT).

The difference in menu bars is perfectly handled by SWT, and it includes Mac-specific menu options like having the Preferences and Quit menu item in the application menu.

You may notice a loss of fidelity here and there - for example, on Mac my error messages don't look exactly like a standard Mac error dialog: http://imgur.com/a/znehj I'm sure I could fix this with 'if(mac)' and breaking out to the native OS, but in 10 years it's never been a high priority for me.

--------------------------

By the way, here's a juicy story about why IBM developed SWT: http://www.mail-archive.com/jug-discussion@tucson-jug.org/ms...

A few choice quotes:

"At IBM we hated Swing from day one. Big, buggy, and looks crap"

"All of the IBM developers are the same crowd who used to work with Smalltalk, and we reluctantly under management orders built our WebSphere Studio tools using Swing. It was a terrible, buggy, monster. In our initial previews when it was demo'd against Microsoft Visual Studio products all our users hated it just because of how it looked, never mind what it let you do"

"Swing was so badly broken deep down in the way it reads windows events...they read their event queue in a way that can leave memory holes so we had to have our own loop polling the windows event queue to do this correctly.....We tried over and over to get Sun to fix this but Amy just didn't understand this"

"Swing is like Java deciding not to do native IO using the operating system, but instead to use the disk motor arm API and read and write the disk data segments themselves."

The UI situation for Java is so confusing. Why are you using SWT and not JavaFX or Swing or...?

In 2017, where do you start?

JavaFX is the way to go.

If you also need to target Android, then it is a bit harder.

Yes there is now a port of OpenJavaFX to it but it was still a bit of work in progress, specially since it requires Java 8.

Probably the best way is to use MVVM and have separate views for JavaFX and Android.

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?

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/

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

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

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

Im definitely anti-jvm. I'm also a daily user of IDEA. Nothing else comes close to the same level of functionality with the breadth of language support available, on macos.

As one who has experience with multiple UI frameworks, and 2 years of SWT i can only say that it is on par with Gtk+/C Gui development experience. It is terrible, with those int constants all around the API, not groupped in any intuitive way, to communicate what should be Or-able with what. The widgets are stupid, as to be native everywhere they usually provide only the common features.

Swing is way better choice, if you are on Java and want nice, feature rich, and somewhat (screen size) responsive UI.

I don't know JavaFx, but it may be worth a try also.

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.

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.

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.

> 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.

When I was developing the Linux version of a piece of software I make (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.

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.

Sourcetree, a git/hg client, was written in c# for windows and Objective-C for Mac: https://community.atlassian.com/t5/Questions/What-technologi...

same goes for Tower (https://www.git-tower.com)

GitUp is awesome too. 100% native Mac app.

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.

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.)

Thanks for the detailed answer. I was thinking of writing a few small apps in C++ on Windows, but may now check out C# for that instead.

> 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...

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.

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.

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.

I think gitkraken is a better git client than sourcetree, and it also works on electron.

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?

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

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.

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 :-)

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

http://ourcodeworld.com/articles/read/288/how-to-handle-drag...

Second result I found on Google

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.

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).

> quick to build a low-quality implementation, impossible to build a good one.

You just gave me a new quote to use. :)

yes...

It's pretty easy to implement drag and drop on web apps, in fact there are specific JS DOM APIs and various libraries to handle that.

Onto the app icon too?

> 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.

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

My guess is they didn't have much in-house expertise for Java and just neglected to mention it in the write-up.

Also, Java isn't cool.

And JS is?

Sadly, it appears so.

:-(

This is so backwards.

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.

JavaFX is actually pretty good and the performance is much better than Electron.

> and pretend every user has 16GB of RAM

I currently have two separate JetBrains IDEs each with multiple projects opened on my 8 GB MacBook Air. Doesn't seem to be a problem.

I was talking more historically. Java was slow and fell out of favor at a time when the average desktop had 16MB of RAM (and many had less). It never recovered from that perception and was pretty much confined to server side tasks.

Now developers are working on electron apps and the average machine with 2GB makes an electron app today feel like a java one from 20 years ago.

All the IntelliJ environments are Java based and seem reasonably well-liked. So it seems alive and well, in its niche.

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.

I don't buy that excuse, it never affected winforms or vb take-up that often had the same issue.

First of all you are talking about OS SDKs, first class platform languages designed by the OS owners.

Second anyone that bothered reading Filthy Rich Clients book should be capable of doing a WinForms like experience.

What I conceed is that Swing has the wrong defaults and requires more UI design skills from devs than Forms does.

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.

The IntelliJ stuff is Swing IIRC, but not open source.

jEdit, IIRC, was often mentioned as a properly written java GUI app, I think it's Swing, but I might be wrong.

EDIT: IDEA code is apparently open https://github.com/JetBrains/intellij-community

Bitwig Studio, https://www.bitwig.com/en/bitwig-studio.html

Booksmart. http://www.blurb.com/booksmart

Ultramixer, http://www.ultramixer.com

jAlbum, https://jalbum.net/en/

VRL Studio, http://vrl-studio.mihosoft.eu/

Centigrade UI Components, http://www.centigrade.de/en/products/bizlaf-stock-look-and-f...

Synthetica UI Components, http://www.javasoft.de/synthetica/

JGoodies UI Components, 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/

You can watch the related JavaONE 2008 session at

http://www.oracle.com/technetwork/java/j1sessn-jsp-155597.ht...

Oh and MATLAB is also a Swing application.

Has the latter problem been solved? Jvm startup times still seem like an issue to me.

The JVM isn't actually slow to start [1] (albeit it does start about 3x-4x slower than python, ruby, or node) [2]. Most of the slow startup in a JVM-based application is in classloading [3] or waiting for your chosen framework to initialize [4] before the control is handed to your custom code.

[1] https://purelyfunctional.tv/article/the-legend-of-long-jvm-s... [2] https://dev.clojure.org/display/design/Improving+Clojure+Sta... [3] http://blog.ndk.io/clojure-bootstrapping.html [4] https://jkutner.github.io/2015/12/01/java-boot-time.html

> Java on the desktop died because it didn't provide a native enough look and feel and it performed too slowly

Not to mention end users needed to download and update hefty runtimes in order to run the software.

For clients, JS runtimes offer a more polished experience on average than Java. That's not because of anything really intrinsic to the languages or platforms - it's just worked out that there is a lot of Java server code and a lot of JS client code, and consequently more catering to either of those extremes.

> JS runtimes offer a more polished experience on average than Java

[Citation needed]

They're both non-ideal solutions, but there is one caveat:

java tends to be the language of choice for companies like JetBrains, that want to deliver an awesome experience on all platforms, and go as far as shipping a custom JVM to make that happen.

javascript (read Electron) tends to be the language of choice for web developers who want to see their fancy icon in the Dock/Menubar.

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.

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

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?

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.

Check out Tower. Best git UI software for Mac.

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

Also GitUp!

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.

> 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.

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...

You mean several native languages with multiple multi-platform ways to create native UI.

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.

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.

The only env. i know is Lazarus-ide and Freepascal

> c# is not native code

Correct. C# does not ahead-of-time compile to hardware machine code (e.g. x86).

> WPF is not a native UI

How do you classify "native" vs "non-native" UI?

> How do you classify "native" vs "non-native" UI?

Not OP, but presumably WPF can be considered non-native because it relies upon the .Net stack.

Not just .net (I think it's all c underneath), I'd consider winforms with c# to be a native UI (but not native code) because it's just a .net wrapper around win32.

Is UWP UI "native"?

Yes, although the windows desktop situation is such a clusterfuck that I could make a case that it's not ;) It all depends on if you consider the full desktop or the metro interface to be the native one.

A native UI is one that uses that platforms (or desktop environment) native toolkit, that's win32 on windows, qt on KDE, gtk on gnome and cocoa (or whatever it is today) on Mac.

WPF is it's own toolkit built in directx, it's as native as swing. WPF sits at the same abstraction level as most games, would you consider the main menu in GTA to be a native one?

would you consider the main menu in GTA to be a native one?

Does a WPF menu (and WPF-based apps in general) integrate with the systemwide conventions and settings for things like keyboard shortcuts, default font, etc? Is it a first-class UI toolkit for the system? My impression was it is supposed to be, in a way GTA's UI (or Swing) is not.

> Does a WPF menu (and WPF-based apps in general) integrate with the systemwide conventions and settings for things like keyboard shortcuts, default font, etc?

About as well as swing ever did, no where near as good as Qt does, I think we'd all agree qt is not the native UI of windows.

Then again, it is hard to judge. Not a lot of win32 apps seem to follow system wide settings either, even the MS ones.

About as well as swing ever did

Really? It's just not the impression I get, granted it's been a while since I've used Windows for anything other than to, well, play a bit of GTA. I remember paint.net being a thing (seems it's still around) and it looked and behaved like a Windows app. Qt apps look instantly recognizable and fugly to me on any platform. It's hard to believe that WPF apps had or still have, say, the font-rendering problems Swing apps had or were missing access to affordances like control over the tray icon, etc.

The reason I'm skeptical is that WPF was very much intended to be a first-class Windows-specific ui toolkit. You're telling me it's worse than cross-platform toolkits with all of their necessary design and implementation compromises.

Edit: Oh! I figured out where I was confused. WPF and Winforms. Not the same thing.

On another note, the classic opening Window of Unity games (when you select resolution and quality) looks remarkably native!

Examples: My Summer Car, Sol 0, Software Inc.

Win32 is essentially deprecated and the native toolkit from Windows 8 on is the WinRT components/engines in "Windows.UI.*" which natively speak XAML (and natively here means these are C++ components baked into the OS). WPF has much more in common with the modern Windows.UI toolkit than Win32 does.

DirectX is at the same level of abstraction as Win32's Graphic Device Interface (GDI) and Hardware Abstraction Layer (HAL) that the rest of Win32's "native toolkit" was built on top of; Windows.UI is just as "native" as Win32 ever was. It should not be a surprise that the hardware abstraction toolkit beat into performance submission by performance demanding games is the new native layer for Windows. The surprise should be how long it has taken to make the transition across. (Avalon promised it back in Vista and WPF was the closest to delivering it. Windows 8 finally delivered on the Avalon promise.)

The problem is they didn't provide backward compatibility for Windows.UI. Until windows 7 is dead win32 is the only native option.

I think to some extent they felt WPF was a strong enough backward compatibility story. Windows 7 supports WPF well. There is a cross-over between WPF XAML and UWP XAML and it is possible to support both with a lot of code shared and even some XAML shared.

Of course, there have been bumps in the road in the compatibility story between the two XAML environments. .NET Standard 2.0 will help a ton (in the very near future), deeply increasing the amount of .NET code that can be shared between the environments. XAML Standard 1.0 (in the slightly further future) will help a lot, in particular the fact that Xamarin.Forms is planning to implement a WPF renderer for sharing a much larger portion of XAML across every platform.

Sure it does.

Ever heard of NGEN, Mono-aot, .NET MDIL, .NET Native?

To what degree are they native? I wouldn't consider something native just because it bundles the VM into the exe.

To the same degree as C is native, there isn't any VM doing JIT compilation.

All straight sugar free Assembly instructions.

Now if you mixing the notions of VM and runtime, even C has a runtime called crt0 on most UNIX systems.

> Now if you mixing the notions of VM and runtime, even C has a runtime called crt0 on most UNIX systems.

I was mixing them up. The line seems be kind of blurry though once you start embedding garbage collectors though, then again the GC could just as easily be in an external library.

> c# is not native code and WPF is not a native UI

"Native" confusingly has two different commonly used meanings. The one you seem to think is the only meaning distinguishes VM from non-VM runtime code (where C# is non-native). This meaning is the N in Android NDK.

The other common usage is "the preferred local platform specific language and dev stack", eg "A native Android app" which usually means "written in Java compiled to dalvik/art" distinguishing from a webapp or an app that is just a packaged webview.

I always interpret "native" to mean "without the use of an intermediary virtual machine." I assume my definition is overly simplistic, but am I incorrect?

Android is a bit weird because the platform is the VM that you're targeting. The same goes for Chromebooks, html and JavaScript are native there.

The terminology for "native" used in the blog post is inexact (actually, incorrect), but consistent with how the casual usage of the term has drifted due to the competition from the 'web technologies' stack. In this usage, "native" means non-webview; and/or non-HTML5/JS/CSS-bundled-with-the-entire-browser-runtime.

Often it's also a byword for the platform-preferred first-party stack, making the argument somewhat tautological: of course there's a limited selection of first-party preferred stacks on every platform.

I'm guessing this usage is a contraction of the term "platform-native".

> In this usage, "native" means non-webview

I wonder what the authours would think of C++, Qt and webviews?

C# compiles to native code since Windows 8, when targeting store applications.

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.

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.

>The overhead is very minimal

You're still using JS, unless you're compiling modules for node.js.

I find node.js pretty fast. The V8 engine does compile it to native during the run time using a JIT compiler. While it is not quite up to the level of java, it is comparable. The major lacking is no thread support, but it is a boon in many cases as tracking down runtime bugs in multi threaded environments is sometimes very tough. Threads can be simulated using child processes to some extend, but its the only major drawback as far as i have encountered.

While nodejs is fast enough, Electron and apps built on it aren't fast. Electron is a mix of Chromium and nodejs. Chromium's rendering isn't meant to be used as desktop app. Especially for laptops. I have a MacBook pro mid 2010 with two GPUs. Integrated GPU uses less battery energy than discrete one. And every Chromium app switches GPU to discrete one and causes battery drain.

> Chromium's rendering isn't meant to be used as desktop app.

Yes, it is. That was pretty much the entire point of Google making Chrome (to make web apps have acceptable parity with desktop apps), and the entire premise of them building on Chrome with ChromeOS.

Now, it may not satisfy you in that role, but it absolutely is meant for it.

Good point. People are bashing Electron and chromium in general. But they do forget JVM based IDEs had the same problem. Rather than bashing Electron, if we can figure out to make it more leaner and faster, it would be much better.

"We"? You mean people that know C++ and low level native APIs, right? Which is decidedly not you. You are building a "hackable" "node.js" "npm" "app". The problem is, people who are indeed capable of making some improvements, including people on the V8 and WebKit teams themselves, do not believe in what these tools attempt to accomplish. (Listen to Don Melton's interviews on the subject, for example.)

I say "some improvements, as the problem cannot be solved completely; you'd understand why if you understood the underlying technology.

> 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".

Minimal regard for the users' system resources? Minimal chance of being used because the user notices their laptop grinds to a halt and then runs out of power when the app is opened?

Well played.

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

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

> 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).

> 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.

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

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.

> 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.

VS Code has less features then the main Visual Studio and Intellij IDEs, also I don't think the problem is the language but Electron. About memory uisage, garbage collected languages will show a larger memory usage because they will not start cleanup when an object is freed, it waits until it needs free memory and then it starts the GC and in Java I think you can specify options to control this,CPU usage is more important since that uses battery/enrgy

JVM has the same problem, isn't it?. In fact VSCode even after extending it with lots of plugin to make it a full-fledged IDE, feels more responsive and relatively lean on memory usage compared to full-fledged (JVM based) IDEs.

If you think VS Code with all plugins is an IDE at the level of Intellij or the main Vs then why VS still exists? Maybe you did not used this large IDEs so you don't know what the features or speed is, maybe your projects work good enough with VS Code or a plain text editor(not all projects need a big IDE). My opinion is that Electron needs more optimizations, and the developers that use it need better tools and need to also care more about the CPU usage. Even if you would use c and compile to web assembly to run n electron the problems would still be there so not the Language is at fault but the implementation.

Reply on news.ycombinator.com