Whenever you can run the same software on a variety of hardware with different specs and capabilities, it's always up to the consumer to spend more money to make that software run faster.

Having said that, I agree with the idea of making software less monolithic and making it start up as fast as possible, as long as it is possible. However, when I say that I want a program to start up fast, I mean that I want it to start being useful fast. Quite a few of author's ideas are not about bootstrapping gradually, they're about faking it. It's like going to a place that used to have a "closed for lunch" sign and discovering that it's now open, but populated by robots whose personality is an Eliza-like AI.

I might have misstated. I mean that consumers shouldn't have to compensate for poorly written (in terms of efficiency and speed) software. Sure buying an SSD would increase the write speed, which is usually the bottleneck for a system, but the consumer can save a couple hundred bucks if the developing company focused on speed instead of bloat.

And I agreed about the "faking" issue. Just like how Windows will silently keep loading tons of services in the background after a reboot, but shows you a desktop and makes you think you are free to click and launch stuff.

It's probably the random read speed that matters for starting apps.

> However, when I say that I want a program to start up fast, I mean that I want it to start being useful fast. Quite a few of author's ideas are not about bootstrapping gradually, they're about faking it.

But quite a few of those ideas are useful.

The only ones I thought were a bit out-there were the ones about "just processing it in the cloud" while the local copy is still loading. But other HNers are probably more qualified to judge how realistic this is.

What is a possibility, however, during loading a lot of time is spent on loading all sorts of modules, ones that might not even be used that session, and most definitely not in the first few minutes. Because what is the user going to do first? Most likely it'll be `File > Open ...` and browsing through the filesystem looking for whatever project they intend to open.

You don't need any plugins for that. And it's exactly the type of task that spends relatively a lot of time waiting for user input and not so much time computing or loading things. During this task the app can continue loading modules and plugins and the user doesn't have to wait because they're selecting a file.

You probably need to disable (most of) the instant preview in the file open dialog until it's done loading, but that's a minor trade-off.

Of course you're loading the modules necessary for opening files first (most recently used filetypes first). When that's done the dialog can start showing previews. If the user happens to have found and selected their file before it's done, then, only then they'll have to wait.

Now you're loading the file and it's showing on the screen, the user can browse the layers a bit and ponder where exactly they left off last time. A wonderful time to load the rest of the modules! Of course the features used in this project will be loaded first. If there's no text layers, we can put off loading font-rendering support in favour of other modules.

It's not all load-on-demand, but a lot of user tasks are not as processor- or data-intensive as you'd think, because the user is busy thinking and as long as the UI is responsive enough they're happy.