Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nylas Mail is now free

blog.nylas.com

Post reply on HN
Print view View original

281–290 of 334 posts

Re: Nylas Mail is now free

#281

Post by spion »

cookiecaper wrote: post #64
g105b wrote: post #29

Earlier quoted context omitted.

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.). One day someone will build a good Electron app.

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 bast…

"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".

Re: Nylas Mail is now free

#282

Post by hota_mazi »

iancarroll wrote: post #224
hota_mazi wrote: post #216

Earlier quoted context omitted.

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. http://blog.mailchimp.com/how-gmails-image-caching-affects-o...

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.

Re: Nylas Mail is now free

#283

Post by ausjke »

jcranmer wrote: post #156
ausjke wrote: post #44

still using thunderbird that is really, totally free, I recall it is EOL, looking for alternatives.

Thunderbird is not EOL. Disclaimer: I am a Thunderbird developer.

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.

https://www.w3counter.com/globalstats.php

Re: Nylas Mail is now free

#284

Post by e12e »

allover wrote: post #280
criddell wrote: post #73

Earlier quoted context omitted.

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.

His lazy comment doesn't need rationalising. 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.

Vim?

Re: Nylas Mail is now free

#285

Post by wanda »

rrdharan wrote: post #257
nkkollaw wrote: post #166

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 Go…

> I think they might have acquired it, though? Inbox is homegrown, not an acquisition. (work at Google)

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]

[1] https://twitter.com/jmdenisme/status/524968589489479680

Re: Nylas Mail is now free

#286

Post by nkkollaw »

wanda wrote: post #285
rrdharan wrote: post #257

Earlier quoted context omitted.

> I think they might have acquired it, though? Inbox is homegrown, not an acquisition. (work at Google)

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] [1] https://twitter.com/jmdenisme/status/524968589489479680

Yes, I used to use Sparrow.

Re: Nylas Mail is now free

#287

Post by e12e »

ocdtrekkie wrote: post #181
kuschku wrote: post #164

Earlier quoted context omitted.

> Which supported service is not already running in the USA and subject to NSLs? Quoting >> You actually can add any IMAP server Well, my own server?

And in that case, you can surely run your own Nylas sync engine server alongside it. Which still adds no new security issues with using Nylas.

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"?

Oh, how I whish that could possibly be true.

Re: Nylas Mail is now free

#288

Post by [deleted] »

jamesgeck0 wrote: post #275
Fnoord wrote: post #243

Earlier quoted context omitted.

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 y…

I don't think the free version of Nylas Mail is storing IMAP passwords, plaintext or otherwise. For Gmail, at least. 1. You never enter them into the client. It uses Oauth to authenticate. 2. By the comment here, it seems that they're using Google's Gmail API. https://news.ycombinator.com/item?id=13417904

[deleted]

Re: Nylas Mail is now free

#289

Post by yoasif_ »

nopzor wrote: post #266
yoasif_ wrote: post #219

Earlier quoted context omitted.

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 "che…

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.

Re: Nylas Mail is now free

#290

Post by charrondev »

cookiecaper wrote: post #64
g105b wrote: post #29

Earlier quoted context omitted.

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.). One day someone will build a good Electron app.

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 bast…

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.

Post reply on HN