341–350 of 608 posts
Earlier quoted context omitted.
How much RAM does your mail client use?
I use notmuch with Emacs - so very little. Before that I used mutt - also very little.
Earlier quoted context omitted.
I think SyneRyder means what format are you storing emails on disk? If a user uses your email client to download all their pop3 email, is it available in a nice format on disk for whatever reason (backups/file recovery/migration to another client)? Or is it locked up in a custom file format.
Currently it is not a standard format so right now there is no easy import/export - however this is a feature that is coming.
What is the reason you do not store in a standard format?
Earlier quoted context omitted.
For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB. I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does). Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though i…
> Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB. Yes, but that’s not a fair apples to apples comparison with his 300mb number. Your looking at the memory used for that tab, not the shared memory used by the browser across tabs. Open Firefox with no sites open and check your baseline memory usage. Add that to the numbers above for a direct comparison.
Earlier quoted context omitted.
I prefer VS Code over native alternatives. Don't conflate your anecdotal evidence with facts. Many users don't know much RAM a process consumes or what an Electron app is, they just care about what the app can do, how fast it is, etc.
> I prefer VS Code over native alternatives. That's because, as the parent said, there are no good (e.g. equivalent) native alternatives. If there was a native editor with feature parity with VS Code (including the number of plugins and dedicated MS resources speeding up its development, and free), nobody would be using it.
>That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.
But that's not true. I use Sublime Edit and have happily used BBEdit and TextMate. Emacs is fine for many people, and I still use vim for fast edits in terminal mode all the time. There are plenty of other great native editors for just about all platforms.
Earlier quoted context omitted.
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…
> Writing a UI multiple times is monumentally expensive. 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 companie…
As others have pointed out in this thread: Qt is not really that much lighter than the web. It draws its own controls and even has css-like styling. I remember Qt apps being relatively slow on small machines... maybe not quite as slow as Electron but the latter could be tuned and improved and made competitive IMHO.
Your main point is valid, but you shouldn't be focusing your anger at Electron or at programmers for choosing it. You should be focusing your anger at desktop vendors for refusing to offer a better way to develop cross-platform apps in favor of an ultimately foot-blasting quest for platform lock-in. By refusing to play with each other desktop vendors have doomed all their platforms to obsolescence and abandonment.
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…
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…
Consider Electrino ( https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w... )
Earlier quoted context omitted.
Well that's just not accurate. With our Electron app, the main process consumes 40mb of RAM, with each window using 30mb of RAM, so if you have a windowed app, thats a minimum of under 70mb of RAM (results will differ, our app is quite large).
Yeah, this is realistic. I wish people would stop perpetuating the myth that "That's just how Electron is" . It's perfectly possible to write Electron apps that don't automatically hog half a gig of RAM.
Love the work you put into this and the detail put into describing the features. One thing missing from the site. Why did you make it?