Our early prototypes of Nylas N1 were built on Angular in the browser, and then Adobe Brackets, but we couldn't really get it to a level that felt great and worked offline. It wasn't until we decided to fork Atom (the previous base of Electron) that we started breaking past the "uncanny valley" of wrapped webviews and discovered an application stack that allowed quick cross-platform deployment alongside native code modules.
After building on Electron/AtomShell for 18 months and seeing the community grow, I can definitely say there is something really special here. We've still got a lot of work to do on N1 (email is hard!) but we're confident Electron is the right platform for this type of extensible app.
A secondary reason we open sourced N1 was to serve as a reference implementation of a large Electron app. There still isn't a great resource for "best practices" when creating complex Electron apps with lots of moving parts. Now that we've hit 1.0, I think it's time to change that!
If you have a free afternoon, I definitely recommend playing around with Electron. It will likely change your outlook on the future of desktop software. :)
Can i use it as a basic Mail.app/Thunderbird alternative, without leaking my personal data to your cloud?
This allows the client to be thin, since it's only using the APIs and is shielded from the intricacies of dealing with mail protocols like IMAP and SMTP. It also allows Nylas to offer a single API that works across all your email.
It's not ideal for some apps, but it's completely serviceable for most apps.
* Office being a behemoth doesn't give a right to other apps to be whales.
* 100MB is just the runtime. Then you've got your application running on top of that, using whatever memory you want. The C/C++ runtime is not 100MB.
* Those 7GB probably include examples, layouts, whatever. Actual content. As opposed to Electron apps which are rarely more than just pretty interfaces making requests to a server. (With some high profile exceptions, like Atom, VSCode, ... Although they do send data to outside servers anyways :^))
* The Office suite is infinitely more complicated than anything done with Electron. That means features, technical debt, everything.
* Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook.
* Where did you get this 100MB metric? VS Code uses 24MB Private, 86MB shared and I've got a ton of extensions added.
* No, most electron apps are offline apps.
* I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose?
* O'rly? Office 2016 add ins are built in JS, and there are built-in "addins"
That is excel. With all its features. 100MB is Electron's base footprint. Running absolutely nothing. Write something as complex as excel with the same feature set, you're going to be way over 142MB with a blank workbook ;)
The 100MB metric comes from experimentation with both electron and electron based apps (VS Code, Atom, N1, Slack, ...). The main process hovers at around 80MB, but you also have countless node processes running. When node will be a default on machines (please, never), I'll stop adding those processes to the total, but meanwhile, they do count.
>I doubt it. Creating performant HTML layouts and WebGL rendering all verified by independent 3rd party test suites is hard, dude. If someone came to you and said "Build a HTML engine or build Word" which would you choose?
A) The electron developers do not develop a rendering engine. They do not develop a JS VM either. They develop a toolkit for desktop apps, which uses nodejs (which is highly dependent on Google not pulling the plug on V8) as well as Blink (which is highly dependent on Google). While I am not discounting their work, they are absolutely not the ones with their hands in the engine internals.
B) I would honestly build a rendering engine. Word has 25 years of backwards compatibility to keep, features and integrations with lots of other office software, etc. Rendering engines have a clear and defined spec. Microsoft hasn't clearly defined the DOCX spec (well, they did, but keep adding undocumented surprises. Just like XLS :^).
C) I'd ask for a team, because no single human being can replicate the feature set of either in his lifetime.
Add-ins in JS? Sure, run them in an another thread and keep them out of performant code and we'll be friends.
You get 2 window bars, and 2 toolbars, nested in each other.
It might be "best practices" on Mac, maybe even on Windows, but it definitely looks out of place on Linux. Especially when compared to native Qt apps.
Maybe detect the platform and use native icon packs when available?
Anyways it's amazing how good Linux have become that we could complain of such minor things ;)
Even Swing and JavaFX manage to make better looking, faster running, easier to code UI apps, which can be distributed smaller (the Java Runtime, thanks to Jigsaw, is smaller than the node+Chrome runtime of electron)
By asking for a "Linux native application", you would need to create forks for GTK/Qt theming at the minimum and change the appearance altogether. It's just an absurd request really. One thing Electron does not do well is per-system graphical elements. It renders the same on every system so you either have a unique application design or you're conforming more to Window, Mac, or GNU/Linux. Or doom yourself to an old stale design, which is bland enough to fit in every category, but isn't the aim of the project.
Most GTK apps work nicely under Qt (although this is very suboptimal), but especially Qt apps look native everywhere. From windows to mac to KDE-environments to Gtk-environments.
Most other toolkits, as you mentioned, don’t look native in many places, but Qt natively supports the CDE style, the Motif style, all different Windows and Mac styles, etc.
A Qt app looks native on Mac OSX, on Solaris, under Gnome, under KDE, under Windows XP, under Windows 10.
That’s why I avoid apps that aren’t either native or Qt anywhere, no matter if I am running Gnome or Windows, KDE or Mac.
Incidentally, nice looking desktop! Which distribution is that, if I may ask?
The wallpaper is from http://imgur.com/gallery/dbELn
Thanks for the work you are doing here, I feel that Email is one area that could use a lot of work.
And you can read our blog post about announcing the pricing: https://nylas.com/blog/nylas-pro/
We haven't yet shipped the version which allows you to upgrade, but it's coming shortly.
Might be worth having a Pricing link/button next to download, and from the Free column, to the download screen.
Also, since the data is all in your cloud, would be nice to have a "web" version, so that I could use the app without needing to install. That would be ideal for me, a web-mail app that I can manage all my accounts from anywhere, even when I'm not on my home computer.
Just a few thoughts.
Electron is the cancer that is killing desktop computing.
Then someone at GitHub had the bright idea to take this "winning" concept and apply it to a developer's text editor, of all things! I still cannot fathom how Atom can have more than 3 users. Every time I've tried it, I've ditched it after 30 seconds. Slooooooooooow!
Fast-forward to 2016: now I see new Electron apps popping up every other day. Even something as simple as a text-only WhatsApp IM client, which could be written in a dozen of C++ files, is a bloated monstrosity that eats RAM for breakfast and contains an entire Node.js interpreter and a Webkit layout engine.
Cancer, I say!
Kill it with fire!
Perhaps the cancer is the fact the desktop development community has had decades to settle on a decent cross-platform 'native' toolkit and completely failed.
Perhaps the cancer is 'native' developers spouting 'native is better' hyperbole, ignorant of the fact these supposedly better 'native' toolkits have been web-influenced for a long time.
- XAML from C#/WPF land being strongly influenced by HTML and CSS.
- Android XML being strongly influenced by HTML and CSS.
- Qt Quick being strongly influenced by JS and CSS.
- GTK+ embracing JS and CSS3.
- Everything else being awful procedural C++. Good luck maintaining that.
And all have massively inferior developer tools than Chrome devtools and/or far worse abstractions for the scene-graph/tree of elements than the much-derided yet very powerful DOM.
Native desktop is a mess. I'm glad we're seeing Electron expose it for the joke that it is.
You can hate web dev tech, but you can't claim that native desktop options are better. I won't be building apps 3 times or using any of these useless 'cross-platform' dev kits anytime soon, when I can build the same thing in Electron in a fraction of the time, and leverage the undeniably huge JS and CSS communities.
Also very tired of seeing devs use weasel-words like 'bloat' and neglect to put it into any context, like the fact that on the desktop 1. it ain't bloat if filesize is cheap, and 2. said filesize is comparable to the most capable cross-plat options you're supposedly arguing for (see Qt Quick).
Edit: Softened, expanded.
Maybe Electron has its own JS APIs that fix those issues, I don't know. But compared to making a traditional web app, it's a relief to use a real desktop API that actually has coverage of desktop capabilities.
 See the ridiculous lengths Atom went to just to figure out how wide a character is: http://blog.atom.io/2015/10/29/atom-1-1-is-out.html
