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, trash the MVP.

Personally I'm far more worried about the first noted limitation about email forwarding with attachments not being available. I'd have wanted that before most of the showcased features, none of which I find particularly interesting. But I applaud the effort and the Polish, and the approach to build the tool that you want/need when. You can't find one.

(Second worry would be: if it's not open source, please make so.)

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

+1

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.

But if NASA let startup hackers write their code, we would be!