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.
https://support.nylas.com/hc/en-us/articles/217518207-Why-do...
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.
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.
* Office isn't running in fucking Javascript
* 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.
Yet. ;)
You get 2 window bars, and 2 toolbars, nested in each other.
http://i.imgur.com/2C769ex.png
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.
[1] https://github.com/nylas/N1/issues?utf8=%E2%9C%93&q=is%3Aiss...
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.
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. :)