I use Gmail. I even pay for Gmail, which TBH really rankles, but I filled up my inbox, I want that stuff as a searchable record (not a Zip or something), any other way of storing dozens of gigs of email means either a lot more work, or moving to other paid storage so a lot of work and paying, so paying for more storage is the least-effort strategy.
I also use a few other web apps, mostly Google: calendar, contacts (I've been using pocket computers since the 1980s, so I have over 5000 people in my address book, and yes, I do want to keep them all), Keep for notes (because Evernote crippled their free tier and don't offer enough value to me to make it worth buying). I very occasionally use Google Sheets and Docs, but would not miss them.
But by and large, I hate web apps. They are slow, they are clunky, they have poor UI with very poor keyboard controls, they often tie you to specific browsers, and modern browsers absolutely suck and are getting worse with time. Firefox was the least worst, but they crippled it with Firefox Quantum and since then it just continues to degenerate.
I used Firefox because it was customisable. I had a vertical tab bar (one addon) – no, not tree-style, that's feature bloat – and it shared my sidebar with my bookmarks (another addon), and the bookmarks were flattened not hierarchical (another addon) because that's bloat too.
Some examples of browser bloat:
- I have the bookmarks menu for hierarchical bookmark search & storage. I don't need it in the bookmarks sidebar too; that's duplication of functionality.
- I don't need hierarchical tabs; I have multiple windows for that. So TreeStyleTabs is duplication of functionality – but it's an add-on, so I don't mind too much, so long as I have a choice.
- I don't need user profiles; my OS has user profiles. That should be an add-on, too.
- Why do all my browsers include the pointless bloat of web-developer tools? I and 99.99% of the Web's users never ever will need or use them. Why are they part of the base install?
We all have widescreens now. It's hard to get anything but widescreens. Horizontal toolbars are the enemy of widescreens. Vertical pixels are in short supply; horizontal ones are cheap. The smart thing to do is "spend" cheap, plentiful horizontal space on toolbars, and save valuable, "expensive" vertical space for what you are working on.
The original Windows 95 Explorer could do a vertical taskbar, which is superb on widescreens -- although they hadn't been invented yet. But the Cinnamon and Mate FOSS desktops, both copies of the Win95 design, can't do this. KDE does it so badly that for me it's unusable.
It's the Mozilla syndrome: don't take the time to understand what the competition does well. Just copy the obvious bits from the competition and hope.
Hiding stuff from view and putting it on keystrokes or mouse gestures is not the smart answer. That impedes discoverability and undoes the benefits of nearly 40 years of work on graphical user interfaces. It's fine to do that as well as good GUI design, but not instead of it. If your UI depends on things like putting a mouse into one corner, then slapping a random word in there as a visual clue (e.g. "Activities") is poor design. GUIs were in part about replacing screensful of text with easy, graphical cues.
Chrome has good things. Small ones. The bookmarks toolbar that only appears in new tabs and windows? That's a good thing. In 15 years, Firefox never copied that, but it ripped out its rich extensions system and copied Chrome's broken one.
Tools like these extensions are local tools that do things I need. Mozilla tried to copy Chrome's simplicity by ripping out the one thing that kept me using Firefox. They didn't look at what was good about what they had; they tried to copy what was good about what their competitor had. I used Firefox because it wasn't Chrome.
For now, I switched to Waterfox, because I can keep my most important XUL extensions.
I run 2 browsers because I need some web apps. I use Chrome for Google's stuff, and Waterfox for everything else. Why them? Because they are cross-platform. I use macOS on my home desktop, Linux on my work desktop and my laptops. I rarely use Windows at all but they both work on those too. I don't care if Safari has killer features, because it doesn't work on Windows (any more) or Linux, so it's no use to me. Any Apple tool gets replaced with a cross-platform tool on my Macs.
I also use Thunderbird, another of its own tools Mozilla doesn't understand. It's my main work email client, and I use it at home to keep a local backup of my Gmail. But I don't use it as my home email client, partly because I switch computers every day. My email is IMAP so it's synched – all clients see the same email. But my filters are not. IMAP doesn't synch filters. I have over 100 filters for home use and a few dozen for work use. I get hundreds of emails every day, and I only see half a dozen in my inbox because the rest are filtered into subfolders.
We have a standard system for cross-platform email storage (IMAP), that replaced minimal mail retrieval for local storage (POP3), but nobody's ever extended it to try to compete with systems, such as Gmail or MS Outlook and Exchange Server, that offer more, such as rules, workflow, rich calendaring, rich contacts storage. And so local email clients are fading away and more and more companies use webmail.
Why have web apps prospered so when rich local tools can do more? Because only a handful of companies grok that rich local tools can be strong selling points and keep enhancing them.
I used to use Pidgin for all my chat stuff. Pidgin talked to all the chat protocols: AIM (therefore Apple iMessage too), Yahoo IM, MSN IM, ICQ, etc. Now, I use Franz, because it can talk to all the modern chat systems: Facebook Messenger, WhatsApp, Slack, Discord, etc. It's good: a big help. But it's bloated and sluggish, needs gigs of RAM, and each tab has a different UI inside it, because it's an Electron app. Each tab is a dedicated web browser.
Pidgin, via libpurple plugins, can do some of these – FB via a plugin FB keeps trying to block; Skype; Telegram, the most rich and mature of the modern chat systems. But not all, so I need Franz too. Signal, because it's a nightmare cluster of bad design by cryptology and cryptocurrency nerds, doesn't even work in a web browser.
Chat systems, like email, are a failure, both of local rich app design to keep up, and of protocol standardisation in order to compete with proprietary solutions.
Email is not a hard problem. This is a more than fifty-year-old tool.
Chat is not hard either. This is a more than forty-year-old tool.
But groupware is different. Groupware builds on these but adds forms, workflow, organisation-wide contacts and calendar management. Groupware never got standardised.
Ever see Engelbart's "mother of all demos"? Also more than half a century ago. It included collaborative file editing. But it was a server-based demo, because microcomputers hadn't been invented yet. So, yes, for some things, like live editing by multiple users, a web app can do things local apps can't easily do.
But for most things, a native app should always be able to outcompete a web app. Web apps grew because they exploited a niche: if you have lots of proprietary protocols, then that implies lots of rich proprietary clients for lots of local OSes. Smartphones and tablets made that hard – lots of duplication of functionality in what must be different apps because different OSes need different client apps – so the functionality was moved into the server, enabled by Javascript.
Javascript was and is a bad answer. It was a hastily-implemented, poorly-specified language, which vastly bloats browsers, needs big expensive just-in-time-compiling runtimes and locks lower-powered devices out of the web.
The web is no longer truly based on HTML and formatting enhancements such as CSS. Now, the Web is a delivery medium for Javascript apps.
Why?
Javascript happened because the protocols for common usage of internet communications were inadequate.
This meant one company could obtain a stranglehold via proprietary communications tools.
That was a bad thing.
FOSS xNix arose because of standardisation.
xNix is a shorthand for Unix. Unix™ does not mean "an OS based on AT&T UNIX code". It has not meant this since 1993, when Novell gave the Unix trademark to the Open Group. Since then, "Unix" means "any OS that passes Open Group Unix compatibility testing." Linux has passed these tests, more than once. Both the K-OS and EulerOS distros passed the tests. This means that Linux is a Unix these days. Accept it and move on; it is a matter of legal fact and record. The "based on AT&T code" thing has not been true for thirty-eight years. It is long past time to let it go.
The ad-hoc, informal IBM PC compatibility standard meant that any computer that wanted to be sold as "IBM compatible" had to run IBM software, not just run MS-DOS. All the other makes of MS-DOS computer couldn't run MS Flight Simulator and Lotus 1-2-3, so they died out. Later, that came to include powerful 32-bit 80386DX computers, which allowed 32-bit OSes to come to the PC. Later still, the 80386SX made 32-bit computers cheap and widespread, and that allowed 32-bit OSes to become mainstream. Some, like FreeBSD, stuck to their own standards (e.g. their own partitioning schemes), and permissive licenses meant people could fork them or take their code into proprietary products. Linux developed on the PC and from its beginning embraced PC standards, including PC partitioning, PC and Minix filesystems and so on... and its strict licence largely stopped people building Linux into proprietary software. So it throve in ways no BSD ever did.
Because of standards. Standards, even informally-specified ad-hoc ones, are good for growth and very good for FOSS.
The FOSS world does have basic standards for email retrieval and storage, but they're not rich enough, which means proprietary groupware systems had an edge and thrived.
Web apps are the third-party software-vendor world's comeback against Windows, Office and Exchange. They let macOS and iOS and Android and ChromeOS (and as a distant outlier, other Linux distros) participate in complex workflows. Smartphones and tablet and ChromeOS have done well because their local apps are, like Franz's tabs, mostly embedded single-app web browsers.
Web apps use a loose ad-hoc standard – web browsers and Javascript – to offer the rich functionality previously dominated by one vendor's proprietary offerings.
But they delivered their rich cross-platform functionality using a kludge: an objectively fairly poor, mostly-interpreted language, in browsers.
Even browser and browser developers haven't even learned the lessons of rich local clients.
Standards too need to evolve and move and keep up with proprietary tech, and they haven't. XMPP and Jabber were pretty good for a while, and originally, FB Messengers and Google Chat were XMPP-based... but they didn't cover some use cases, so they got extended and replaced.
I've read many people saying Slack is just enhanced IRC: multi-participant chat. XMPP doesn't seem to handle multi-participant chat very well. And that's a moving target: Slack adds formatting, emoticons, animated attachments, threading...
The FOSS answer should be to make sure that open standards for this stuff keep up and can be implemented widely, both by web apps and by local clients. Standards-based groupware. There are forgotten standards such as NNTP that are relevant to this.
But standards go both ways. Old-fashioned internet-standard email – plain text, inline quoting, and so on – has compelling advantages that "business-style" email cannot match. Rich clients (local or web-based) need to enforce this stuff and help people learn to use them. Minimal standards that everyone can use are good for accessibility, good for different UI access methods (keyboard+mouse, or keyboard + touchscreen, or tablet + keyboard, or smartphone).
Richer local apps aren't enough. Chandler showed that. Standards so multiple different clients can use it are needed too.
What I am getting at here is that there is important value in defining minimum viable functionality and ensuring that it works in an open, documented way.
The design of Unix largely predates computer graphics and totally predates GUIs. The core model is "everything is a file", that files contain plain text, markup is also plain text, and that you can link tools together by exchanging text:
ls -la | grep ^d | less
This is somewhat obsolete in the modern era of multimedia and streaming, but the idea was sound back then. It's worth remembering that Windows now means Windows NT, and the parents of the core Windows NT OS (not the Win32 GUI part) were the processor-portable OS/2 3 and DEC VMS. VMS had a richer content model than Unix, as it should – its design is nearly a decade younger.
Dave Cutler, lead architect of both VMS and NT, derided the Unix it's-all-just-text model by reciting "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture.
Defined protocols for communication, so that different apps from different teams can communicate – just like an email client receives messages from an email server and so can download your mail, and then this evolved to it being able to ask the server and show you your mail while the messages stay on the server. This is immensely powerful, and now, we are neglecting it.
We can't force companies to open their protocols. We can reverse-engineer them and so write unauthorised clients, like many libpurple plugins for Pidgin, but that's not ideal. What we need to do is look at the important core functionality and make sure that FOSS protocols can do that too. Email clients ask for POP version 3, not just any old POP. IMAP v4 added support for multiple mailboxes (i.e. folders). I propose that it's time for something like IMAP v5, adding server-side filters... and maybe IMAP v6, that grandfathers in some part of LDAP for a server-side contact list too. And maybe IMAP v7, which adds network calendar support.
Got a simple email client that doesn't do calendaring? No problem, stick with IMAP 4. So long as the server and client can negotiate a version both understand, it's all good.
Ditto XMPP: extend that so it supports group chats.
NNTP and RSS have relevance to Web fora and syndication.
Getting together and talking, defining minimum acceptable functionality, and then describing a standard for it. Even if it's an unofficial standard, not ratified by any body, it can still work.
But by the same token, I think it's time to start discussing how we could pare the Web back to something rich and useful but which eliminates Javascript and embedded apps inside web pages. Some consensus for something based on most of HTML5 and CSS, and make it a fun challenge to see how much interactivity programmers can create without Javascript.
What's the minimum useful working environment we could build based on simple open standards that are easily implemented? Not just email + IRC, but email with basic text formatting – the original *bold* _underline_ /italic/ ~strikethrough~ that inspired Markdown, plus shared local and global address books, plus local and global calendars, plus server-side profile storage – so when you enter your credentials, you don't just get your folders, you also get your filters, your local and organisation-wide address books, your local and org-wide calendar, too. If you wish, via separate apps. I don't particularly want them all in one, myself.
Ditto shared drives for safe, encrypted, drive mounts and shares over the internet. I can't use my Google Drive or my MS OneDrive from Linux. Why not? Why isn't there some FOSS alternative mechanism?
Is there any way to get out of the trap of prioprietary apps running on top of open-ish standards (Web 2.0) and help rich local software get more competitive? I am not sure. But right now, we seem to be continuing up a blind alley and everyone's wondering why the going is so slow...
The year of Linux on the desktop came, and the Linux industry didn't notice. It's ChromeOS. Something like 30 million ChromeBooks sold in 2020. No Linux distro ever came close to that many units.
But ChromeOS means webapps for everything.
I propose it's time for a concerted effort at a spec for a set of minimal clean local apps and open protocols to connect them to existing servers. As a constraint, set a low ceiling: e.g. something that can run on some $5 level device, comparable to the raw power of a Raspberry Pi Zero: 1GB RAM and 1GHz of CPU in 1 core. Not enough for web apps, but more than enough for a rich capable email client, for mounting drives, for handling NNTP and internet news.
Something that can be handed out to the couple of billion people living in poverty, with slow and intermittent Internet access at best. This isn't just trying to compete with entrenched businesses: it should be philanthropic, too.