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.
Except if you mean that you could do it since 2001 on web pages in < 16ms -- which is clearly not the case.
Edit: thanks for the replies.
I'm reminded of this article , about just how bad Electron is compared to native apps.
It reminds me of "Adobe Air", all over again.
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.
- Many people know VS Code before that
- It was a bug, not something inherent to Electron
VSCode just makes an tolerably-fast Electron app. Still doesn't solve the CPU usage, battery hungrinees, and memory hoginess of the platform.
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.
Maybe they'll figure something out.
Other cross platform solutions are not nearly as heavy (though they might have other issues).
Both perform within a small margin of native code, with the major exceptions of vector instructions that aren't supported by all CPU's
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.
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.
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
"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.
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:
I'd say about 95% of my UI code is platform independent.
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?
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://firstname.lastname@example.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."
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.
In 2017, where do you start?
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 wonder how Jetbrains manage to handle all the anti-JVM/Java crowd.
BTW, where can I trial your software?
You can try it here: https://www.solaraccounts.co.uk/
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.
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.
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.
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.
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.
I switched to Qt and was pleasantly surprised at how nice it was to use.
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.)
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.
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.
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 also worry about performance and file size with Electron. Why couldn't they just use a native cross-platform toolkit from the start?
Second result I found on Google
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.
>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).
You just gave me a new quote to use. :)
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.
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.
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.
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
Oh and MATLAB is also a Swing application.
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
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.
Not to mention end users needed to download and update hefty runtimes in order to run the software.
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.
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?
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.
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.
"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.
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".
I wonder what the authours would think of C++, Qt and webviews?
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?
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?
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.
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.
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.
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.)
Examples: My Summer Car, Sol 0, Software Inc.
Not OP, but presumably WPF can be considered non-native because it relies upon the .Net stack.
Ever heard of NGEN, Mono-aot, .NET MDIL, .NET Native?
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.
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.
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.
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.
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".
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).
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.
- 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
- Rename variables/classes/interfaces
- Change method signatures
- Pull/push methods to parent/child classes
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.
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.
You're still using JS, unless you're compiling modules for node.js.
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.
I say "some improvements, as the problem cannot be solved completely; you'd understand why if you understood the underlying technology.