That may be true for WinRT, but I did not mention WinRT. XAML/WPF were around a long time before that.
> Same with the HTML/CSS-style toolkits.
Not sure what you're referring to but no, I don't believe that's true for the projects I mentioned.
Your complaints with JS APIs are warranted, but won't apply to 90+% of apps. Still seems like an overall win to use Electron/NW.js over any other option currently.
Probably you are underestimating how complex is to build a GUI for different platforms and also underestimating how much browser technologies have been improved integrating zillion of years of experience.
Also, you can't compare how easy is to develop a desktop UI with Windows Forms in Visual Studio to how difficult is to build an HTML UI.
Presumably you're getting at platform-specific differences. I'd suggest these are no longer as important as once deemed. Pretty much all desktop platforms are currently looking dated with respect to their mobile counterparts. So anything that looks 'modern' across all of them (e.g. good design + Electron) actually feels like sweet relief.
(If you meant something else, please correct me).
>> ... and also underestimating how much browser technologies have been improved integrating zillion of years of experience.
No, that's absolutely the point that I'm making. I'm suggesting browser tech is superior, largely due to the insane amount of engineering effort piled into it by Google et al.
>> Also, you can't compare how easy is to develop a desktop UI with Windows Forms in Visual Studio to how difficult is to build an HTML UI.
Yes I can, having done both :)
Show me the tool that makes incredible simple to design that UI.
I say the two are comparable because, with talent applied, the HTML version looks better and works everywhere, so there's a net win for devs that embrace web.
As it stands, it's not a great use case for many types of applications, but I would say that it's good enough for most of them. Beyond this, people are building useful things with it quickly. Far more quickly than they would be able to if they were targeting a custom UI platform, or with a lower level language like C/C++ etc. All this with the ability to relatively easily build for Windows, OSX and Linux deployments.
I don't mind people using XML based UI composition, as it works pretty well. Flex, XAML, and many other UI builders are XML based, simply because the structure corresponds well to the rendering hierarchy of components, and allows for easier understanding of their relative interactions.
I am half surprised there isn't a path towards a ReactNative for Desktop (OSX, Windows, Linix) at this point, that is similar to Electron, Node/V8 core, but with a common/reduced component set that just works.
Not official though, but it's getting some use out there.
And then a user pointed out that Acrobat Reader can actually do that already .
HTML has been great to make the web great without microsoft attempt to monopolize it, but markup languages are useless as a file format you send across the internet.
Why? Because parsing text is, and will ALWAYS be slow. So either pre-parse html and put this in an OPEN binary file format, or burn it with fire.
Why can't investors and other developer take a damn hint that there is a reason smartphones use applications instead of web apps: html, dom, js, css all those things are slow and totally not well designed ! If you want to know more, start with that video that talks about the messy process that was HTML standardization https://www.youtube.com/watch?v=RH0o-QjnwDg
HTML is not a strict language, meaning it's EVEN SLOWER to parse.
Wake up sheeple (sorry that was unnecessary)
Native apps have a better foothold currently because mobile platforms had better support for their own native languages, than for sophisticated web runtimes like V8 at release.
If AT LEAST html would be a strict language like xml is, maybe that'd be better. But XML is not even human readable. YAML is.
i have not done so because i actually agree with you that desktop apps built on a browser are a pretty sad end-user experience, but the lure of honest-to-goodness "write once, deploy anywhere" is hard to deny.
It's fast as hell.
If not Electron, how should one build a desktop app for Windows today? It seems the correct way is to use .NET and WPF if you want to take Microsoft's word for it. I've done this and it's installed on on 100k+ machines. In my experience, WPF is horrifically slow for users and uses just as much or more memory than Electron.
With that in mind, I don't really see how Electron has any downsides at least on Windows, and has plenty of upsides: build apps that respond to input much faster using a more familiar set of tools (JS, HTML, CSS). No .NET dependency that makes the install process a nightmare. No need for a custom update component (always very complicated, even for a super simple one) since Electron can just load remote resources. No need to worry about Admin privileges. Better support for monitor densities. Much better text rendering. So many things. I think Electron is saving Windows desktop app development, not killing it.
All of that said, even WPF has been superseded by the Universal Windows Platform. If all I planned to target was desktop apps on Windows 10+ I'd use the UWP these days. UWP has very similar advantages to Electron. (I really like Electron, though.) You can use familiar sets of tools, whether it's HTML/JS/CSS or XAML/C# or even XAML/C++. (UWP XAML is somewhat faster than WPF, but still just as sensitive to making sure you have your application properly threaded.)
If you can take advantage of the Windows Store or the Windows Store for Business (yes, that is a thing for enterprises to take advantage of) you get incredibly easy installation and upgrade.
Even if you can't use either sort of Windows Store, since the Windows 10 November Update, installs and updates are simply a matter of double-clicking an app package (.appx file). Users get a UAC-like prompt about the install, but don't need Admin privileges.
UWP has really good support for monitor densities and text rendering as it's meant to support nearly every combination of monitor densities you can possibly imagine, including the "Continuum" example of running an application on one's mobile device, miracasting the mobile device to a nearby screen to get a "full desktop" and moving the app to that screen.
The present of Windows desktop app development is the UWP. I'd still use Electron for cross-platform apps, but as a developer I like the UWP too. (My Electron apps I'm building for code sharing with Cordova hosts as well, so in essence I'm in a "Why not both?" situation and expecting to release both Electron and UWP options. I could even see encouraging people to use the UWP app on Windows over Electron. That said, I'd love a little better convergence between Electron and Cordova and could even see a more Electron-like API for UWP JS...)
desktop is hell. if I have to choose between wasting your memory or giving in to apple or android excruciating and closed developtment cycle, I will kil your memory anytime.
A shared browser engine could replace all of Electron apps (wink wink Chrome desktop apps) only if we had it right when we started.
Burn them all down BURRRRRRRNNNNNN!!!
Also, unbelievably faster in terms of developer time.
I think, because I spend a lot of time staring at text editor/terminal I really want it to look satisfying and pleasant to my eye. It is not main thing that decides, but definitely is up there.
On the Mac: Can an Electron app be scripted with AppleScript? Can it hand off to a mobile app using the Handoff API? How is the accessibility?
Windows has similar things with COM and Continuity. Can an Electron app play nice with these technologies?
In the peculiar Windows case, you can share much of your JS code with a "proper" UWP app as JS is a supported platform choice. With a bit of shim work you could even support almost all of the Electron API directly on top of the UWP.
I imagine that supporting AppleScript, etc, is a lot more common amongst developers that focus on MacOS vs developers that develop an application for three platforms.
As with any application platform, in some cases developers benefit from community effort and (ahem) platform effects: if, for example, a Mac OS developer really cares about AppleScript and builds a very good, simple way to provide it from an Electron application other developers might just do it because it is easy low hanging fruit to make Mac users happy. Theoretically it's even the case that if such a thing were used enough it might get baked into the Electron platform itself making it even easier to support.
Certainly if you can find a way to make it apply to multiple platforms (ie, "oh and this AppleScript tooling is similar for what we might want for IFTT support and these IoT platforms too"), then it has more value to a developer to support and makes it more likely that a developer will support it. (One example in Electron today is that most platforms have a concept of indicating progress status in their launchers/docks/taskbars, so Electron makes it easy to support all of the variations of that.) The complaint can be that in trying to build multi-platform supporting code is sometimes you get a "lowest common denominator" approach, but that leads us back to the original question that I answered which is that Electron certainly gives you the opportunity for developers to do the more specific things when they want to and isn't necessarily locked into "lowest common denominator".
From a general power user perspective: a cross-platform toolkit makes it more likely I see the application at all on my chosen platform; whatever the developers add to make it feel more comfortable to work with on my platform is a bonus.
Looks like it: https://github.com/electron/electron/pull/5352
I tried both Atom (ditched it after 30 seconds) and VS Code (tried to use it for a few days) but they cannot compete with a well-written native app.
However, it seems weird that when talking about mobile apps, the PhoneGap/Cardova "web wrapper" concept is derided as awful compared to native code or maybe cross-plat frameworks. From my anecdotal experience, those same people tend to think that Electron or NW.js are the greatest thing since sliced bread.
Electron is PhoneGap for the desktop. That's not necessarily a bad thing or a good thing, it's just a thing that makes sense in certain use cases and not others. The fact that web wrappers have different levels of "street cred" across mobile/desktop contexts feels more subjective than objective.
I suspect it's simply a matter of the younger crowd having more exposure to native mobile development, and little or no experience with native desktop development... so this discrepancy reflects those different comfort levels.
Yes, but mobile and desktop are quite different. For one, desktop has a lot more power - one of the biggest issues with PhoneGap etc. is that it's just slow, and, particularly, single threaded. That doesn't matter so much on desktop.
Also the other complaint is that PhoneGap doesn't use native UI components. Desktop has a huge variety in UI compared to mobile (think Microsoft Word vs Photoshop) - another "not native" format isn't quite as notable.
More importantly, though, is that developers hate PhoneGap and the experience it provides. I'd be interested to see the results of a survey where normal users are given a PhoneGap app and asked to point out what's wrong with it. I suspect many would think it's just fine. Not great, but fine. Similarly, if you asked anyone about the Slack desktop app I suspect they'd say it's fine.
Especially the latter is really puzzling to me.
Chrome (technically not Electron but it includes all the same problems) and Spotify gobble down enough power that I make a point of not using them if I'm away from my power cord.
Here I thought the gradual year-over-year percentage increases in battery technology were going to get us better battery life, but it turns out we'd rather just write shittier software.
What other battery life concerns do you have that are automatically solved by another framework?
Even if you just leave it sitting in the background with one tab open, Chrome uses more power than Safari. I'm currently measuring an "Energy Impact" of 1.9 vs 0.1 for that test.
I don't have any hard data for Electron apps, but my experience is that they're worse than their native counterparts. For example, Spotify (playing offline files) vs iTunes.
A JS+HTML application will be slower than a C++ application that uses the OS's native UI toolkit, and therefore will consume more battery.
My point is that tools like Electron are actually making it harder to do fast and multi-threaded code on desktop compared to other (native) options. So in that sense Electron's just as "bad" as PhoneGap on a mobile device: it actively hinders developers that want to build decently performing applications.
This even happens with applications that are considered "toy" in this thread like Atom: Performance is really much worse than other editors like Sublime or TextMate.
Absolutely. Electron is worse than native, I'd never disagree with that. But I don't think people are looking at Electron and saying "hmm, shall we do Electron or native?", they're saying "oh great, Electron means we can make a capable cross-platform desktop app, something we don't have the time nor budget to do otherwise".
If someone is wanting to release a shitty application, they're going to do so irrespective of Electron availability.
What it comes down to in the end is, is the trade off worth it. With Electron/PhoneGap and the like, you have a much faster path towards an application. Web tooling is broadly understood, and a lot of that logic/workload can and often is already done, and being able to reuse it is helpful... Having a stack that is closer to the rest that you are using anyways means less disconnect.
It's not for everyone, but in the end it doesn't stop anyone from using C++, Go, Java, C#, Python or a number of other languages/tools.
What I mean is what is preventing you from writing a C/C++ library, installing it down with your Electron UI and having the Electron App call out to the high performance .so?
PhoneGap gets a lot of hate because it's _slow_ and single threaded in an environment that is starved for resources. This can impact user experience even in _just_ a UI context. On a desktop, a single core is many times faster and there are much greater resources so I don't see it as having as large an impact on UI (if any at all noticeable user experience degredations). This is of course provided Electron is (or can be) UI _only_.
Just curious :) since I have never really heard of Electron before this.
There are also native modules for Electron/Node which can work in background processes.
In the end, for the most part, in most applications, there isn't much logic that actually takes advantage of multiple concurrent threads for logic, and I/O is already multi-threaded.
I agree with you with regards to multithreading, though. It seems like that is actually important on both the desktop and mobile for compute intensive tasks.
Just because Electron is used in a technology stack doesn't automatically mean that the developers are going to be lazy.
Lazy devs be lazy, bro.
Electron happens to cross the threshold for sensitive users like you and me, but for a large number of users it seems the step in performance from mobile to desktop is enough to buy you the "Electron/PhoneGap/Cordova abstraction" (seeing as how there are popular Electron apps but few for PhoneGap/Cordova).
Electron is not native, and beyond that, there are too many variables cross platform for anything to look truly native everywhere even for a compiled C++ app without a lot of work. That said, you can definitely style to a platform more appropriately (again, there is work to that).
Mobile devs care about their artisanal/bespoke/authentic Objective-C or Swift code, while no-one really cares about Qt, GTK or wxWidgets in quite the same way.
There's social cachet to be gained by coming out in favour of native mobile development, while the same is not true for native desktop development.
I do enjoy Visual Studio Code, Atom, Slack, and other apps built with Electron. Yes, people also use it to build horrible apps, but Electron has proven that it's capable of powering apps people love. I have yet to see a Cordova app people love.
TL;DR: I love various Electron apps. If I see an amazing Cordova app, I will reconsider my position towards Cordova.
This was already a ton of work. I shudder at the thought of having to have done this with 2 seperate native versions instead. I would have never shipped.
Electron has been the basis for several great applications though, just looking at their website you can see a good number of apps that look and run great. Discord and Gitkraken among them, for starters.
Every time I've opened a Cordova app I haven't known it was done in Cordova, but immediately thought the app was acting very oddly. Checked the source and yeah, there it is. Cordova.
That's not to say that every Cordova app is bad, I'm sure there some that work well, and if I had a need for any of the example apps in their showcase I would have already tested some. HTML5 performance isn't so much the issue as the implementation of the wrapper. Electron stands as a testimonial to the capability of web technologies as an application platform, it's the history of Cordova applications, even in the last month I have tested an up to date Cordova app, and it just doesn't hold up to the hype. And I'm someone who really wants cross-platform web-based development on mobiles to be great.
The most relevant use case is getting away from different browsers.
You doing your web-app, make it responsive and give people who are like "We want to use IE5" an electron wrapper for the web-page.
Currently I am using Visual Studio Code, because it is one of the best IDE experiences for when I need to play around with Rust.
And being pragmatic, I rather enjoy the productivity of VS Code for Rust than being religious about it and losing the said experience.
I've had a chance to work with the core team on a handful of bug fixes and new features, and they've been incredibly kind and welcoming. I think Electron will go far as an open source project, and I'm excited that GitHub is growing it beyond Atom.
If you're in the SF Bay Area and interested in learning more about Electron, there's a meet-up coming up later this month! http://www.meetup.com/Bay-Area-Electron-User-Group/
The energy and "momentum" in the web community is something that has been discussed extensively on HN and elsewhere, so I won't comment on that. Suffice it to say that motion is not always the same thing as progress.
For instance, I downloaded Atom and after starting it, it wanted to connect to atom.io and then Google analytics. Now Google not only knows which web pages one visits, but also which apps one uses. Electron is win/win - for web developers and Google, of course.
It is not usual to gather telemetry on the desktop, with perhaps the exception of some AppStore apps. Of course now that Microsoft got greedy and web developers are starting to develop desktop apps, we might see a different trend.
You practically have a window frame inside a window frame even! http://i.imgur.com/2C769ex.png
(Speed differences, the theming (dark theme for the whole UI, except for some electron apps?), etc are also issues.
I think lpsz said it best, "It's cool for developers. It's not cool for the users". I'd qualify that with "It's cool for web developers".
Works pretty perfectly with rust as well. I have both a vim and an atom rust setup and they have near total feature parity.
Neither is a text editor that can't show letters as fast as a person types.
Not the only one:
* Atom vs. something like Sublime Text
* Or, Slack that takes the cake especially if you log in to multiple Slacks.
It's cool for developers. It's not cool for the users.
Electron apps don't appear to play nice with the underlying API.
Take Spotify and Slack, for example. It makes sense that it should expose its API via AppleScript (on Mac), COM (on Windows), and DBUS (on Linux). These let you do neat things like, for example, use a PowerShell (or bash or AppleScript) script to update your Slack status to the name of the track that's playing.
Whether you'd WANT that specific functionality or not is beside the point, the fact that the functionality exists means that people will do cool things with it. More importantly, it means that people will do things the developer never thought of.
Looking at Atom's API docs, for example, tells me that there's a very rich API that doesn't appear to be exposed in any way that's native to the underlying platform.
No, you're not. In fact, every time any link shows up on the Hacker News front page that has to do with using HTML/JS/CSS to build native applications the comments on it are usually dominated by people who are "unhappy with the trend toward web-wrapper applications".
> It's cool for developers. It's not cool for the users.
Here's the thing, if it's not cool for developers, then it might not even get built, and that's really not cool for the users. So if I had to choose between less performant code but more software options for users and more performant code but some software people really want or need not being developed, I'd choose the former.
There's a really high chance that you had another browser process open that was dedicated to writing your comment. Mobile included as the HA app is a Cordova-based solution.
But you feel compelled to say that thing that you used to accomplish your reading and commenting task was somehow slower and hogged your battery.
It got the job done didn't it?
Further, what's the #1 tech that some really smart people are focused on optimizing because of its usage. Yeah, again, the browser.
Show me another standards-based general UI stack that has had as much man hours dedicated to optimization... AWT/Swing/JavaFX? laugh. WPF, also really slow. WinForms? Not a lot of dev going on there at the moment.
So I get what you're saying, but the worst case is that your browser will do the same thing for each tab.
Software like Excel which will spawn a different instance of Excel for each workbook, even though it could theoretically be a single process... so it's not like native apps are a panacea in your argument.
Now we're talking about writing applications with web technologies for high specialized skill and high effort tasks, e.g., code editors, photoshop clones, etc... Which is what a lot of us are skeptical of. These "professional" applications are designed to reward a huge investment in muscle memory, if you are putting so much effort into learning an application, you don't want the return on that investment to be stunted by limitations in the technology the tool is built with.
How much emphasis is being placed on JavaFX/Swing/AWT these days. Not so much. WPF? Microsoft has said that "...we are not investing in any major changes to WPF"
There is so much effort being placed in HTML/JS optimizations by WK, Blink, Edge folks that it's hard to find another framework with as much emphasis placed on it.
* Lack of data ownership, how do you export/backup?
* Poor keyboard shortcut support, e.g., constant conflicts between the browser itself and the app being run in the browser
With Electron based apps:
* Performance obviously, this might get better in the future, but that's a big bet of your time investment in learning and building on the tool. The fact that Atom is slow on a top-of-the-line machine is concerning. Sure that'll improve in time, but what if I also want to run it on more constrained device, tablets, etc...
* Electron apps still have a long ways to go to support basic platform expectations, e.g., on OS X Atom doesn't Services, AppleScript, or piping to the command line utility.
List one that is MIT licensed...
GTK+ is LGPL 2.1 (not a problem unless you need to statically link).
Like Whatsapp App on Desktop you literally have a 60MB download and 200MB install just for a screen that is EXACTLY the same as the Web Version of Whatsapp.
While I dont expect all the apps are like CCleaner or the old uTorrent which is only a few MB in size, 200MB is just redicously large.
Ideally it should be run through webpack/etc and only a bundled, minimized version of the app is shipped. In practice some modules may have native compiled addons.
I'm working on an app right now and it ships at 247MB which is way too big.
a node module should be just runtime required code and LICENSE
Also, before packaging your Electron app use something like gulp to exclude problematic files like .md and anything else unnecessary.
There are other common tools like browserify that can still be leveraged.
EDIT - Ok, sorry, it seems quite a few people do have pretty horrendous bandwidth issues.
Also, Electron's size means more power draw. When I want enough battery life to do some work and still watch a long video afterwards, I habitually close Slack because it makes a worthwhile energy difference. The app's size reduces my engagement with the app after install. I'm aware my behavior is unusual, but developers do need to keep this in mind, especially as Windows and OSX make app energy use more transparent.
How do you make the link between app size and power draw (as opposed to some other aspect of Electron causing draw)? And, what are you comparing Electron's power draw to?
A larger application presumably uses more RAM to itself (especially if its instances of node/chrome/libraries are distinct and so do not share pages by reference or in a copy-on-write manner with other similar applications) so there is less room for cache and buffers so the machine as a while is likely to be hitting disk more often and so consuming more power that way.
Loading the app will obviously involve more IO too, though hopefully that is not a regular occurrence for a full desktop app (it may be for a smaller utility program though) so the running costs should dwarf any start-up costs over time.
I think the following is a great narrative on why it can matter though: http://blog.chriszacharias.com/page-weight-matters
I agree on page weight, but somehow I'm more sympathetic to downloading apps, perhaps because it's just downloading in the background, rather than me waiting to read the content.
As for downloads, I remember using dialup and only getting one 1MB file per hour. It would take a lot of patience to even download a 10MB app on that. I don't tend to leave my computer on downloading overnight these days though, and I 'only' get 1MB/s (dslreports.com says I'm "faster download than 60% on DSL in australia").
What does the order of magnitude really gain the end user? A slower, less powerful GUI system?
Those data points aren't really as different as you seem to think :)
For non-web developers, there are already well-suited technologies to develop desktop applications: Swing, Qt, Cocoa, GTK, WPF/WinRT, and so on. Maybe theses technologies seem less sexy but there are here from the beginning to do that kind of job.
Please, use the right tool for the right job.
> "Please, use the right tool for the right job."
I would rather use a tool that I know and build something functional fast, than spending many months learning new language just to make my app cross platform and losing interest because of that.
Electron tries to break the same barrier WebForms did but in the opposite direction. Hopefully it turns out better and doesn't result in a bunch of shitty desktop apps like WebForms resulted in a bunch of shitty web sites.
If you build something functional fast with your favorite tool (not suited for the job), then you will probably spend many months maintaining/hacking your codebase to keep it functional and well designed.
An Electron app is not equal to a native app when it comes to UX and UI. Right off the bat: they require more resources to run, thus making your computer slower, a laptops battery last less on a single charge, and don't look and work like native apps thus requires the user to learn a new paradigm.
So instead of you, the developer, using a couple of months to learn a new paradigm, you put that burden on your users, and end up with something that is a whole lot worse than standard native apps on Mac, Linux and Windows.
If you only have 1 user, that is no hassle, but if you have 5 million users, that is a whole lot of time that a whole lot of users needs to spend collectively because you are lazy and want to ship something fast instead of shipping something great.
And no, I have never tried a great Electron app. I don't think they exist.
Exactly. That's the externality a lot of software companies nowadays generate.
But yet you used a either a browser or the HN mobile app (cordova) to post here... guess that means function > fitness.
You get the picture.
The barrier to entry for Electron apps is 0, the same as for native apps.
At first glance, Electron apps should be more maintainable, not less, because it's one toolset for multiple platforms, which should translate to faster development time and less total cost of maintenance at the tradeoff of app performance and size.
Also, whether an app is difficult to maintain ought owe more whether (1) you have multiple diverse codebases and toolchains to maintain, and (2) that you have a disciplined engineering strategy.
Again, whether or not Electron is the right tool for the job is a business decision based on business constraints.
Unfortunately, usability and ergonomics are rarely reflected in business "fitness functions" (hell, even making an actually useful tool rarely is these days, thanks in part to marketing having better ROI than delivering value). Business people take care of business goals, and I think it's our responsibility as developers to make applications that don't suck, whether or not it is reflected in the organizational "fitness function".
Using web technologies to develop a GUI has been so much easier than learning a new toolkit, or even language. For one thing, some of the options you mentioned are OS specific. There are benefits to OS-native toolkits, but as a one-man team with a small project, the benefits are small and the time investment large. With Electron, I can build on Linux and release for Win/Mac without any concerns.
Qt is the best option of those you mentioned, and I considered it. But I was never great with C++, and learning a whole new markup language (or being tied to Qt Creator) for the UI was an extra barrier for entry. And I've often found that Qt programs don't look or feel right outside of Linux.
Personally, I find developing a UI on HTML/CSS/JS much easier than any desktop UI toolkit I've tried in the past. Updating the UI from the code, and calling code from the UI is s simple, because that's what it was designed to do. And having a browser console makes debugging and trying things so much easier.
I was never a fan of using JS for anything but websites before, but I decided to give Electron a try and I'm a convert. Perhaps there's enough of a speed difference between JS and native code that it would matter for more complex programs, but for my uses I don't notice a difference, thanks to the speed of JS engines now.
Maybe from someone that's starting with no coding knowledge would find Qt and C++ just as easy to pick up as HTML and JS, and certainly a C++ developer would find Qt a better choice. And sure, I don't expect anyone to be able to build Photoshop on top of Electron. But there are plenty of programs that aren't that complex.
While in theory I agree with not using the "new sexy technologies" for the sake of it, and "using the right tool for the job", I don't think that applies here. It works both ways, don't stick with old technologies just because that's what you're used to. What specific benefits do you get from using one of those toolkits for a simple desktop program?
The real reason you're seeing apps based on Electron these days is that it's easy to hire HTML/CSS developers. That doesn't mean these are good platforms though. I remember when the bulk of apps were being written in Visual Basic because it was easy to hire VB devs (lots of people learned VBA via MS Office).
You're right. They need to catch up to using 5.8 GB for Visual Studio and 480MB for IntellJ to start. :)
What about applications like Photoshop, Premiere, Cubase, Logic? Basically anything that does more than show a couple of editor panes. I'd love to see these kinds of things built in Electron but as far as I can tell this has not happened yet. In these areas languages like C++ and frameworks like Qt are still really really popular. Not to mention embedded development, of course.
That's the difference between toys and tools. Most of the popular applications are toys, and this saddens me a lot personally, because humanity is wasting the potential it has with all that cheap computing available.
> I'd love to see these kinds of things built in Electron but as far as I can tell this has not happened yet.
I don't see it happening any time soon. Web is not meant for serious tools. Compare Microsoft Office and Google's butt office suite. One is a tool, other is a toy that looks nice for simple documents, but is utterly unusable when your document/spreadsheet grows beyond more than a couple of pages.
Well, isn't that an ambiguous claim with a weak anecdotal evidence. What is a "serious tool"? We have our email, crm, analytics, (only) shop, document versioning, etc. online. Actually, the native applications I use are just Visual Studio (can be replaced by code), Sql Management Studio (many web-based alternatives) and the browser itself - that being the only type of application I use with no web-based alternative, which could be seen as an operating system.
Try working on a 20-page document or 5-page-long spreadsheet and see how long it takes before you get pissed off at the performance. Unless you're oblivious to it - I'm starting to believe more and more people don't even expect anymore that computers can work without constant lags and pauses.
> the native applications I use are just Visual Studio (can be replaced by code)
Now can it, really?
> Sql Management Studio (many web-based alternatives)
With even remotely similar feature sets?
I replaced Visual Studio already with Code for my personal projects. I expect it is just a matter of time before companies start to consider doing that too. Is it feature-complete? No, but not because it is an Electron-app, but because it's just young.
SQL Server doesn't work on platforms other than Windows so the motivation for coming-up a feature-complete alternative is little. I could even then find a couple promising projects with a web search. For other databases such as Postgres and Mongo, there are many alternatives which provide more than their native GUIs. Rethink's main GUI is web-based, for example. A database management interface isn't challenging to implement as a web-app because web-apps are limited toys, but it is hard to do right in general.
I always wonder if pretentious people realize their pretentious and simply don't care, or they're actually oblivious. Perhaps you could enlighten me?
The difference between a "toy" and a "tool" is whether or not something is mainly for fun or mainly for being productive. It has nothing to do with the process used to build it.
Then again, from what I know, Premiere, Photoshop, and DAWs like Cubase and Logic are straight-up C++ applications, and don't even go into Java / Qt territory.
I would say that something like Google Apps vs Microsoft Office is a lot closer than it used to be. Native-app Excel sheets for instance still have the edge in speed overall, especially for large datasets (say, >10,000 rows) better, and Excel has a pretty significant edge in my opinion for analysis (pivot tables, charts, etc.). Google Sheets however are very capable for a large percentage of documents, with the added benefit of being so much easier to share and collaborate. Neither use case is a "toy" scenario in my opinion.
Also, lag issues are not really limited to high-end graphics / video editing. Sure, lag/low performance makes those tasks basically not doable in the browser. But even "ordinary" webapps - like word processors or issue trackers - are annoyingly slow. Take Jira for example - I'm probably wasting a few (billable) hours every month just because it's not a desktop app. So are all of my co-workers. It's most likely also the reason people tend to batch time reporting and do it once a week or so (it's much less distracting then), which as a result precludes management from having access to up-to-date information about time spent on tasks.
Trivial inconveniences can have non-obvious impact.
I think you'll find that Desktop apps often have to communicate with with centralized servers as well.
From what I've heard (no in depth knowledge so I welcome corrections), the DOM / CSS model itself really wasn't designed for fast, responsive applications and thus tends to under-perform in that department. So even a fully internal network app with comparable communication speed may seem slower on the browser from the get go.
Many web apps often also tend to be a little bit laggy just based on their cloud based nature. Load a random spreadsheet on Google docs, and you are probably talking 100-200 requests and (depending on your network) perhaps a 5-7 second delay. Change a tab, and you probably have another 2-4 second delay. Compared to the 1 second load time of a spreadsheet and nearly instantaneous tab switching time on a native spreadsheet app, it feels slower... especially for the power users, I'm sure...
They're just tired and try to highlight some problems that others don't care about.
> The difference between a "toy" and a "tool" is whether or not something is mainly for fun or mainly for being productive. It has nothing to do with the process used to build it.
The difference is the goal - is it supposed to help people be productive at their task, or is it just supposed to make such impression while in fact being there to extract money from naive customers? (Or is it a worse-is-better half-assed 20% solution?). Whether you like it or not, performance is a big part of usefulness of application. I brought up MS Office and Google's cloud-based solutions for a reason - only one of them can handle the load a professional user needs to handle.
Quite often it's literally like a difference between a metal hammer and a plastic one. Both can, in theory, be used to drive nails, but there is kind of a difference in performance.
 - https://upload.wikimedia.org/wikipedia/commons/8/84/Claw-ham...
 - http://thumbs.dreamstime.com/z/plastic-hammer-2181534.jpg
