Looks great David! One suggestion - would it be possible to keep the bar going (maybe at a slower pace) instead of having it pause around the middle even though it is waiting for a response? It could maybe go slower from 40% to 70% and maybe then pause if no response?
Hiding that short pause would make it feel more responsive and instant in my opinion 
Currently, it seems to go slower for 5s before stopping at 80% width.
Here I simulated a very, very slow Internet connection:
Current SCSS:
.loading-indicator-container {
--loading-duration: 5s;
--loading-function: cubic-bezier(0, 0, 0, 1);
--done-duration: 0.4s;
--done-function: ease;
--fade-out-duration: 0.4s;
position: fixed;
top: 0;
left: 0;
z-index: 1001;
height: 3px;
width: 100%;
opacity: 0;
transition: opacity var(--fade-out-duration) ease var(--done-duration);
background-color: var(--primary-low);
}
.loading-indicator-container .loading-indicator {
height: 100%;
width: 100%;
width: 0%;
background-color: var(--tertiary);
}
.loading-indicator-container.loading {
opacity: 1;
transition: opacity 0s;
}
.loading-indicator-container.loading .loading-indicator {
transition: width var(--loading-duration) var(--loading-function);
width: 80%;
}
.loading-indicator-container.done .loading-indicator {
transition: width var(--done-duration) var(--done-function);
width: 100%;
}
body.discourse-hub-webview .loading-indicator-container {
top: 1px;
}
body.footer-nav-ipad .loading-indicator-container {
top: 49px;
}
body.loading #main-outlet {
opacity: 0.2;
transition: opacity 0.2s ease;
}
Hmm it stops at about 40% for me, but a moving bar - even if slower - would be better than a pause I think.
Also, in relation to the fade - maybe fading content out and new content in would make it appear faster (if its possible to target the outlet for the loading route)?
There are two things happening…
@Canapin is right that the initial animation ends 5s in at 80%… so on a slow connection it’ll get stuck there and won’t complete until you’re on the next page
@P16’s case is what I experience on a faster connection… once the transition away from the current page happens, the animation is briefly halted wherever it happened to be… and it picks up a second later on the new page (exaggerated the bar height here so it’s visible)
I agree that keeping some motion ongoing is ideal, but it might not be possible without changing the way it’s implemented entirely…
I don’t think the fade in will help much… you can’t fade in the content until you have it, so you’re slightly delaying its appearance that way. I guess it’s possible it might create an illusion of speed, but it will technically be slower by however long the fade-in animation is!
I just realized you can test the fade in (kinda) with the table of contents component (because it fades in the post), for example… visit: PostgreSQL 13 update. I don’t think it feels particularly faster… but it is definitely “softer”
Oooh, I think that’s happening because the content did load, and there’s a large hitch of HTML Parse / Style Cascading / Layout / Render, during which the animation can’t move.
.loading-indicator-container .loading-indicator, .loading-indicator-container {
background-color:#FFCC00;
}
I tried to change the color in the CSS of the theme but it stays blue. Any help?
Yeah exactly. The single-threaded nature of the JS / DOM rendering means that we drop loads of frames while rendering a topic 
. The slider is ‘moving’ the whole time, it’s just that the frames never get rendered.
Thanks. I just tidied that up in core, so it will be fixed here on Meta very soon.
I’ll get a fade-in going on Meta today so we can see how it feels. Although obviously if we do that, we’ll want to remove other fade-ins like the TOC component.
Edit: that’s done. Fade-in enabled on meta
Depending on the order that your themes/components get loaded, that might not work. You need to make the selector ‘more specific’ than the loading slider component CSS. The simplest thing is probably to add !important to the background-color. You’ll also want to remove the container selector, otherwise the background will be the same as the foreground:
.loading-indicator-container .loading-indicator {
background-color:#FFCC00 !important;
}
Thanks David looks great!
It now takes an average of the last 5 page loads, and uses that to set the speed of the bar
Hi David,
This loader getting better and better 
Keep the great work.
With this new update it looks more dynamic
I just notice one thing about this in category. I use the create topic button rename. 
With Loading Slider it doesn’t refresh the button text. I just notice this because it might cause problem with other scripts.
Demo (on this video i click a category which has other create topic text and go to other category which has the default create topic button.) After i refresh the whole page it show the correct text.
The fading in/out is an improvement. But I still find the slider a distraction. I find myself looking at it, meaning I’m slower to be ready to read the page when it loads. With the spinner, it was in one place so was easy not to look at, and the suddenness makes me think of speed (maybe wrongly).
It may be that on slow connections the slider is better as you get a feel for how slow/fast the page is loading. I don’t know about that.
For me when using a mobile phone the slider is located at the top of the screen while the old one is located more in the middle of the screen aprox 30% from the top…
Instead of keeping your eyes focused on the center off your phone they make movement up and down, up and down… just my 2 cents…
I’m agree with this. I think that would be the best if Loading Slider works on desktop only and on mobile maybe keep the spinner. The spinner is more feels like using an app which is good on mobile. Just like YouTube use the loaders.
Yes, I’ve been using it on an iPhone so my comments really related to mobile.
Love the concept. I’m a big fan of sliders v. spinners.
Enabled and tried on many themes (Dark, Alien, Vincent, Star Wars, etc) on both 27" and 34" ROG monitors. Could barely see the loading slider. Seems very thin. On “dark” themes the thin line seemed too soft of a color to really notice.
Also tried the slider on mobile, iPhone 6s and iPhone 6+. Similar comments. Barely noticeable.
Trying not to be a social party-pooper, but objectively speaking, the slider seems promising but needs additional CSS work (IMO), and so we went back to the spinner on our site for now, since it is noticeable and tells the “reloading story clearly”. When I have time, I will enable again and work on the CSS for our site; since this looks really promising!
Looks very promising!
Thanks and keep up the good work!
PS: No speed issues. I’m on (just off) our national fiber backbone, on a dedicated fiber to the main backbone.
I just want to mention that I don’t really care for the new UX behavior when selecting categories, topics, etc., where the current view becomes faded before the new page loads. I think the old approach of just having a blank page with a spinner was a much nicer experience.
In either case the page changes twice. But because spinners are universal things, it didn’t really feel like the page changed twice. It felt like it was preparing to change, and then changed once. Now it feels like it’s changing twice, because there is still content after both transitions, once faded and once for the new page content. It’s hard to pin down exactly why I don’t like it, but I think it’s because there’s no longer a universal loading view. Now there are effectively an infinite number of different loading views, and I find the fade-then-load loading view to be distracting since the background content is different every time I transition to a new page.
Some things that use didInsertElement hooks will need updating, yeah. With the old spinner, all elements on the page would be destroyed and recreated. With this new system, Ember will reuse elements if possible. Which might actually make rendering a little faster, but could create some bugs if customisations are not following normal ember patterns. We’ll have to work through and clean those up as we notice them.
Do you have the code for your customizations in a git repo you could share?
That’s the main reason I want to experiment with this as a theme component for a little while longer - we’ll be able to catch as many issues as possible before moving it into core.
I think there’s a mobile bug (at least on iPhone) with this new feature. If you select “Latest” from the navigation dropdown, when the page loads the dropdown properly goes away. But if you select “New” or “Unread” (possibly others), the dropdown is still visible. It doesn’t happen 100% of the time, but often enough that it should be easily reproducible. Note that this did happen sometimes with the old version, but only with “Latest” and never with “New” or “Unread”.
Thanks @Don - I had a play with this and I think this is a better way of doing it, which should work with the new slider: https://github.com/VaperinaDEV/category-btn-name/pull/1 (sorry if I messed up any of the Hungarian). That kind of pattern should be useful if others need to update their components as well (using computed properties rather than didInsertElement and JQuery).
added to my list to investigate, thanks