Is there a build available which doesn't require users to sign up for a Nylas ID?
The support page states that "If you’re using N1 against our open source sync engine, you’ll still need to create a Nylas ID."
Given the privacy policy says that Nylas shares information with third parties and that they can "make a copy of the entire contents of the applicable email inbox, calendar, and contact book", it doesn't feel like a traditional email client to me.
Nylas Mail Basic does NOT store your mail data in the cloud. It still uses a cloud service for some features (like read receipts), but all the data is local on your disk and auth credentials stored in your native OS keychain.
Nylas Pro currently syncs in the cloud to enable some of the pro features not currently offered in Nylas Mail Basic and to provide a much easier to use modern API wrapper around mail data. The cloud syncing infrastructure is open source and you can run it yourself and inspect the code.
All editions (both Basic and Pro) need a Nylas ID. This lets us manage subscriptions for those who want to upgrade. The code is open source on GitHub (nylas/N1). You can fork & run yourself without a Nylas ID. You just won't get any cloud-enabled features.
We never send mail, contact, or calendar data to 3rd parties. We do, however, use 3rd parties for basic usage and performance statistics and self-host as much reporting infrastructure (like Sentry) as possible.
I understand the desire to have a seamless flow from free to paid, but you can easily move this flow later in the app (a la progressive disclosure). You can even build this into the existing flow where users currently go to upgrade, by prompting the user to create a Nylas ID at that point (if they haven't already).
There's a reason that e-commerce sites allow buyers to add items to a cart without sign up, and to "checkout as guest" instead of forcing users to sign up for a Staples (or whatever) login -- you get more conversions.
Even if you prefer the approach of trying to get the information up front, adding a "skip" option that allows users to use the app without cloud sync, etc., then allowing a user to "go pro" later on at least allows people to try the app without a commitment. It's not possible to convert someone who isn't a user because they got scared away by the registration requirement -- better imo, to have a non-registered user, than no user at all.
The only reason I could think of for not wanting to allow this is related to the third party data sharing -- perhaps you plan to sell (obfuscated) user data to data brokers. If that's not in the cards, and you do not plan to monetize your free tier (aside from up-selling to pro), I see no downside to allowing users to use the app without cloud sync in the free tier, with upgrades available within the app.
Updating the privacy policy to be explicit about what data is used for ("basic usage and performance statistics") would do a lot to allay the idea that this data is being sold to data brokers (and not simply to make the app better).
It's a lot harder to monetize free->paid if you don't even know who your free users are. Requiring the creation of a Nylas ID for the free tier addresses this. Your ecommerce example doesn't fit the situation here; the ecommerce business wants the order $$ at the expense of the account, and their UX reflects that.
I remember a few years back after I got my first decent Android phone looking at "top 10" lists of the best apps out there.
One of those apps was Lumosity, and I installed it. The first step was setting up an account. I promptly uninstalled the app, and to this day, I have no idea whether it is any good.
It felt odd to me that for a game with no multiplayer component would require me to sign up for an account, and I'm not interested in leaderboards or cloud based backup either. I have the same feeling about email clients, especially when Thunderbird exists and is mostly decent.
Giving up an email account for a free "app" (and not a service) continues to feel odd to me. It almost feels wrong to call it "free", especially since it is unclear to me how my email is used.
And a throwaway phone without any user data? (I don't think there are working Android-in-Android VMs that are both performant enough and offer good isolation.)
Thank you for making the sync engine work client-side! It's a huge step towards making Nylas a viable choice for privacy sensitive folks like myself.
The next step would be to make features like "read receipts" that necessitate signing into a cloud optional. Being able to use the app without having to sign into a cloud platform would be a much more valuable feature for me than any feature such a cloud platform could enable.
Aside: as mentioned elsewhere in the thread, tracking pixel based read receipts in particular, is overwhelmingly only used in spam and newsletters and I personally consider it to be a liability rather than a feature.
Privacy concerns are very valid. You do have the option, however, of disabling those features in preferences, so you never have to use them (or the cloud platform) if you don't want to.
Do you still ship the open source engine with no authentication system at all? That was a massive problem last time I checked. Sure, you mentioned it, but many didn’t read that before setting it up.
OK, You will Need to Point this out in BIG BOLD 16 Fonts somewhere. Because I have skim read through Nylas multiple times and wherever it said it requires Nylas Cloud i just bypass it right away, thinking I have to store all my Keys and Important Data in yet another third party Cloud.
Since those are accomplished via a tracking pixel in the email and you need to serve that image from a public server, then yes, you'll need a cloud service to run that. As stated before, you can choose to run that server yourself if you don't trust Nylas with that kind of data.
Unfortunately, standardization != widespread use. Tracking pixels are still the most reliable way to know whether a recipient (or many) opened your message.
Gemail, Outlook.com/hotmail, thunderbird and outlook all block images, unless whitelisted... Now, there may be other providers/clients that don't, but the above accounts for a significant number of users (if not most western mail users).
Gmail does something more interesting. It shows the image by default if the url is not unique, or the image is an attachment. It also uses googles servers to download and cache the image when receiving it.
That's not a good excuse for not implementing a standard. It's also a little like saying "private investigators are still the most reliable way to know whether a person is at home": it's true, but not really a better thing to implement.
Tracking pixels are ubiquitous, and used in virtually almost every situation where you want to know if a person opened your email, which equates to virtually all ecommerce in my experience.
As you said, in newsletter/spam business. But common mail apps don't do that - there is already a defacto standard for that. It's clear that Nylas business is around tracking and collecting data. It's like Win10, the user is the product and everything gets collected.
Good that Outlook and other mail apps blocks third party pictures by default.
The parent mentioned probably the two biggest mail clients in the world, and you mentioned 2 that I haven't heard of despite 20 years of sending email and toying around with new software.. I'm not sure it's an effective rebuttal.
So this won't work with emails coming from Gmail (and probably other providers) since these services cache these images on their server as soon as they receive them (and not when recipients open them) precisely to defeat this kind of tracking.
And of course, a lot of email clients only open such images on demand anyway.
I don't believe this is correct. Gmail will only request an image to proxy once you've opened the email, according to MailChimp, so this would only prevent tracking multiple opens.
It's actually hard to track down exactly when these images are cached. I don't really trust MailChimp to be truthful about this but I also can't find any specific from Google themselves about whether that caching happens when their SMTP receives the email or when the user actually opens the message.
Since Google's goal with this was clearly to defeat tracking, I would strongly expect the former, but I can't back this up.
At first I thought "shares information with third parties and that they can [copy your email]" (emphasis mine) meant that the third parties can see & copy your email. I can't find anything like that language in Nylas' privacy policy (https://nylas.com/privacy-policy/) and so I guess your "they" meant "Nylas". Given their precise business model is making synchronized copies of your email inbox, that doesn't sound very unreasonable to me.
That's an integral part of how it works. Their sync servers download your email, then sync with your local client. You need that ID to log into their server and access your individual email accounts.
Hey – I'm an engineer at Nylas. This used to be true but Nylas Mail now uses a totally client-side sync engine.
If you're on the Basic edition, your emails never touch our servers. This was a huge undertaking (it's not easy to port a sync-engine written in Python and designed to run on servers to run efficiently on desktop machines) and is the major reason why we can now offer a freemium service. We're going to put out a blog post soon with more engineering details soon!
> We're going to put out a blog post soon with more engineering details soon!
Looking forward to it!
I think for this audience, this blog post raises more questions than it answers.
I'm a student, I can't justify $12pm (or $7pm) for an email client however good it is - but I'll gladly use the Basic version and continue contributing; pay a little back that way :)
That's awesome to hear. However I see Nylas still is requesting full "view and manage your mail" OAuth permissions server-side. Is that something that can go away?
Not any more, per the post, the performance boost comes from using Gmail's, Exchange's, et al. APIs directly rather than remote IMAP sync + provide REST API for the client.
Cloud now used for "much much much much less" [0] - just tracking and stuff. Sync-engine also (?) runs locally now, I'm not totally clear on how this works but there's apparently some currently closed source stuff to become open 'soon', so it should become clearer exactly what's going on.
There's also apparently some details to follow on their engineering blog [1].
I really wanted an Email client for Linux which isn't power hungry but unfortunately last I tried Nylas - it was always top app in `powertop`. An always running app has to be low on power consumption IMO, but because so many apps are being built on top of webkit/electron most of them pretty much suck when it comes to battery usage.
Another case in point is slack app. On Linux, it is probably the worst app. :(
Electron actually gives you quite a bit of free help for power consumption. The Chromium team goes through great lengths to save power and most of those efforts get reflected in Electron. For example, when it the app gets put in the background it will automatically reduce power usage.
When no javascript is running the app consumes effectively no power.
Now that being said there's nothing to stop developers from running lots of expensive code or being non-performant with rendering. This is true in any environment. However; having access to the type of flame-charts and profiling tools that come with Chrome / Electron go a really long way to addressing some of these issues.
I work at Nylas and we've been heavily focused on reducing the amount of power the app consumes. We've still got a lot of work to do, but at the end of the day processing a ton of email quickly is a fairly expensive operation.
In the long run it's possible to offload very expensive work to natively compiled modules. A lot of Electron projects do this and can use Node's native bindings to connect to processes that really need to be fast in native code.
I have done some benchmarking of Qt/C++ vs Eletron/node performance while I was working on rbkit-client (https://github.com/code-mancers/rbkit-client) and frankly performance gap is huge for stuff like parsing, processing and anything which is CPU bound.
So if Nylas is parsing imap messages then both parsing and rendering difference between a native and eletron app will be big. Fortunately browsers workaround some of this problem by consuming json and stuff - formats browsers can natively parse.
I don't know how I ever missed this one when I searched for email clients. That looks like such a breath of fresh air: the download is under 10MB and it even supports GPG.
I second that! Thank you very much for the link. Looks like the perfect lightweight and powerful mail client. And the fact that it stores each mail in its own file is absolutely bombastic. I guess I can finally sync my mail on different machines using my cloud storage as the sync back-end.
I think the answer is Mutt. For me, the editor is what stops me from switching. Does it still require you to shell out to an external editor to send a mail?
There was an amazing mail client for (of all things) FidoNet back in the 90s called GoldEd that was amazing. It had threaded message display, a great editor, pleasant colors, etc. It was tailored to that network, however. Would love to find something like this for console-based email that has the built-in editor and isn't Pine.
I am a very loyal mutt user. Coupled with mbsync (for offline imap) and notmuch (for indexing, threading and address completion) I think it's a great MUA.
I obsessively measure wakeups/s in powertop for every application I use, and the above setup is very good.
If you want to try other things you can look into the mutt-kz fork (which replaces internal search commands with notmuch).
There is also a notmuch curses client, but I find mutt+notmuch superior.
Mu is a notmuch alternative worth considering. Their emacs client is excellent.
Finally, also if you use emacs, gnus is perhaps the most powerful email client ever. Steep learning curve, though. It's a bit different to everything else, as gnus has been built as a news reader. It treats mail as news, but this has some great advantages I think, as long as you can adapt your mindset. Also Org integration.
Gnus is the only thing that might make me switch away from mutt.
Gnus is unbeatable for reading mailing lists -- it basically lets you take the many optimizations and workflows developed in various newsreaders for managing large Usenet newsgroups of which you only want to read a small subset, and apply them to mailing lists. For reading mail other than big mailing lists, it's a little awkward. I used it as my main email client for years, but have drifted away.
Using email less, honestly. Because I can't get to my home email from work, I've largely stopped following most of the mailing lists I was on, just catching up periodically. I've played with mu4e, and I'd probably use it more if I spent more time on a computer and network under my full control.
For my reduced email needs, I mostly use K-9 Mail (Android) and self-hosted RainLoop (web). For work mail I use Outlook.
The trouble isn't electron/webkit, it's the tonne of JavaScript frameworks that are used to emulate what HTTP already does very efficiently (pages, links, requests, responses, etc.).
I still do not understand the fascination with JavaScript. SPAs, desktop apps like Electron, server-side stuff with Node, I just don't get it. JavaScript is the worst tool for the vast majority of these things. It brings us enough pain as the only practical client-side language on the web. Who deals with that and says "I need to write my server (or worse, desktop app) in this, and you know what, I'm going to now bastardize the entire web model with all this Angular cruft just for good measure"?
Every time I try to get someone to explain it to me I'm just met with a bunch of empty answers like "Yeah it just flows really well man". It seems like the JavaScript Everywhere fad came into being solely to fulfill the need of a lot of novices to feel smug and important against more reasonable people, who are just left with puzzled looks.
"JavaScript is the worst tool". Ah, no matter how many times I see it, it never fails to rub me the wrong way for some reason.
Its faster than Ruby, Python and PHP by a mile.
It now has async/await.
The amount of work that goes into making it good for front-end apps is amazing.
It has a fairly large ecosystem.
Dynamic / unityped nature lets you prototype quickly.
Tooling such as TypeScript lets you switch to static types when being dynamic just wont cut it any longer. Oh, and TypeScript has generics! (can't believe thats still a differentiator in 2017)
TypeScript can typecheck JSX templates.
It has PureScript for when you want even stronger type-checking and abstraction powers.
It doesn't have: multicore green threads (probably not going to happen) and large ints (coming soon).
Here, have a look at https://facebook.github.io/reason/ and https://facebook.github.io/reason/modules.html and see how many equivalent features it provides using just lexical closures and free-form objects (the TypeScript overlay can also approximate some features of algebraic datatypes via tagged unions and control flow analysis)
Really, the JS sucks meme is getting old, fast. Sure there are more powerful languages and higher quality ecosystems, but its quite far from being "the worst".
Thanks, this is the most convincing response so far.
In particular, I didn't realize how much faster V8 is than the reference implementations of similar languages. That can be a real and significant usage consideration and makes me less hostile to things like desktop apps. I've been operating from the "JS is slow" pre-V8 perspective, and while I knew V8 was a massive speed-up from the web perspective, I didn't consider that it was actually now among the fastest dynamic languages for non-web uses. That's a great point that should probably get promoted more often.
I still dislike a great deal about the methods and culture in the community and wish that such optimization would be directed at what, in my mind, is a more worthy target, but I know of a concrete rationale now. Thanks!
Its not just the speed. Have you looked at ES6 code? You will see a modern language with all the bells and whistles, including classes, lambdas, coroutines, template strings, a few other sugary features and a python-like module system.
All the fixable weirdness has been fixed. Even `this` has been mostly fixed by arrow functions. It still has implicit conversions, but hey, typescript and flow make that irrelevant because they'd check statically for those.
What else is so bad about JavaScript? I really don't get it.
Javascript gets used everywhere because it successfully commoditized programming. It requires very little knowledge to get it to work, so anybody can pick it up without much effort. For businesses, this means an endless supply of cheap labor. Most people here on HN and elsewhere believe this is a good thing. It furthers their dreams of programming becoming a basic literacy, like english and math.
Keep in mind I don't agree with the above at all, but this is what a lot of people believe.
I don't think that JavaScript did that. I think web development in general did that, and continues to do that. JavaScript is only contributing insofar as JavaScript-based backends are inexplicably now becoming more employable than some much better alternatives (which not too long ago I would've also been deriding, but they look beautiful compared to node).
Until recently, and I know the "front-end devs" are going to have my head for this, but until recently, there was hardly any serious JavaScript coding going on even on the client-side. That means it wasn't something that a new developer would really stumble across and just start using to build full-fledged programs.
JavaScript's main use was extending web widgets to do things slightly more conveniently. All the heavy lifting would be behind the scenes and JavaScript would watch you type so it could autotab for you. So I don't think the explanation that there was a vast knowledgebase eager to break into the backend is plausible.
JavaScript was so disliked from horrifyingly frustrating exposure throughout the IE6 days that no one would go near the thing unless they were wrapped in the jQuery condom. John Resig was a hero of legendary bravery for biting the bullet and making JavaScript semi-usable.
Someone had to write a book called "JavaScript: The Good Parts" that openly acknowledged JavaScript's inherent inferiority but tried to cheer us up by saying "Hey, I know we're stuck with this because browser vendors will never be able to agree on something else, but there are some hidden cool things about it! Don't cry!"
Somehow in the last 5 years or so, JavaScript has gone from something that required a prophylactic device before anyone would approach it to something that real companies are writing production _DESKTOP_ applications in. What the heck happened?
(I think The Good Parts is probably the real turning point here, where it became OK to treat JavaScript as a non-joke, and that V8 accelerated it. But people took Crockford's feel-good apologia and ran way past the finish line with it.)
If a company's doing web (as a lot are) they have processes and tools in place for that, so they would like to reuse them. These companies have also discovered that they can still hold on to most customers if they deliver merely adequate solutions.
They will then naturally choose the convenient-for-them known quantity and dismiss concerns regarding usability, performance, etc.
I don't see a real trend toward building apps using web technologies, but there is a lot of noise, making the topic seem larger than it is.
Of course you can't write a piece of, say, typescript, and just include it in your HTML and call it a day.
You need to compile it first, and you need some tooling for that, but it's not different from using a C++ compiler for building a Qt application.
> Every time I try to get someone to explain it to me I'm just met with a bunch of empty answers like "Yeah it just flows really well man".
It's different from using a C++ compiler to build a Qt application because it's in the opposite direction. Qt is a toolkit that lays on top of C++, which your compiler translates to machine code. Qt is still C++. Everything is the same language and gets compiled directly into the code that the machine knows how to execute.
With JavaScript transpilers, this happens in reverse; there is an entirely separate secondary language loosely bolted on here, which compiles to JavaScript, which compiles to some IR, which compiles to machine code. From the developer point of view, the code they wrote in the top-level language executes as JavaScript, not native code, and must be debugged at that level.
I'm sure you're not actually naive enough to pretend this is the same as using a library like Qt. Language semantics are very different and can be difficult and bug-prone to cross-implement. Third-party libraries and modules have large, potentially interdependent module webs that have to be resolved and will often result in massive includes on such transpiled pages (talking 10M+). Bugs at runtime will have to be debugged as the transpiled language, not as the code you originally wrote.
If you use Qt, everything is written in the same language, built by the same compiler, and that language's typical pipeline, including dependency resolution, is unaltered. Bindings in non-reference languages link out to shared objects that do not use transpilation, but long-established and well-understood OS-level linking conventions. This is a greatly reduced complexity surface (== fewer bugs).
My experience with transpilers is that people avoid them whenever possible because they introduce very intricate and difficult-to-use bugs. Now that I think of it, the most well-known transpilers are specially-made to service a large project's needs, like the recently-announced Grumpy [0], which converts YouTube's Python codebase to Go.
"Grumpy is a Python to Go source code transcompiler and runtime."
Literally the description on GitHub, and a very similar line is the first line in the README. I admit that I have not tried Grumpy personally and do not have any real experience with it. My knowledge on it mostly comes from the HN discussion a few weeks back. It is absolutely possible, even likely, that I'm getting things wrong here. Would you kindly correct my misconceptions? Thanks.
My reading of the "Developing Grumpy" section of the README [0] is that Grumpy is primarily a transpiler, and that's what `grumpc` is. It says right there it takes your Python, compiles it to Go, and then you run `go build` to build a Go executable.
The "runtime" comes in at this point. It sounds like `grumpc` compiles Python objects down to stubbed-out Go objects, which depend on the functionality implemented in grumpy for the implementation of those stubs. "The Go code generated by grumpc performs operations on data structures that represent Python objects in running Grumpy programs."
To me, this mostly sounds like a Python->Go transpiler with special hooks to more easily facilitate Pythonic access in Go. If anything, it seems to support my original point that transpilers are custom-built even more; from my high-level and probably wrong reading, it looks like instead of a full-scale Python-to-Go transpiler, Grumpy's developer realized it would just be easier to implement if he made the programs dependent on his "runtime", which he could freely do because he was running his own project on it and he can execute that project through `grumpy` just as easily as he could through anything else. Such options would probably not be available to someone who was tasked with writing a generic Python-to-Go transpiler that was expected to work anywhere that Go works.
I also could be misreading this, because again, I've never used it, and maybe by "runtime" the author really does just mean "library", and it all compiles down to a standard Go application. That'd be cool.
In all fronts is the worst, except easy of build a cross-platform GUI (not necessarily native looking!). The thing is that is easy to get the basic widgets cross-platform but in the moment you need custom widgets or easy styling html/css just is easier.
I wish exist a native renderer that could use a (saner, better) subset of html/css that fit the same use case, then let us use any better language for the logic.
Probably OpenGL toolkits are the idea, but it way to operate and looks are weird.
JavaScript is NOT the first language to provide cross-platform GUI. Such toolkits are very old. Gtk, Qt, wxWidgets, and many others serve this functionality and have bindings across dozens of languages. There is no reason to use JavaScript just so you can get a "cross platform GUI".
Gtk is not very cross-platform. It looks non-native on Windows, and it's so non-native on macOS that you have to run an X server just to see it. wxWidgets seems to be abandoned (their bindings don't even have a Python 3 release, which would happen right away if anyone cared). Most of these provide dated UI elements that people don't want to work with.
Qt perhaps is holding up the best, but I can see why people prefer Javascript's event model to Qt's.
Pointing out that old toolkits still exist doesn't necessarily help when people expect more from their toolkit now.
What do people expect nowadays from their toolkit?
It can't be performance, because Electron is slow. It's not conservative power usage, because browsers are power hungry.
It's not disk space or memory usage either.
Nor is it a native-looking UI. Nor security. Nor privacy. Nor accessibility.
The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new.
It's all anecdotes, but in my experience native devs are by far more willing to step outside of their area of expertise and use the right tool for the job when building for the web. Yeah they'll groan, but at the end of the day they realize that HTML+CSS+JS is how web front end works and so they write that. Very few bother compiling their favored language to JS or asm.js or whatever because it adds an unnecessary step/level of indirection and feels like trying to use a hammer as a handsaw.
By comparison web front end devs tend to cling much more tightly to their favored language+toolchain, taking it with them to every platform they decide to develop for.
I think the front-end world has a big culture problem, and your answers are an example of that.
Ignoring arguments, aggressive advocacy, "you too"s, asserting that web technologies are great in the face of so much evidence to the contrary and most of all, insisting to use the same inadequate tools for
everything from desktop to mobile to embedded.
I've been having the same discussion for six years with different characters now. One thing has never changed - web apps consistently show poorer quality than their native counterparts, especially in performance, resource usage and usability.
The software this community so focused on PR and advocacy is building is not good in spite of the bragging.
And regarding your arguments:
* Java, C++, .NET, Python, etc can claim having ecosystems. JS has a continuously churning collection of libraries. Nothing has been forgotten.
* a lot of Qt developers use it where it makes sense by bulding hybrid apps or together with QML.
> Ignoring arguments, aggressive advocacy, "you too"s, asserting that web technologies are great in the face of so much evidence to the contrary and most of all, insisting to use the same inadequate tools for everything from desktop to mobile to embedded.
Don't get me wrong, I'm actually a nice guys who has nothing against Qt/C++. I'm glad it exists because I can use it when what matters is power usage, native looking UI, security, privacy and all. It's just that I don't, personnaly, need those requirements.
> The only thing I can think of is that it's free and allows the typical web developer to avoid learning anything new
I'm sorry but this is simply wrong. And I think you don't need to show disregard to "typical web developers" when you're trying to make a point.
What do you choose when you need to quickly throw an MVP in front of a customer? Surely not C++/Qt (well, maybe yes if that's the only platform you master).
When you need a web-looking UI ? Not C++/Qt.
When you need to easily deploy on hundred's of windows workstations at a plant where IT is blocking you from installing anything on said workstations? A web app, not a C++/Qt client.
So, you see, maybe the web platform also has it advantages when you start looking outside of what you do everyday for a living.
> Gtk is not very cross-platform. It looks non-native on Windows, and it's so non-native on macOS that you have to run an X server just to see it.
This has not been true for years now. There is a native port of Gtk that does not require an X server. Gimp is available natively, as are other Gtk apps (Gnucash, Deluge, etc).
> JavaScript is NOT the first language to provide cross-platform GUI.
Of course it's not.
> There is no reason to use JavaScript just so you can get a "cross platform GUI".
The main reason (imho) is that "JavaScript" (as you call it, but you should say "the web platform") is more future proof than "old toolkits".
Qt would be the best candidate for a "cross platform GUI", but you are relying on the [Qt company/nokia/whatever] for its continuation.
When you choose html/js you choose a standard used by virtually every single person with a computer nowadays. There is far less chance that html/js will be killed someday, like Microsoft killed WPF or like IBM made SWT an abandonware, because nobody is in that position and this whole World Wide Web thing rely on it.
How can JS be more future-proof than old UI toolkits when JS libraries and frameworks are constantly changing? Sure, nobody will kill HTML and JS, but that's not the point. Nobody knows how UIs will be built with web technologies in two years!
Edit: based on your reply below, it looks like I have to spell it out. GUIs are built with UI frameworks, not just with programming languages and markup languages. JS frameworks are so short-lived that one can't be sure if their code will still work in one year.
There's real momentum behind a lot of things, including C and FORTRAN. That doesn't mean your next project is necessarily going to be written in either C or FORTRAN.
The crop of JavaScript derivatives are probably not going to disappear, but riddle me this: while there are many variations on JavaScript's syntax, why do other languages that are arguably JavaScript competitors, like Ruby and Python, not have the same wide selection of alternate syntaxes and sugar packets? Could it have something to do with the usability of the default dialect?
I personally think it's a bad sign when so many people feel they need to write a transpiler to add some syntactic and behavioral enhancements. The language should provide a functional, livable set by default, at least good enough that writing a transpiler doesn't sound like the time-effective solution.
I don't understand ASM.js very well but it sounds like it's a new type of bytecode that allows programs written in many different languages to be executed in the browsers' JavaScript VM. If this truly bring us first-class support for non-JavaScripts (which won't be real until browser vendors either ship or make it transparent and automatic to install additional DOM bindings), I will be so happy. I will also be curious to see if it has any impact on the popular use of JavaScript itself -- the node buzz already kind of seems to be fizzling out and moving onto things like Go, so maybe we won't have to wait too long.
> why do other languages that are arguably JavaScript competitors, like Ruby and Python, not have the same wide selection of alternate syntaxes and sugar packets? Could it have something to do with the usability of the default dialect?
Popularity, and the fact that things were very bare-bones before ES6.
> If this truly bring us first-class support for non-JavaScripts (which won't be real until browser vendors either ship or make it transparent and automatic to install additional DOM bindings), I will be so happy
Interop with existing JS code/data(structures) will still be a problem. Shipping (or rather, not re-shipping every single time the user vists) your favorite language's runtime and standard library will become a problem (which can be solved). By that time JS will be good enough to make it even less worth it, especially for dynamic/GCed languages.
> the node buzz already kind of seems to be fizzling out and moving onto things like Go, so maybe we won't have to wait too long.
This is true. There hasn't been anything new happening in node land for quite a while now, and the basic core platform is showing its age. With tools such as typescript, async/await and generators available, however, a revival is possible. TS tooling combined with a well designed and documented "core standard library" in the style of Dart's stdlib could make node a very nice platform again.
> I personally think it's a bad sign when so many people feel they need to write a transpiler to add some syntactic and behavioral enhancements. The language should provide a functional, livable set by default, at least good enough that writing a transpiler doesn't sound like the time-effective solution.
You focus too much on ES5.
It's not about the language, it's the platform.
> Edit: based on your reply below, it looks like I have to spell it out. GUIs are built with UI frameworks, not just with programming languages and markup languages. JS frameworks are so short-lived that one can't be sure if their code will still work in one year.
Ok, so let me spell this out too (frameworks/librairies mixed):
- jquery: 10 years
- backbone: 6 years
- angular v1: 6 years
- ember: 5 years
- react: 3 years
Otoh, Qt5 with QML: 3 years.
Quoting from wikipedia:
> Qt 5 was officially released on 19 December 2012. This new version marked a major change in the platform, with hardware-accelerated graphics, QML and JavaScript playing a major role. The traditional C++-only QWidgets continued to be supported, but did not benefit from the performance improvements available through the new architecture.
> JS frameworks are so short-lived that one can't be sure if their code will still work in one year.
Versioning your dependencies is good practice regardless of language and has been for decades. Javascript has enough cons, you don't have to resort to imaginary ones.
Is not about the first (and this is more about html/css than JavaScript). Is about the easier to work out, specially for custom styling and do custom widgets.
Not get me wrong, I don't like much JS/html apart as be hostage as everyone else to use it in the web, but is clear that as far to build the GUI is way more enjoyable than most GUI toolkit.
I think you need to prove that a (custom) UI is easier to build with HTML/CSS compared to QML. Or even plain old QWidget.
It can't be that web developers have been bitterly complaining about how poor HTML and CSS are at building UIs for years and years and suddenly it's become easy and enjoyable.
Actually it has become easy and enjoyable ;) Even for complex UIs.
Just think seriously about what a stack like es6/React/Redux brings on the table against plain old ES5, and you'll be struck by how well things have become.
Last time I implemented a complex web frontend was about 2 years ago. I can assure you that the process was anything but "easy and enjoyable". I will, of course, grant that things have improved greatly since the bad old days of IE6. But that's not a good anchor point to use for "easy and enjoyable".
> I will, of course, grant that things have improved greatly since the bad old days of IE6. But that's not a good anchor point to use for "easy and enjoyable".
Totally granted, the web platform suffer from a very bad reputation. And what does not help at all is that one need to carefully choose his tooling among a zillion of short-lived, hyped github repos.
But there is future-proof gems for those who invest the time in trying and learning. In a jumble: React, Redux, Reagent, Re-frame, Typescript, Clojurescript, Om, Immutable.js, Om.next, and so on.
I completely understand why people are moving to electron apps. Recently, I began work on what was to be a crossplatform desktop app, with a goal of being nice looking, and easy to use. Most of my previous experience was in android development, a little bit of web development (no applications though, only document based sites) and design work. I do most of my development work on a Mac so I decided I was going to start with a native Mac app (learning swift along the way) and then deal with the windows side later. Swift itself was very easy for me to pick up, but the rest of the experience was a nightmare.
The application involved a few components that were going to be quite complex and I wanted many of the basic components to have slight customizations. This turned out to be quite a bit more difficult than I thought.
The numerous issues that I encountered in 3-4 weeks (part time) of native development for MacOS included
* Xcode support for swift is garbage. Highlighting, code completion, and general responsiveness are far lower than even web based editors. Also no refactoring.
* Lack of documentation in swift + cocoa + appkit
* Lack of documentation for swift 3. Many examples were from either iOS (not everything is equivalent) or from older versions of swift (a lot has changed in 2 years apparently). Even basics of naming have changed a good bit.
* There was a lot of magic going on in xcode with storyboards / interface builder. When something broke it was very difficult to figure out what went wrong in the storyboard. The generated code from the storyboards is useless to look through. The difference between code working or not could be me forgetting to option + click a part of interface builder to a certain line in my code, with little or no indication of whether it had been done correctly, or what needed to go where, particularly with certain appkit components.
* Dependancies are a heck a of a lot harder to manage. I don’t know why but I ended up using Cocoapods and it was a total mess.
* Many core UI components requiring me to extend them or recreate them for basic functionality that would be a single line of code/xml/css on other platforms. Components that are common in other desktop applications don’t seem to be included in AppKit (some are including in UIKit though)
I ended up scrapping the idea of doing it natively and decided on Electron + React + Typescript. It was a lot easier to aquire and intergrate dependencies, the development enviroment is a lot faster, there’s no magic connecting my UI together, and it’s actually easier to recreate customizable, native looking components with css + js than it seems to be in AppKit. On top of that I won’t have to build a seperate windows app. Realistically my app currently looks and performs better than any competing app (many of which are legacy java+swing apps) and is a lot faster to iterate on.
Why's that? VSCode actually looks to me like a native app. It's really fast and behaves properly like any native app would. I guess most people wouldn't notice it's not native.
I think gregman1 means bad from a resource consumption point of view. It takes a lot of memory and CPU compared to similar, non-electron based text editors.
VS Code is not 'a very bad app'. If you know of a comparable app that uses fewer resources to a significant degree please let us all know and I'm sure we'll all switch.
An app that doesn't do anything in the background won't use any resources, doesn't matter if it is built on webkit/electron. Unless you have a huge volume of email, then Nylas should not be power hungry. I for one am grateful for web apps and for webkit/electron desktop apps. Without these taking off, the Linux desktop would be dead for me.
I admit I do have tons of emails, but It would be hard to find a programmer who doesn't have tons of emails these days. What with bunch of github notifications, mailing lists - I am always sitting at more emails than I can possibly handle.
Heck even my company-id has lots and lots of emails. Jenkins integrations notifications, travis, cron job failures and what not.
I naturally filter both my person and company accounts - so my Inbox is neat and tidy but I think we have reached a point where programmers/system devs/devops people will have to deal with tons of emails.
And yeah - I wish Nylas was better at dealing with this.
I also got lots of JIRA, Jenkins, Travis, Cron job notifications, until I filtered all of them away, straight to trash.
If I'm reading emails it means I'm not working or enjoying myself. And I'm not dev-ops, which means I'm not getting payed to keep the systems up and running at night.
I'm also practicing my own extreme version of "inbox zero". Whenever my Inbox reaches 100 emails, I select them all, mark as read, then archive. Information loses value as time passes and I figure that if there was anything important in there that hasn't caught my attention and that I did not answer, then one of my colleagues will surely buzz me about it. Worked fine thus far. And because I'm regularly removing noise, it means I have a higher chance of actually noticing important messages.
Writing this message reminded me that I've got 40+ unread emails in my Inbox. Marked as read, archived, now it's a solved problem.
Is your usage IMAP-centered ? Then I can only recommend Trojita (http://trojita.flaska.net/). There are a few quirks here and there, but it's pretty much the one application that is started when my computer starts and closed only when it is shut down. Its smart usage of IMAP makes it extremely efficient (doesn't download all of your emails just to display one, doesn't download the entirety of a single mail just to display its subject, ...). The only downside is that your usage has to be pretty close to IMAP for trojita to work best for you.
Never really compared their resource usage since I'm only in one Slack team 99% of the time and even the official app isn't that horrendous in that use case.
I use Mail.app, Outlook and Nylas on OSX and Nylas is way faster for me. Problem is that it doesn't have an easy way to encrypt/sign mails with PGP. Well the new MacOS Mail.app neither...
As much as I like the features, Gmail is horrible when it comes to performance. On my chromebook, GMail is the only page that significantly slows down the whole computer. Don't know how they do that, but no other page is able to slow the system down so much as Gmail.
Which is somehow funny, since the whole supply chain is controlled by them (App, Browser, OS).
After signing up for Nylas Mail, I started getting daily "marketing email" (spam) from them. It really added insult to the injury already caused by the Linux app being horribly slow, buggy, and power-hungry.
I sent them a scathing email about Nylas violating EU privacy laws years ago, and they only responded to them after I spoke up against the product here on HN. They still haven't told me what data they collected about me, which they are required to by law.
It's nice to see that Nylas has learned nothing at all and keeps violating their users' rights.
I suggest calling your local EU Data Privacy Official, they’ll be able to investigate the issue, and sue Nylas – without you having to get active, and netting the same result (your privacy rights being respected).
I open the page and have no idea what Nylas is. I click on the logo and I'm taken to the blog home page, where 60% of the screen is the Nylas logo with no subheader telling me what it is. I click on it again and it just refreshes the blog index. No link to nylas.com. How do so many people make the same mistake?
I had the exact same experience. I see this sort of issue commonly. Surprising companies don't just link you back to their homepage when they promote their product with a blog. Seems like an obvious thing to do.
It's a medium blog. They don't allow you to add external links anywhere outside of a post. I suppose you could create a new post, add links in that post, and then add that link to the nav of the blog.
Don't use medium for this purpose then, would be my answer. I also had an issue getting to the homepage. Obviously I managed to get there, but I almost didn't bother.
It looks nice. I don't have a mac so I can't test until you finish your release for the other platforms, but my question is about your marketing copy. I almost hate to badger you about this since the product looks nice, but I've got to ask about this line, "...the most powerful email client ever built"? That's a pretty bold claim and it makes my baloney detector go off. My suspicion is that it almost certainly isn't true, expect perhaps in specific areas, but not in the general. (If the suspicion is born out after testing, that makes me trust you less rather than more since it was a broad claim). Do you care to back up that claim in the general sense it seems to be offered? Or, if not, maybe change the copy?
Nylas Mail is the first email client built from the ground-up to be extensible. It's kind of like emacs in that way– you can create new plugins that add any sort of new functionality, whether that means connecting it to GitHub, Quickbooks, your CRM, etc.
I had forgotten about that part. Thanks for the clip; it's awesome!
Call me old-fashioned, but I still think words matter. IANAL so I don't know whether any laws are broken or not by such claims as "worlds greatest coffee", but there are truth in advertising laws on the books in the U.S. https://www.ftc.gov/tips-advice/business-center/guidance/adv... Even if there weren't, it erodes your integrity if you're not being truthful and the faces of the staff in the video clip are a nice balance between disbelief over Buddy's credulity and shame (particularly on the guy in the foreground). But I may be reading too much into this...
(Repeating here that I'm not claiming that Nylas' claim is false; I don't know if it is or isn't).
First of all thank you for making Nylas Mail, keeping it both free and open source. It takes courage to have such a free client competing with your commercial product. Also, thanks for developing the backend within Nylas Mail so a user can easily run the client without depending on a backend with SMTP/IMAP credentials hosted within the USA.
Have you considered an iOS or Android version client? Why?
Is the backend within Nylas Mail still in Python? Isn't this inefficient, performance wise?
Yep, we've considered building an iOS and Android version. But that means we need to make more money and hire more people. Our team is very small right now.
The new sync engine is written in Javascript, which is faster than Python, but the main performance improvements came from changing the architecture.
You could give the application away for free with a sub, while saying to Basic users they gotta pay for it.
The application Emby has the same model.
I think its fair. Me, I don't want more subs (and I'm not a business user so probably not your market). But I'm fine paying a (high) one time fee for an application.
> I used Nylas for a while and really liked it, until they they forced everyone to pay $7 per month to use it.
Sorry, but that isn't a fair way of describing what occurred.
Nylas is a startup, trying to figure out a business model which works for them.
You're not yet forced to pay. If you had a Nylas ID back when Pro was announced you got a gratis year of subscription. Now, they released a gratis version once more, called Nylas Mail, which is also open source. The backend is also open source.
What this means is that they've adopted a freemium model, and you got approx half a year to still enjoy your Pro license.
I haven't done a feature comparison between Mozilla Thunderbird (which I know is not everyone's preference but was my previous cross platform e-mail client), Nylas Mail, and Nylas Pro. If anyone knows one, please share.
My main concern is the backend being hosted in US by a US corporation. I don't like my data being hosted by US corporations, on US soil, and I recommend non US-citizens/residents to care about this.
> If you had a Nylas ID back when Pro was announced you got a gratis year of subscription.
Well, uh.. that didn't quite go that way for me.
The Pro 'transition' was a miserable experience that made me stop using it altogether* - it literally popped up asking me if I wanted to subscribe to Pro, and if I said 'no' (thinking I'll just continue non-Pro) the whole app quit.
* Coincidentally I tried it out again (seemed to get a 14day trial even though I'd used it before) a few days ago. There's still lots I like; the Basic tier is exactly what I needed really - last year when it suddenly held my emails hostage (slight hyperbole of course, there were still copies on the server).
I'm sorry to hear about your problem with the transition. Did you attempt to contact customer support about this?
My experience was I received a coupon via e-mail at june 15 2016. I upgraded the same day. But I also still use other e-mail clients to access my mail e.g. from my phone. So I would not be locked out of my e-mail if Nylas quit working that same day.
Hey – I'm an engineer at Nylas. To add to what you said, the newly released Basic edition does all email syncing client-side, and uses our servers for minimal things (i.e: auth).
The backend speaks SMTP, IMAP, and HTTP. It is basically a glue (or proxy) between SMTP/IMAP (including those protocols over TLS) and HTTP. Nylas Pro talks HTTP to the glue (I assume that is using TLS, so HTTPS). Nylas Mail also talks HTTP to the backend, but the backend runs locally, so you're self hosting the backend. I suppose this has a performance loss. (With Nylas Pro, you can set a separate backend server if you desire but that requires work. That is a really cool feature for a business though.)
So I would assume you are hosed. The passwords need to be stored plaintext.
Oauth makes sense that there's no password saved. A unique key is saved which is authenticated with Google. If this key leaks, you are hosed, too, but at least you can revoke that key.
I tried grep mypasswd ~/.nylas-mail/* and grep said Binary file shared.sqlite matches. This did not occur in ~/.nylas it makes sense and it is inevitable, a client like Thunderbird suffers from the same.
It can be circumvented by saving the password encrypted and decrypting it using a master password. That is akin to how LastPass and Mozilla save their cloud data.
Using containers etc would also lower the threat.
In a way its good the password is saved locally. The engine also runs locally. It moves the threat model to the client, away from Nylas servers. Kudos.
The app looks great, but I just am not in favor of piping everything I have with email through your servers. Just a standalone app as basic version with opt-in for Google OAUth would justify its use case.
Nylas Mail Basic was designed exactly with this in mind. It's a free client, syncs locally, and does not include a lot of the Pro features that power users save a lot of time with.
On the flip side, we've designed Nylas Pro (and its price point) for users who are coming from the productivity world of ToutApp or YesWare. The goal with Pro isn't to merely be another Thunderbird or Mac Mail. We're focused on building new powerful workflows for people who live all day in their mailbox, calendar, and address book.
I used Nylas back when it was free, and it is a good email client, but it just wasn't worth $7 a month to me, and certainly not $12, especially when I consider that Office 365 Business Premium is only $12.50 a month, and includes Outlook, Word, Excel, etc. I would never use Office 365 personally, but when I consider the value offered by Office 365 Premium vs. Nylas, for about the same price, it makes Nylas Email look grossly overpriced.
It seems to me that Nylas could make a lot more money by charging $1 a month, since there are likely many, many more people willing to pay $1 vs. $12. Probably more than the 12 to 1 ratio required to break even.
I like Nylas, and think it is a good email client, but their pricing suggests they haven't done the market research and competitor analysis required to price themselves strategically and to be successful.
> It seems to me that Nylas could make a lot more money by charging $1 a month, since there are likely many, many more people willing to pay $1 vs. $12. Probably more than the 12 to 1 ratio required to break even.
Do you have any data on this? Would love to see it to help inform the research we already did when pricing the Pro edition of Nylas Mail.
Not for Nylas, since spending the time to do that research wouldn't benefit me. I'm happy to do it for a salary though.
Having said that, I can offer you this isolated anecdote (as worthless as that is): The last company I worked for used to use Nylas, before the pricing was set to $7 a month. When your company started charging for Nylas, we all stopped using it, both personally and professionally, and the general consensus during the transition away from your product was basically, "I'd continue to use it if it were around a buck." We understood the need for your company to make money, but $7 a month seemed too steep to us, so we went elsewhere.
I think it is great if you're able to succeed at $12 a month. I certainly won't begrudge your success. It just seems to me that at the $12-price-point, your competitors are offering much, much more. There are also free options, like Boxer, that work satisfactorily and are still free.
I'm not knocking your product. I liked it when I was using it, and I think you're trying to succeed in a difficult market, so kudos for making the attempt. I just don't personally value Nylas Mail at $7 (or $12) a month, and reading through this thread, it seems there are others who feel the same way; which I would think you'd want to consider as you fine-tune your business model.
Anyway, best of luck to you. I wish you all the success you deserve.
How is this different than Mail and every other email client in existence?
Don't get me wrong, it looks extremely good.
However, I visited the site and immediately clicked on the back button.
I've been using Google Inbox for a few months, and it radically changed how I handle my many mailboxes. It's not rare now that I actually achieve inbox zero.
I would love to see the same amount of innovation that was put into Google Inbox (I think they might have acquired it, though?) in another email client, as I'm always looking to try things out.
In Nylas, I see the same things that make dealing with email a pain: folders, the trash and spam being given the same importance as the inbox, etc.
It's set up to make it a job to keep your emails organized, while you shouldn't keep them organized, because it's just doesn't matter: just reply and mark as done, snooze until you can reply and mark as done, or discard/mark multiple emails at the same time and go on with your life.
Nylas Mail Basic and Nylas Pro are all built on an open source, highly extensible, modern platform. This lets us deliver a very familiar clean experience out of the box while supporting the ability to add an enormous number of very powerful features very quickly.
Everyone uses email slightly differently. The plugins allow us to build Salesforce integration, tracking, templates, and mail merge for sales people, while offering an entirely different targeted set for other users.
We intentionally "don't move the cheese to far" from existing clients to ease transition. There are a lot of grand ideas for radically different email experiences that fall flat due to their deviation from the core experiences most people expect and need. We instead believe that a handful of targeted features to a targeted group gradually develop into a very different way to interact with email for a very specific use case.
Your goals seem to be different than mine (and there's nothing wrong with that).
I'd rather lose Salesforce integration, tracking, templates etc. and get the basics right: going through the dozens of emails we get every day.
When we reply to emails we feel like we're being productive, but we're just taking time away from our actual job. If there's no easy way to easily differentiate between low priority and important emails—which Google Inbox does automatically by grouping them and letting you dismiss them all at once—you're not helping me.
Again, the product looks awesome, this is just my point of view I thought I'd share.
I suspect the parent is thinking of the Sparrow acquisition by Google, but Sparrow was a native app for OS X/iOS; thus it stands to reason that the acquisition was more of an acqui-hire for creating/refining Inbox. [1]
I love Google Inbox as well. The one downside that bothers me is its performance. It can be very slow and tends to gobble up resources the longer you have the tab open. I'm constantly on the lookout for a native desktop app that matches its features and ease of use.
I was a bit bummed to not see Windows support either...especially when there's a screenshot showing how to install on Windows on the download page. I registered for an account thinking that an auto-download had already started, so I was extra disappointed by a "Coming soon" prompt. Just felt a little bait-and-switch-y.
I've tried it, I wanted to love it, but man was the self-hosted sync engine a pain in the ass. Seemed like this was a totally second-class offering from Nylas, there were several known bugs where the client had problems syncing with self-hosted engines and the response was seemingly "we know this is a problem with self-hosted sync engines, we'll try to fix it eventually". A fair enough response to me as a nonpaying user who didn't want their cloud offering, but certainly enough to get me to stop using their open source offerings as my email client.
> Today’s release supports Gmail/G Suite, Office365 Exchange, Yahoo! Mail, iCloud, and FastMail. Full support for self-hosted Microsoft Exchange servers is coming soon.
I am a little curious why this is so limited. All of the above solutions support IMAP, so why is this so specific? I could understand if they're trying to support, say, Gmail-specific features of your inbox, but a provider like FastMail is pretty much entirely standards-compliant, AFAICT.
So it's closed source, by a US company (subject to NSLs, violating foreigners rights etc) and they get a copy of all my mails? At least that's what it sounds like.
The cloud service is also open source, like the client. And they specifically said in this blog post they've actually reduced the dependence on the sync engine, the client now connects directly to mail providers, and the cloud service is needed only for specific features of Nylas.
A normal e-mail client doesn't suffer from this issue. Only if the user is hosting their e-mail traffic inside the US. You may think that's true for everyone, but that is your own bubble or tunnel vision. Say, you are working at the EP (European Parlement). You use Mozilla Thunderbird for your e-mail. Some of the e-mail you receive is internal from your party. The SMTP and IMAP server is hosted in your European country. Then, one day you switch from Mozilla Thunderbird to Nylas N1. Suddenly, your e-mail is not hosted in the EU anymore, and the US government can use a NSL to read your private data. You may not give a rat about this (and if you're from US I can fully understand), that's your discretion. Others do, and their viewpoint is not 'absurd'.
> Which supported service is not already running in the USA and subject to NSLs?
Any SMTP and IMAP server not hosted in the USA. You know, you don't have to use Gmail.
(Nylas Mail doesn't suffer from this problem. Only a few features still require Nylas servers.)
This comment made me smile. Mostly because it threw a new a new light on what I was already thinking; self-host (love how my phone assume I mean "self-hatred", not "self-host", btw) the whole stack, and avoid new security issues that come with forced hosting in hostile jurisdictions.
But take a new daemon that talks a cross product of tls/ssl and three(?) protocols, is supposed to parse random emails, expose it to the Internet - and claim "no new security issues"?
It's reasonable to point out this, true. But in the scope of the parent discussion, it was about NSLs from hosting in countries with compromised providers. If you are running your own mail server, you have mostly the same security issues you need to zealously guard against, wherever you put it.
I have not used Nylas but if email is a tool that is integral to your productivity, paying for a tool that helps you is not a far-fetched idea. It's the same as with text editors. There are plenty available for free but if there's one that happens to help you in your work, paying less than 0.1% of your income can hardly qualify as excessive.
At $7/month, if this tool saves you 10 minutes a month, it's worth it.
Maybe I'm weird, but it's worth more than 10min/month to me not to have another recurring charge on my CC, before the amount of money is even considered.
It is worth if it weren't a subscription model. People are reluctant to have another monthly bill. Give me a price for the package and be gone with it.
In this day and age, open source tools are usually more private than their closed source counterparts. Usually. But, they also usually require you to do extra configuration or setup to get the privacy benefits
I do really like Nylas, it's mostly a pleasure to use.
But I'm using it with Gmail which costs me like $2pm for 100GB storage; the core (with I think 20GB?) is free (at the point of use, blah-blah advertising).
Is Nylas, the thing through which I access my free/almost-free email really adding $12pm value? I'm not so sure.
Nylas Basic is free forever. We hope you'll like it so much that you'll upgrade to Pro.
Essentially, we started as a free beta at the very beginning, launched with free trial last year, and now have switched to freemium (with a free trial on the Pro version still there).
The Nylas client doesn't connect to you mail provider directly, instead the Nylas client connects to the Nylas Sync Engine. It used to be that using this API for this was a couple hundred a year, per account.
Both the client and the sync engine are open source, so you've always been able to host your own.
I use Nylas but I recently had to move from a 2013 MBP to a 2008 MBP and it shows how unresponsive the UI is. I'd like to use something such as mutt but I find it very unfriendly.
There are serious privacy concerns[1] with spark though. One alternative to Polymail which is not often discussed is Canary Mail[2], which I've always found to be reliable and good looking.
Nylas has a keymaps.json (as well as the UI of course) which is a +1 in my book. Unfortunately other things missing from textual config, such as mail rules (filters).
So much for people saying "machines now are good enough for most basic uses and don't need upgrading anymore"... I guess Intel should be thankful for The Rise Of Electron Apps.
And modern software that behaves respectfully, I'd expect, especially if it's doing something that my 100Mhz Pentium w/ 64MB (with an M) of memory used to manage just fine (graphical email client). With the bonus that newer machines can run more such programs at once, and enjoy longer battery life.
I'm not sure what your point is. Nylas looks pretty cool, but is it doing so much more than other 10 year old email clients? Is it features or implementation choices that lead to relatively high resource usage?
Apparently on the basic version it connects directly to your mail servers without going through Nylas' cloud. But there are a couple of features which still require the cloud to funtion, snooze etc.
I used Nylas for a while after it was first released and really liked it. Then one day out of the blue I started getting sync errors and it basically stopped working (I've talked to multiple people that this happened to). After spending a couple hours, removing, reconnecting, re-installing, all with no success I gave up and stopped using it (actually attempted using again a month or two later with the same results). Would've been great to have local sync from the beginning as I actually might've paid to use it if I wouldn't of encountered so many issues and lost time trying to fix them. Now it looks like everything that I used to use and like about the app is only included in the paid version, and there's no way I'm going to pay just to see if they fixed the issues.
I'm really enjoying spark (https://sparkmailapp.com). I would try Nylas, but snooze is an absolute deal breaker for me. I'd highly recommend making that a free feature.
Spark has similar shortcomings: it isn't an email client, it is an email `service.` It relies on a third party service (other than your email provider).
Is this image from before or after selecting "Load Remote Images", assuming Nylas has such a feature? Also, what is the default configuration? To load remote content, or to not?
I looked at this app in depth and used it for about 2 days. Overall it is fairly usable and I liked it but the memory usage is killer. On a MacBook Air with 8 gigs, it uses 979 megs out of the gate and bloats up an additional 100 megs by the next morning. More details here: http://fuzzyblog.io/blog/email/2017/01/18/nylas-mail-review....
Ok I will try it again. I have to say when I used it during the trial, I liked it a lot. Love the inverse theme and the customization that is allowed. My only bad experience was, I ran the OS update that killed their app. It stopped updating with their server, then a week later started taunting me to pay money. It's not their fault the app stopped working. It was just bad timing that left a bitter taste in my mouth. I really do like the app and looking forward to reinstalling and configuring right now.
I actually really like it. It's funny how many Electron apps I have been using lately:
- Visual Studio Code
- Hyper Terminal
- Nylas Mail
- Slack
- Whatsapp Desktop
- ...
Nylas Basic supports generic IMAP accounts. We don't show them in the list of supported providers for QA reasons but you can still add such an account like this: https://imgur.com/a/WBdXe
(By the way, feel free to open a Github issue if you're encountering problems syncing your IMAP account: https://github.com/nylas/N1/issues/)
I am not sure how much faster it is right now, but last time I tried N1 just hanged when i plugged in my gmail account ( it just have like 8-10gigs of emails for last god knows how many years). But that is what happen to pretty much any mail client I tried on mac. I end up using only inbox in the browser/android.
No new funding model, just better tech! In the new version, we don't sync and store all of your email on our servers, which dramatically drops the cost of running the service.
Thanks! Thankfully we have both the Nylas Pro offering and the Nylas Cloud APIs as revenue streams. (Seriously, if you're integrating with email, check out the Nylas Cloud APIs: https://nylas.com/cloud)
It's been over 1 year since a blog post on the Thunderbird blog [0]. Is there any possibility for an update? Maybe something like "All the cool things we worked on in 2016?" (E: I realize 'developer' does not necessarily mean 'part of the Mozilla team developing it/in charge of the blog' but you may have better contact with someone who can get this done than I have. :] )
It was to my understanding that development, outside of security fixes, was more or less halted. Although looking at commits this doesn't seem to be the case [1]. While I use and enjoy Thunderbird, I was also under the impression is was more or less frozen/dead in the water/EOL.
This bug has been open for ~14 YEARS. Thunderbird not being actively developed is not exactly a recent development.
Reading through this thread I see tons of great MacOS mail clients, but very few Linux and essentially zero Windows. That's why I still use Thunderbird myself-- nothing better has ever come out.
The reason for the lack of implementation has very little to do with a fault on the side of Thunderbird. It's been blocked on Firefox people accepting the changes in https://bugzilla.mozilla.org/show_bug.cgi?id=441414 (which they finally categorically refused to do a few years ago).
Yeah, it's the usual open-source ego-driven squabbling.
Whatever the reason may be, users were left without this extremely useful and desirable feature for fourteen YEARS. Thunderbird at its core today acts and performs essentially identically to 2003. I've been using it myself since well before that. Development on the mail client hasn't meaningfully progressed since, well, _ever_.
We really hope that Nylas Mail will be your cross-platform email app then. Being build on Electron allows us to support all three major platforms and we are 100% committed to it. Nylas Pro (formerly N1) already supports all three and Nylas Mail should be there in a couple of weeks, if 'e0m is to be trusted. :)
You announced your project with tons of fanfare but no Windows client. I realize MacOS is very popular amongst developers, but Windows has a 91% desktop OS marketshare.
From a broad marketing perspective, you should have waited until the Windows client was available. When you finally release it in a week or a month, will you get another frontpage Hackernews post? Probably not.
great to know and in fact I think mozilla should focus more on thunderbird instead of just firefox, indeed chrome is taking market share from firefox (and everyone else) rapidly these days, it's a fact, while google does not have any interest in a cross-platform email client since google wave.
What motivated the decision to give again the option to use Nylas for free?
I remember reading that your target were kinds of "email power users", for whom you would offer the ability to create advanced workflow. Did this change?
Free trial versus freemium. If you have a larger base (free tier), even if a small percentage upgrade to paid, then you may make more money. It's what Dropbox and Slack do.
But Dropbox has always offered the free option.
Nylas used to have a free plan, but at some point took it away entirely -which actually meant cutting away a part of their base.
I feel like they might change their mind again and remove the free plan.
> We already sync several hundred terabytes of data for our users and are adding tens of thousands of new users each month. It’s costing us real dollars.
This is now changed with the new architecture in Nylas Mail.
Honestly this move is something that might bring me back into it. It opens up an already existing codebase for basic functionality to users who wouldn't be paying otherwise- and perhaps with dependence on this service or interest in more that it offers, they may turn into a subscription user.
The same happens for me with ProtonMail. I used the basic service but found that the convenience of a paid plan was enough for me to pay.
I was sort of put off by the look of Nylas though, in regards to the lack of a "native" feel. It was convenient, but I was forced into a paywall before I could really get acquainted as someone who isn't a power email user.
Ugh, Emojis are thing for very informal conversations - your friends. Seeing them splattered in somewhat official statement looks so out of place and unprofessional.
This is amazing. I was using this client all the time until they were not free enough. The price was way too high imo so I stopped using it until today.
First of all Apple's Mail.app is a native macOS application. Nylas is based on Electron, the Chromium/NodeJS platform originally designed by GitHub when they were building the Atom text editor.
I do understand the need for a better modern open source email client (not trying to start any kind of client war here), but I really want something that doesn't rely on an external server.
1 - any suggestions for an open source alternative that provides email snoozing on linux (that's a big part of my email processing)?
2 - any good guide on how to self host the Nylas server on my home server (I know they have the project on GitHub but the instructions are a bit too complicated for me, although that's perhaps my sysadmin skills are quite low)?
Well, there are standards for that (RFC 3798 as pointed out above), but this is entirely something in your control so that you can know if an email was read or not. You choose to turn on tracking (on a per-email basis with a default of your choosing) and then get notified whenever that tracking pixel is hit.
And the thought that using Electron and being the best email client are incompatible concepts is misguided. There are many quality products built on top of frustratingly bad technology stacks. But if you think about it, Gmail is a web app too. Different wrapper (your browser), same tech stack. And Gmail is pretty good.
The support page states that "If you’re using N1 against our open source sync engine, you’ll still need to create a Nylas ID."
Given the privacy policy says that Nylas shares information with third parties and that they can "make a copy of the entire contents of the applicable email inbox, calendar, and contact book", it doesn't feel like a traditional email client to me.
https://support.nylas.com/hc/en-us/articles/220974588-How-is...