Yep. The most successful startup I worked at had a SPA that downloaded 5MB bundle and preloaded a bunch of data. Took nearly 10 seconds to startup.
Nobody complained about that. In fact, few people complained about a few portions of the app that had abysmal performance. It often wasn’t until 60 second load times that customers started complaining.
They still raved and raved about that software because it solved an extremely valuable problem for them. A job that took literally a week could now be done in minutes.
As the space heated up, we needed to improve some things, but most people literally did not care. It would always be stack ranked last in the list.
Startup time of an SPA is meaningless when it's for the sort of app you open once in the morning and then use during the rest of the day. It's a single startup-hit, and the user suffers it in between closing the tabs from the previous day and fiddling with some emails. Doesn't matter it is 10-20 seconds.
The problem with the long startup is that it tends to cloud any discussion on performance. Code loading and parsing is basically the biggest bar in the app-perf breakdown of your profiles, and thus spins this narrative that this is the thing to optimize for, because it's the biggest bang. Rather than say, responding to user selections, reducing jitter and sluggishness while scrolling, etc...
I'm starting to believe that for a large class of apps, developers should look at it as if they are writing video games: the user will tolerate the spinner before the level, but then it needs to be silky smooth after. And the _smooth after_ requires a whole class of other optimizations; it's striving for a flat memory profile, it's small ad-hoc data transfer, it's formatting data into usable layout at lower levels in the stack, it's lazy loading of content in the background, etc... Those are the areas where web-devs should be looking a
(again, this only applies for that sort of SPA; e.g read-only content, blogs and such, should display _fast_).
Most of my current applications have been opened since the computer booted (11 days ago). Where I'm drawing the line is wasting resources and time while I'm using them. As you said, mostly about user interactions and scrolling because UI is bound to IO for some reason. I remember all the big software taking time to startup (Adobe's, Autodesk's, even Microsoft Office's), but once they do, it was pretty smooth unless you launch that computer/gpu intensive operation. But now, things like Slack causes the computer fan to scream.
"They still raved and raved about that software because it solved an extremely valuable problem for them. A job that took literally a week could now be done in minutes."
This is a big point isn't it.
We seem to think that customers are choosing "slow" over "fast", when a lot of times they are really choosing between "slow" vs "manual" (i.e. very very slow)
You’d always take a bike instead of walking if you can’t get a car. No one is looking to waste time when they need to get something done. If a tool is the only thing in town, they’ll praise it. Until your competitor came with something better in the way that matter.
I do not doubt that if customers had a choice between "slow" and "fast", all things being equal customers will pick "fast". Customers aren't stupid.
But in a surprising number of cases, either customers don't have that choice (because the market hasn't provided a "fast" solution yet), or all things are not equal (say, the fast solution is fast because it's missing features that are crucial).
And this is why it always looks like customers are content with poorly-performing solutions.
Nobody complained about that. In fact, few people complained about a few portions of the app that had abysmal performance. It often wasn’t until 60 second load times that customers started complaining.
They still raved and raved about that software because it solved an extremely valuable problem for them. A job that took literally a week could now be done in minutes.
As the space heated up, we needed to improve some things, but most people literally did not care. It would always be stack ranked last in the list.