4 ms·

You can massively accelerate the speed (real, not perceived) of page loads by fetching content asynchronously. There's no way for the browser to know that any g

You can massively accelerate the speed (real, not perceived) of page loads by fetching content asynchronously. There's no way for the browser to know that any given fetch is performing the equivalent of a navigation operation, and there's no API for user scripts to tell browsers that a navigation-via-fetch is happening. Asynch page fetching is faster, but not instant. If you have a reliable way to improve your app's responsiveness but can't drive a native progress bar, what offers a better UX? A subtle, tasteful custom progress effect or nothing? Or do you declare the entire approach invalid on a technicality? That seems reductive and petulant, like giving up your favorite wine because the winery switched to screw caps for sustainability reasons.

sirwhinesalot 5y ago
Ask yourself why you believe loading a megabyte of data at best requires asynchronous content fetching. Web pages with a "loading/splash" screen are a telltale sign that I'm about to have a miserable experience, kinda like UWP apps on Windows. Even better when the javascript crashes and instead of getting the content, perhaps badly rendered, I get nothing and need to reload and pray again. Not saying these apply to Shoelace, but it's also the sort of page that really doesn't need a spinner on first load. Let the browser load things, it already knows how to do that pretty well. 3G connections you say? Send me the unstyled HTML first so I can at least get to the content instead of making some bullshit spinner that will probably crash anyway. I hate the modern web.
- peteforde 5y ago
  It's only an argument if you don't acknowledge that 1) you have no idea what kind of apps I build and 2) it's fair to say that we're building different kinds of things. The behaviour you are describing would indeed be frustrating. It describes (well) many of the sites built with SPAs, IMO. Thankfully, that's not at all what I'm talking about. My stack - server rendered content, Turbo Drive for asynch page loads, Stimulus for light client interactivity that doesn't involve permanent state - is amongst the most battle-hardened. In real terms, hard page refreshes take hundreds of ms on top of whatever data is sent. Turbo Drive can replace content in whatever real-time is, which is especially noticable on mobile devices. A properly constructed Turbo Drive powered app can therefore feel native to most users, but with server-rendered content. If you haven't tried it, you might be shocked when you do. As an addendum: Shoelace is not my site, and I share your distaste of "Loading" prerolls. That said, a quick blue line across the top of the content area that you only see for the same amount of time you'd be waiting for content to load anyhow seems distinctly fine - and that is, not coincidentally, exactly what Turbo Drive does out of the box.

sirwhinesalot 5y ago

Ask yourself why you believe loading a megabyte of data at best requires asynchronous content fetching. Web pages with a "loading/splash" screen are a telltale sign that I'm about to have a miserable experience, kinda like UWP apps on Windows. Even better when the javascript crashes and instead of getting the content, perhaps badly rendered, I get nothing and need to reload and pray again. Not saying these apply to Shoelace, but it's also the sort of page that really doesn't need a spinner on first load. Let the browser load things, it already knows how to do that pretty well. 3G connections you say? Send me the unstyled HTML first so I can at least get to the content instead of making some bullshit spinner that will probably crash anyway. I hate the modern web.

peteforde 5y ago
It's only an argument if you don't acknowledge that 1) you have no idea what kind of apps I build and 2) it's fair to say that we're building different kinds of things. The behaviour you are describing would indeed be frustrating. It describes (well) many of the sites built with SPAs, IMO. Thankfully, that's not at all what I'm talking about. My stack - server rendered content, Turbo Drive for asynch page loads, Stimulus for light client interactivity that doesn't involve permanent state - is amongst the most battle-hardened. In real terms, hard page refreshes take hundreds of ms on top of whatever data is sent. Turbo Drive can replace content in whatever real-time is, which is especially noticable on mobile devices. A properly constructed Turbo Drive powered app can therefore feel native to most users, but with server-rendered content. If you haven't tried it, you might be shocked when you do. As an addendum: Shoelace is not my site, and I share your distaste of "Loading" prerolls. That said, a quick blue line across the top of the content area that you only see for the same amount of time you'd be waiting for content to load anyhow seems distinctly fine - and that is, not coincidentally, exactly what Turbo Drive does out of the box.