Your needs are different, and that is cool - but it does not relegate web apps to "toy" status.
There's a significant difference between "theoretically X can be done with it" and "it is useful for doing X". You can drive nails with a plastic hammer after all (and most people don't even need the "additional" feature of pulling them out).
 - which is partly because I reduce expectations of what I can do. Think of it as generalized Blub paradox - you think in terms of the tools you use. Get a better tool, and suddenly you can do more, do it better and do it faster.
Crashes / weird bugs and MS Office... that's something new to me. I always considered MS Office to be a set of some of the most stable applications I've ever seen. Do you do something atypical, so that the bugs/crashes could be related to a platform or some rarely used features? I'm asking out of curiosity.
Google Docs et al. don't just lack advanced functionality, they lack a lot of quite basic functionality too. But my point wrt. webapps is also one of ergonomics. I do a lot of work in Google Docs and Spreadsheets due to external reasons, and I absolutely hate the experience. No matter how fast a computer I use, the lag on the Google's office suite is very annoying and distracting. Like with some IDEs which are slow enough to make one unable to ever enter the state of flow, Google's spreadsheets routinely double the time I am spending on a task due to simple lag on almost every operation.
Not that I can tell. I mean I run it inside a Windows 7 VM, but other than that, nothing atypical.
One example of a bug that I can think of (because it happens consistently) is that Outlook 2013 taskbar icon shows the orange envelope to indicate that I have unread mail... when I don't have any. It drives me absolutely bonkers. I've also ran into more serious issues, for example yesterday when I pasted something from a web page into MS Word and it froze and crashed.
I've seen many complaints about Spotify on e.g. Reddit - specifically about the fact that it's no longer native.
Seen also many complaints about bloat and slowness in Atom & VScode.
I understand why this toolkit is chosen, but companies can only push so much before the customers also push back against the decrease in qulity.
Everybody can yell that Qt/Gtk or even the MS stuff is the better tool for desktop apps, it won't change anything.
There's 0 objectivity in the choice. The young boys just think in HTML/JS, so we'd better adapt :-)
Can you give examples of ERPs or CRMs that are "way, way more complex than Photoshop" though? It would be nice to be able to compare.
It's not at all about how sexy a technology or framework is. I just think I can do a better job in a framework that's adapted to my skillset, instead of adapting myself to a new framework.
You used to be able to use Delphi or VB6 to make working desktop apps in very short times. I'm sure other will reminisce about other older desktop techs that were a breeze to use.
There was also Adobe Flash Builder that very briefly looked like it would be a competitor when Balsamiq was a big new thing, but it never really took off (only other thing I've seen use it is salesforce's SOQL tool). At that point everyone hated Adobe though, so it didn't have much chance.
Though interface builders help a lot, I've always had a problem building more dynamic interfaces through any of the native tools. React, for example, makes that a lot easier.
Try to stay at least a little bit realistic...
One thing is that React is the newest iteration of production-quality declarative UI management. Angular, Backbone, a lot of stuff came bdfore. And all that contributes to a mature understanding
That being said, I forgot about QT quick. That is also pretty powerful stuff. Though the web influence seems there ( correct me if the causality is wrong).
I ask because I quite like JavaFX. The developer/documentation website is fusty and old-fashioned looking, but the tech itself is just really solid. You can tell it's been made by people who have spent their whole careers doing UI toolkits.
Which part of Electron makes it wrong?