331–340 of 608 posts
Earlier quoted context omitted.
1. It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum, which is less than what Finder consumes, and I consider everything over this limit to be a bug. 2. Currently not supporting Mbox/Maildir but downloading emails directly from the server, however an import of this is on the todo list 3. Re: turn off conversation v…
> only around 300mb of RAM maximum For a email client that is still more than I ever would accept. Do you hold all conversations in the RAM for searchability or something?
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…
Earlier quoted context omitted.
This is a simple definition but I think it lacks a couple important things: 1. It doesn't match the words. If that defines a "web app" then where does the web come in? I would think part of being a web app is that you can access it via the web and don't have to install it on your device. 2. Usefulness of the distinction to users. The specific nature of the bundled runtime for the code doesn't matter to anybody. It st…
The word web comes in when “browser” is short for “web browser”. I can’t believe I had to explain that. As for the second issue: users care because performance is worse, accessibility is by and large non-existent and platform features don’t work. For example: macOS has tabbed windows at the core - any document based app gets it automatically. How does that work out for electron apps?
You didn't really have to. I guess I made my point badly. The fact that a "web browser" is somewhere in the chain of what is reading an application does not mean that the application itself has anything to do with "the web", so I think calling it a web app is confusing and pointless. And again, seems like a technicality.
> As for the second issue: users care because performance is worse, accessibility is by and large non-existent and platform features don’t work.
I agree with this in general. It doesn't mean it helps the user to call it a web app. Maybe we need a third, generic term for electron apps and others like them. A name that refers to the potential differences in performance, accessibility, and performance that users may notice?
Web app doesn't work for what you are talking about as far as I can tell. Of course this is an industry where terms and definitions change a lot.
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…
I'm confused by this statement. The point of Qt is that you write the UI once. Your controller back-end might have platform-related pragmas, but not the UI.
> If Slack with its billion dollars doesn't do it what does that say?
When you give programmers freedom to choose what makes life easy for them, end-user experience suffers?
I really think all dev companies should have a lab of 'consumer-grade' laptops with 4GB of RAM and 20Mbit/sec networking. And QC shouldn't let anything ship until it runs adequately on those. Particularly for a company like Slack that is targetting corporate users, the bulk of whom aren't software architects with 2017 MBPs ( who make the choice ) but small-cogs with a five-year-old Dell.
This looks pretty cool, I'm really pleased to see people writing new email clients, and you've clearly worked very hard on this! I have a bunch of questions that I couldn't find out from the website (but are obscure enough that I shouldn't expect to): * Is this a purely native app, or an Electron / Javascript app? Personally I'm only interested in native apps & Electron would be a deal breaker - but I'm weird, most p…
> Electron would be a deal breaker You say that like HTML emails don't exist. If the client has to embed a web view anyway...
Designed emails using HTML are used by marketing teams - not by people. I don't care to read emails from marketing teams "as intended to be viewed". Show me the email and let me read an email that's just a bunch of plaintext markup.
Earlier quoted context omitted.
I'm not convinced that JMAP existing will make it easier for people to develop things like Ivelope. I don't know in this particular case, but if I were writing Ivelope I wouldn't first write an IMAP library of my own. I'd use an existing one. And all commonly used languages have pre-existing IMAP libraries anyway. I doubt the ability to do "var client = new JMAP()" instead of "var client = new IMAP()" will lead to a…
I perceive that you haven’t ever tried programming against IMAP or making a MUA, or not seriously at least. IMAP is a mess if you try to do much beyond the basic “retrieve list of folders, retrieve messages, now just leave it alone”; and most IMAP client libraries are worse than IMAP need be. There are many extensions for many features, poorly supported in various clients and servers, and various things that are slow…
I, too, am quite excited about JMAP, although I have my doubts about ever trying to write an MUA ever again.
Earlier quoted context omitted.
> It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum I feel bad but you have already lost me there :/
How much RAM does your mail client use?
Before that I used mutt - also very little.
This looks pretty cool, I'm really pleased to see people writing new email clients, and you've clearly worked very hard on this! I have a bunch of questions that I couldn't find out from the website (but are obscure enough that I shouldn't expect to): * Is this a purely native app, or an Electron / Javascript app? Personally I'm only interested in native apps & Electron would be a deal breaker - but I'm weird, most p…
1. It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum, which is less than what Finder consumes, and I consider everything over this limit to be a bug. 2. Currently not supporting Mbox/Maildir but downloading emails directly from the server, however an import of this is on the todo list 3. Re: turn off conversation v…
I strongly prefer to disable conversation view, because the time (recency) and time interval (frequency) are obscured, at least from the inbox view of most readers.
There is a big difference to me between a thread with 10 emails in one morning, versus one with 9 emails over a week, followed by one this morning.