Live data from Hacker News

I've spent the last two years building a new email client

ivelope.com

601–608 of 608 posts

Re: I've spent the last two years building a new email client

#601
post #523

Earlier quoted context omitted.

If their tech stack isn't appropriate for the job, then they shouldn't be using it for. We don't have people writing software for space probes in Python.

Yes, but: - we're not talking about space probes, - this is just one dev who thought "I want to write an email client" and make a tech choice based on his/her own proficiency with that stack and his/her project constraints (time, cost, quality, scope). It seems unfair to rant so much about it. If it's feature full and good and perf becomes an issue, consider it an MVP and a stack change is doable. If the thing blows,…

> if it's not open source, please make so

+1

Re: I've spent the last two years building a new email client

#602
post #596

Earlier quoted context omitted.

I would normally agree with you but I can actually see the point of Electron for email because you'd need a HTML renderer anyway to display emails (assuming you want the ability to view HTML emails, if not then you're better off with a console client and save yourself even more RAM :p) Plus Gmail and a few others big names in webmail require a HTTP client for authentication if you want to use their proprietary sync (…

What does rendering HTML or needing a HTTP client have to do with Electron? As far as I know, every single usable language comes with a HTTP client, and every single GUI framework has a "WebView" control or equivalent.

WebView's are typically just WebKit / Blink / Trident / whatever embedded anyway. So if you're going to embed Blink then you've already lost any significant memory savings you'd hope to make by avoiding Electron in the first place. Thus you might as well write the whole thing in Blink / Electron from the outset as that will also give you massive developer productivity gains (which it will - such is the sad state of desktop application development these days).

As for the HTTP client point; you can use a simple HTTP API (libcurl or whatever) to perform the webmail authentication but honestly you're in for a whole world of pain because it's really more than just a HTTP call. Ideally you'd want another webview for that as well. Oh how all those individual webviews are going to add significantly to your memory usage. You might as well consolidate them all into one...let's call that new WebView "Electron" shall we ;)

Re: I've spent the last two years building a new email client

#603
post #289
post #277

Earlier quoted context omitted.

"Qt isn't that much less bloated than Electron, especially when you start styling it and get dynamic." Given how many smart people are working to make the browser techs as efficient as possible, and the way that things like QT get "bloated" as soon as they start trying to do what browsers do, I've pretty much arrived at the idea that once you have images and an engine that can reflow text and load fonts and so on, an…

I totally agree. Modern UIs with support for themes, complex interactions, multiple screen and pixel formats, and every language spoken by Homo Sapiens since Gobekli Tepi was built are large and complex. It's not avoidable. That is the problem domain. If you're doing less than that you'll regret it when more and more users start requesting features you don't have or complaining that your product doesn't look right on…

> Modern UIs with support for themes, complex interactions, [...]

And don't forget accessibility. That's the part that makes me want to scream whenever I see a new lightweight UI toolkit on HN.

Re: I've spent the last two years building a new email client

#604
post #203

Earlier quoted context omitted.

Or you use qt. Which is cross plateform, native, fast and open source.

Ask yourself why more people don't use Qt: (1) With web technologies you can write once and run everywhere including mobile to some extent. Writing a UI multiple times is monumentally expensive. Even huge companies don't like to do this, let alone indie efforts and startups. If Slack with its billion dollars doesn't do it what does that say? (2) The ecosystem is far more active. The web is the largest open source eco…

> Trouble is everyone I show [libui] to says "ugly" as their first comment. Everyone wants styled apps today with polished UIs

I don't think I'll ever understand this. What about consistency between apps? Sticking to the OS's native widgets and style will get you that. Do people really like it when each app has its own look?

Of course, I'm no judge of aesthetics. Being visually impaired, my idea of a perfect UI is something with high contrast and large text.

Re: I've spent the last two years building a new email client

#605

Earlier quoted context omitted.

But we do have people writing some of the most used email clients in the world using HTML and Javascript, so that's hardly a valid criticism in this case. https://emailclientmarketshare.com/

Apple iPhone, Apple iPad, Outlook, Samsung Mail, and Google Android, together making up well over 70% of that list, are all native clients. Plus, the clients that aren't native are all web-browser based.

So 30% of marketshare belongs to clients built on the browser technologies of HTML and Javascript, the same technologies you claim are "inappropriate" for the new client that we're discussing.

Re: I've spent the last two years building a new email client

#606
post #482

Earlier quoted context omitted.

I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be. My OS has UI semantics. I want most of the apps to work the same everywhere. Your app is not special. Stop reinventing a "visual identity". Give me congruency and features.

"I agree with that to some extend, but the fact is, except for some very specific cases like vscode, I not only don't need "styling and dynamic", but I don't want it to be." Actually, I'm not referring to things like colors or fonts. What I'm referring to is the fact that had the web-browser style layout algorithms not been already invented by web browsers, they would have been invented by the inexorable progression…

> you'll happily spend 100MB of the user's RAM to make the pain end.

And users, at least the savvy ones who hang out here, are saying that this RAM isn't ours to spend. Is there no way that we could spend more resources on our dev machines instead, at build time, to take a piece of code that was pleasant to write and convert it into something that's frugal with resources on the user's machine? C++ and Rust promise abstractions with zero runtime cost compared to the best that you could hand-code. I wonder if the same can be applied to multi-platform GUI toolkits, perhaps through compile-time metaprogramming.

Re: I've spent the last two years building a new email client

#608

Earlier quoted context omitted.

This is often heard but I don't think there is legal justification for it. It is pretty clear that it is your data, hosted on someone else's server that you pay by looking at ads and allowing them to read your mail. It is your mail nevertheless. Additionally, if we are really picky, only mail written by you is your mail. All mail received is normally copyrighted by someone else and belongs to the sender or/and his/he…

> All mail received is normally copyrighted by someone else and belongs to the sender or/and his/her company Source please? Shouldn't there be a creative aspect about it? Which is probably not the case for lots of emails.

Correct, that's why I wrote this at the end if the paragraph:

>[...] if it bears any artistic value.

Source: As this depends on the country you live in you would have to look up your country's copyright law and see if it's true for your country.

Post reply on HN