Our team at Nylas has been incredibly lucky to build on the shoulders of the folks at GitHub and I'd just like to thank Kevin, zcbenz, Jessica, and their entire team. They've been awesome to work with and super supportive of this new community.
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. :)
Building a larger Electron app myself, thank you SO much for opening up your code. There's a ton to be learned, like you said, about best practices with Electron. I"ve spent so much time shuffling things around and refactoring that I can appreciate a good foundation for consistent file trees.
I'm going a little off-topic here, but i just found out about Nylas. What i don't understand is the Cloud integration. If i use Nylas with my IMAP account, does Nylas upload any data to your cloud?
Can i use it as a basic Mail.app/Thunderbird alternative, without leaking my personal data to your cloud?
Not the OP, but AFAIK, Nylas does store your email in their 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 will likely change your outlook on the future of desktop software. :)
Slow, with a 100MB node runtime eating up an entire CPU, piling hacks on hacks on React on top of the DOM, being dependant on Google's will to develop V8, written in JavaScript? That sounds like a pretty damn bleak future to me.
Other than a little startup lag VS Code which runs on top of Electron performs very well on my computers, though they all have SSDs. As to performance and memory footprint vs. a statically compiled language/platform, yes, it's a bit heavier... that said, people are writing useful software with it, and able to deploy it cross platform, with minimal additional effort, and able to re-use components build for web based versions.
It's not ideal for some apps, but it's completely serviceable for most apps.
Oh I'm not contesting the fact that it's serviceable. Our job is to deliver software. I'm just slightly concerned by the absolute disregard for performance and power usage that is implied by using Electron.
* I meant 100MB memory footprint. Office doesn't have a 7GB footprint.
* 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"
>Excel alone uses 86.1MB of private memory, and 142MB on a Blank Workbook.
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.
Not in the least, it's dynamically-typed with ecosystem libraries removing APIs by the dozen (upgrade your dependencies? prepare for days of verifying runtime errors of missing functions), and TypeScript is still a second-class citizen even despite the increasing amount of TypeScript-first libraries (like Angular2)...
In comparison to most GUI apps on Linux, this looks pretty good. It might not be perfect, but if i had to choose between no linux port, and a good-enough linux port, i'll choose the latter.
It looks "good", but not, as claimed by the Nylas team, "native".
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)
The problem with asking for a GNU/Linux standard application is there are several toolkits for developing them that stand out when not in the same base as the desktop environment. There is a single concise appearance to certain distros (e.g. Elementary), then difference of appearance in desktop environments (e.g. GNOME, KDE) and then there are the toolkits that are written completely different and use separate libraries (e.g. Qt, GTK).
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.
You realize that GTK and Qt are both compatible with the other?
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.
What do you mean by gtk under Qt? What about Tk apps, or Athena apps, or Motif, or GNUStep, etc.? There really is no such thing as a native Linux look and feel, you just happen to use a consistent selection of apps on your own system.
What I mean is that a Qt app will look native everywhere, and Gtk apps will look native in most places.
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.
Can you point me at an example of an app that does it really well? We couldn't find any compelling ones when we were investigating platforms for N1. :/
There basically is. Linux per se is just not a desktop OS, like Windows or OS X. Ubuntu has a standard UI, Debian's default install has a standard UI, Kubuntu has a standard UI, and so on.
That's even worse though. You can't ask for a universal GNU/Linux native appearance since there are Debian/Kubuntu/Ubuntu standards for UI. The list goes on and on too.
That’s the KDE Plasma Desktop – I am running it on ARCH Linux, but the new Kubuntu (which I have on my laptop, and looks exactly the same) http://www.kubuntu.org/ has the same desktop.
Electron saved my ass when I was trying to come up with a simple solution for non-technical people trying to get their things done. So, thank you and team for doing this. I would like to see this achieve what Java couldn't.
I'm curious, and not willing to fill out a form to find out... it looks like N1 uses Nylas Cloud for data/services... that said, there's no actual published cost for this. I have several email accounts and would love a cloud/web version to access them all, combined with a standalone (desktop-ish) app, as the electron one... But I'm concerned about the pricing model, and with no openly published price, and no apparent income source, I am hesitant to even try the application.
Thanks for the work you are doing here, I feel that Email is one area that could use a lot of work.
Thanks, I didn't see an obvious link (should have clicked "more"), wound up on NylasCloud page, which did have pricing, but that linked to a contact form.
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.
Indeed. I am always surprised by the responsiveness of this app. Even when the rest of the system has slowed down to a crawl it's never too much to open up N1.
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. :)