> That demo literally shows a brief "Loading..." screen for the first open issue, which was pretty much my point.

Yes when you open a desktop app that has to load the data from the internet it has to load first... You can't get around that fact unless you have zero data remote? Which defeats the purpose of a collaborative B2B app.

After that first load, strictly the first time you open the app, you never see another loading screen.

Saying desktop apps don't do the same thing is disingenuous.

And as I mentioned, that's a simple demo for a new framework in beta hosted on a free Heroku instance. Linear's production app is even faster. Especially when you download the desktop version.

> Yes when you open a desktop app that has to load the data from the internet it has to load first... You can't get around that fact unless you have zero data remote? Which defeats the purpose of a collaborative B2B app.

This could be true for data being loaded from the Internet, yes, though it assumes the premise that JS based applications will still do this faster. However, collaborative B2B apps existed before the JS craze and worked perfectly well (and faster) without it. They also don't strictly need to be querying data from the broader 'net but can be doing things like talking to a local database server, asynchronously retrieved local cache, etc.

> After that first load, strictly the first time you open the app, you never see another loading screen.

That's actually only half true. The "Loading" screen does indeed not popup. Instead, you just get broken empty UI until it eventually loads the record. What I observed was scrolling to the end and selecting any of the final few records there was a substantial and noticeable second-plus delay loading the record data into the view. Steps are: Load page -> scroll to very end using scrollbar -> pick last record.

For fun, I profiled it. According to the profiler it takes 3.8s for it to successfully load and process the record, of which 2.1s is just in one promise.

It's also a demo site and could easily cheat this (but to their credit appears as though they are not quite doing so at the expense of heavier page loads). It's not a compelling example of what you're talking about.

It seems like you’re missing the point of the demo. It is purposely not trying to hide the initial load. There’s more (a lot more) to application performance than page load speed. This obsession with page load speed is weird. How many times a day do you open Excel? How many time a day do you click on things in it?

> I've not seen loading screens since about 2000 on any native apps.

Have you used any real apps, because Macromedia Dreamweaver/Adobe Photoshop/etc had literal minute long splash loading screens where they zoomed text on a small snippet telling you what it was doing since at LEAST 2000....

My comment was clearly in the context of loading an individual database record within the application once running. Sure, splash screens exist. Are those part of using the application?

Arguably, I guess though if that was really the comparison to draw, should we then compare it to closing down a browser entirely and booting up the demo via shellopen or equivalent for the URL in question?