Libreoffice is monolithically designed, as shouldn't be representative of the generic performance of modern software.

The reason is that StarOffice was envisioned as desktop environment, therefore, all the components of the suite are loaded on the first startup.

  $ libreoffice --writer &
  $ time libreoffice --calc --terminate_after_init
  
  real	0m0.104s
  user	0m0.016s
  sys	0m0.008s

I think the article is very misguided; the problem is in the expectation that anything should be faster, even in contexts that are implicitly slower (networks, i.e. internet), or with features that will inevitably slow down the experience (e.g. browser plugins).

Using as reference the slowest software - Libreoffice, Atom, Firefox - is nothing else than cherry-picking.

In this perspective, a sibling article is correct - if you want faster alternatives, you have them.

EDIT: not startup time, who cares about startup time? When you load a few hundred pages doc, or a massive excel.

re 2: I only wanted to give examples, but you're right, my wording is off.

I wanted to say there are fast and good interfaces: there's vim for the terminal, there's Rainloop for webmail, miniflux for RSS reading - these are all keyboard-oriented ones, all working decently and as fast as they can. In case of web-connected ones, the speed of going back and forth is certainly an issue.

Local - as in not making connections on the network - in my opinion, will always have a speed advantage though.

Slow compared to decent standards of what a word processor needs. For reference, WordPad perceptually opens instantly for me, and has felt like it opened instantly since Windows 95, I'm pretty sure. I am saying that both LibreOffice and Google Docs are examples of software that take way too long to do simple things because they're busy doing complicated things that I don't actually care for. (And arguably this isn't really their fault per se, they're both designed to compete with / follow the expectations set by Microsoft Office of what an office suite is, and those expectations are that all the complicated things are available).

> Local - as in not making connections on the network - in my opinion, will always have a speed advantage though.

Depends what you're doing with the network. I do just about all of my work in the terminal with a mosh connection to a cheap server a couple hundred miles away, and I never feel perceptual slowness from my machine not being local, unless I am literally in the subway or in an elevator. And I actually gain a lot of perceptual speed because I can close my laptop and switch to my phone instantly and see the exact screen where I was.

If you're streaming binaries from the network or trying to pump animations on a 2048-by-1536 true-color retina display, yes, remote is going to be slow. Half the tweetstorm's point is that you shouldn't be designing software to need that in the first place.

And you can use pandoc to get the best of both worlds.

LibreOffice on even midsized spreadsheets is quite slow. Slower than opening it Google Docs in fact, which borders on shameful.

It was an example - the slowness (to me) is present for the entire interface. It was just easy to demonstrate. (Also in both LO and Google Docs I can type plain text into an existing document just fine.... I'm curious what you find slower in Google Docs than LO.)

My point is that this rant is not, as far as I can tell, a "local software good, cloud software bad" rant. There are reasons to believe that, e.g. debuggability and computing freedom, but UI speed is not one of them.

I can't speak for the poster above yours, but I would be serious. In my experience, on the startup time, google docs way out performs open office. It's open in single digit seconds, open office is 10s+

I still prefer offline software, but the bloat can be awful. At least web tech is designed with web browsing latency expectation. I find most desktop software these days has a much larger start and use latency by far.