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

261–270 of 334 posts

Re: Nylas Mail is now free

#261

Post by cookiecaper »

bpizzi wrote: post #200
cookiecaper wrote: post #64

Earlier quoted context omitted.

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…

> It brings us enough pain as the only practical client-side language on the web. That's plainly wrong. The list of praticals client-side language on the web is actually pretty vast: https://github.com/jashkenas/coffeescript/wiki/list-of-langu... . 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…

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.

[0] https://github.com/google/grumpy

Re: Nylas Mail is now free

#262

Post by baby »

gnufied wrote: post #8

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. :(

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

Re: Nylas Mail is now free

#263

Post by ComputerGuru »

e0m wrote: post #15
gnufied wrote: post #8

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

> The Chromium team goes through great lengths to save power and most of those efforts get reflected in Electron.

Citation needed. Battery life with Safari on Mac or IE/Edge on Windows is easily twice that of Chrome/Chromium with the same tabs open.

Note: I'm not disputing that the Chrome team has put in significant effort, but rather that the results are anything above mediocre at best.

Re: Nylas Mail is now free

#264

Post by cookiecaper »

bpizzi wrote: post #204
blub wrote: post #196

Earlier quoted context omitted.

Your message left me scratching my head. 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 lan…

> Sure, nobody will kill HTML and JS, but that's not the point. Yes, it is the point. Nothing more, nothing less. > Nobody knows how UIs will be built with web technologies in two years! You can't say that things like es6/react/typescript/clojurescript will be plain gone in two years, there's too much real momentum behind these things.

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.

Re: Nylas Mail is now free

#265

Post by rspeer »

jhasse wrote: post #249
rspeer wrote: post #152

Earlier quoted context omitted.

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…

> and it's so non-native on macOS that you have to run an X server just to see it. Gtk has been ported to macOS in 2007. You don't need an X server anymore :)

Oh! Sorry. I suppose this is what Inkscape for Mac is using; that makes sense.

Does it support hi-DPI yet?

Re: Nylas Mail is now free

#266

Post by nopzor »

yoasif_ wrote: post #219
e0m wrote: post #106

Earlier quoted context omitted.

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

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.

Re: Nylas Mail is now free

#267

Post by philfreo »

karim wrote: post #100
shreve wrote: post #54

Earlier quoted context omitted.

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

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?

https://www.dropbox.com/s/s37onyv41w91zi0/Screenshot%202017-...

Re: Nylas Mail is now free

#268

Post by brazzledazzle »

thatcat wrote: post #178
jcranmer wrote: post #162

Earlier quoted context omitted.

Unless your recipients use email clients that don't load remote http images except on demand. I can think of one email client with ~15 million users that does that.

Which client blocks remote images by default? Is it a cli or gui?

I believe Exchange/O365/Outlook block by default when the senders are outside the organization.

Re: Nylas Mail is now free

#269

Post by spion »

cookiecaper wrote: post #264
bpizzi wrote: post #204

Earlier quoted context omitted.

> Sure, nobody will kill HTML and JS, but that's not the point. Yes, it is the point. Nothing more, nothing less. > Nobody knows how UIs will be built with web technologies in two years! You can't say that things like es6/react/typescript/clojurescript will be plain gone in two years, there's too much real momentum behind these things.

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

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

Re: Nylas Mail is now free

#270

Post by cookiecaper »

bpizzi wrote: post #209
blub wrote: post #192

Earlier quoted context omitted.

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.

> 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".
Post reply on HN