281–290 of 608 posts
Earlier quoted context omitted.
Because of Privacy concerns! The thinking is that few people would enter their email and email password on a 3rd-party website, having it as a downloadable software ensures the privacy of users
Although, in reality, that doesn't make it more secure.
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.
I don't think this puts enough emphasis on the fact that it is a local client and not a web service. I see some people here griping about Electron, but the privacy implications of being a local app are way more important than the performance of the framework used.
What is the reason to build it as a native software instead of a webapp? Seems like a lot of email clients are now webapps and I can see the arguments why.
Because of Privacy concerns! The thinking is that few people would enter their email and email password on a 3rd-party website, having it as a downloadable software ensures the privacy of users
Earlier quoted context omitted.
Because of Privacy concerns! The thinking is that few people would enter their email and email password on a 3rd-party website, having it as a downloadable software ensures the privacy of users
Would love to be able to self host this though and access it through the browser... That'd be awesome.
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...
Earlier quoted context omitted.
> 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. Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development? In other terms: Maybe the portable native full featured VS Code is th…
> Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development? It could -- though I doubt it. But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?
I understood what you meant. I respect you disagreeing with my premise, but in the scenario where that premise is true, your question is not applicable.
Scenario: Would anyone choose MDF boards at IKEA if they could choose plywood or natural wood, or assemble their own furniture if given the choice (at the same price)? Barring a few applications, probably not. But IKEA wouldn't be IKEA if they were just another producer of wood furniture, meaning they got to market and stayed there because of the shortcuts and limitations they could justify when reaching a price.
Same thing here (IMHO). VS Code could have some cross-platform code and some platform specific code, but the cost would be higher and the output velocity would likely be lower. Assuming that is true, your question is misleading, albeit not on purpose.
What is the reason to build it as a native software instead of a webapp? Seems like a lot of email clients are now webapps and I can see the arguments why.
Because of Privacy concerns! The thinking is that few people would enter their email and email password on a 3rd-party website, having it as a downloadable software ensures the privacy of users
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…
"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…
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 X or with X language/font/etc. That's my problem with all these ultralight immediate mode UI libs like nuklear. It's like going back to MS-DOS or CP/M and saying "wow that's simple and fast!" Yeah but it lacks a lot of stuff you will need.
The web's rendering layer isn't perfect but it's better than many alternatives and isn't going anywhere, so putting a lot of effort into making it more efficient and robust is very logical.
Earlier quoted context omitted.
The webapp can send your data wherever once it has the data, chrome won't log http requests if they were made server to server etc
Isn't it the case for any app?