27 ms·

I always applaud this behavior when I see it, and it was one of my favorite features of turbolinks when it was still in vogue. Some people are on satellite inte

I always applaud this behavior when I see it, and it was one of my favorite features of turbolinks when it was still in vogue. Some people are on satellite internet. Some people are still on dialup. Some people are on a tiny sliver of a 3G connection that is dropping in and out as they go in and out of train tunnels. Sometimes gasp the cloud itself gets slow. In all of these situations a progress bar for practically any network action is greatly appreciated. If you are on a fast connection with a fast CPU, you likely won't even see the loading bar. If you need it, you'll probably see it. What is there to complain about? Who wants a blank screen with no information where you end up looking at dev tools to determine whether something is actually loading?

jeroenhd 5y ago
Yes, a progress bar is nice, that's why every browser has a progress bar built in. Both determinate and indeterminate progress bars appear automatically whenever you click a link. If your browser's progress bar is incorrect somehow, your browser is broken and websites shouldn't have to correct for that.
- peteforde 5y ago
  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.
- jimmont 5y ago
  This is simply a reflection of the depth of design (visual and user experience). I'm saying contemporary UX and UI mostly ignore, or are ignorant of, the platform being used and its features. That's not necessarily the case with shoelace, the loading is simply a design decision made to look nice and I presume not much more. The shoelace component system is ok. It reflects a lot of work applicable to what has been possible and borrows from what has been possible the past few years. I find it interesting to see the details in systems and approach and would avoid using this product myself. I haven't reviewed it enough to get past the general impression that it's too complex to be worth the investment and has some weaknesses in the system and technical design. If I were doing a masters in visual communications it would definitely be worth a look, or if I wanted to lead a new project like it as well--to take the understanding of the problems and approaches.
- sam0x17 5y ago
  Browser progress bars don't tell you "what" is loading. Many sites will say "waiting.." continuously because some ad server or request that has nothing to do with the current content is taking forever. A single-channel, catch-all "waiting" indicator isn't enough. Every major browser is broken in this respect. The "waiting" indicator is also typically only noticed by power users who have hundreds of thousands of hours of experience loading pages and some technical insight. This feature isn't accessible, it's a farce.

jeroenhd 5y ago

Yes, a progress bar is nice, that's why every browser has a progress bar built in. Both determinate and indeterminate progress bars appear automatically whenever you click a link. If your browser's progress bar is incorrect somehow, your browser is broken and websites shouldn't have to correct for that.

peteforde 5y ago
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.
jimmont 5y ago
This is simply a reflection of the depth of design (visual and user experience). I'm saying contemporary UX and UI mostly ignore, or are ignorant of, the platform being used and its features. That's not necessarily the case with shoelace, the loading is simply a design decision made to look nice and I presume not much more. The shoelace component system is ok. It reflects a lot of work applicable to what has been possible and borrows from what has been possible the past few years. I find it interesting to see the details in systems and approach and would avoid using this product myself. I haven't reviewed it enough to get past the general impression that it's too complex to be worth the investment and has some weaknesses in the system and technical design. If I were doing a masters in visual communications it would definitely be worth a look, or if I wanted to lead a new project like it as well--to take the understanding of the problems and approaches.
sam0x17 5y ago
Browser progress bars don't tell you "what" is loading. Many sites will say "waiting.." continuously because some ad server or request that has nothing to do with the current content is taking forever. A single-channel, catch-all "waiting" indicator isn't enough. Every major browser is broken in this respect. The "waiting" indicator is also typically only noticed by power users who have hundreds of thousands of hours of experience loading pages and some technical insight. This feature isn't accessible, it's a farce.