> As an aside, Thunderbird occupies that uncomfortable space of software that is libre, but seems so bloated and complex I don't want to install it, let alone work on it. I'm not sure if that perception is "accurate" (which of course depends on how you define things). But think of OpenOffice/LibreOffice. It's a huge, classically written C++ blob that is hard to check out hard to build and hard to contribute to. Yet, its very existence undermines the motivation to start something new.
I think what those have in common is being corporate codebases that were "dumped" as open source. If you look at the equivalents that were built as open-source from day 1 - KMail, Konqueror, and KOffice - you find something that while still C++ is much cleaner and better structured, since they were always meant to be maintained by a distributed collaboration rather than a small team of l33t h4x0rs.
> Surely there is a space for minimalist office suites and email clients, written starting with a browser as a jumping off point, rather than a compiler? I guess I'm arguing for an Electron-based docs/sheets/email/calendar using modern software best practices, and great components. An email client should be a webview + sql-lite, no? And (for office docs) maybe with a more thoughtful file format, like a simple html subset. Does this exist?
I don't think browser-based is the right direction, and I actually think browser-based may detract from having good standard UI component libraries, since the browser itself tends to fall into the trap you mentioned - browser-native components are simultaneously not great, but imposing and complex enough to suck the oxygen away from alternatives. But I agree there's a lot of value in using existing frameworks and libraries to develop your applications, and definitely something that contributes to both OpenOffice/LibreOffice and Mozilla-family applications being as complicated as they are is the fact that they include their own one-off GUI frameworks. (In fairness Mozilla did originally make a legitimate attempt to make their GUI framework an actual first-class GUI framework that could be used for other applications with XULRunner etc., but those days are long gone now). Again this is somewhere where I find KDE family applications shines in comparison - everything is properly layered between the libraries, frameworks, and applications, and the libraries actually see reuse across a wide range of applications.