I think the glitch might simply be happening because show() finishes before the new image is fully loaded. 
As a quick experiment, try using show() and hide() without the fade option and see if that helps.
P.S.
Good morning! By the way, am I the one being tested here? 
Honestly, as someone who usually only speaks Japanese, I didn’t quite get what “STRUGGLING SCALA” meant at first—especially since I was still half-asleep! But now I get it, and thanks to that, I had a shockingly energizing start to my morning!
Well then… maybe I’ll just keep struggling with this problem for years? 
Would you two stick with me until then? Wait for me? Aim for God-coder status together with me?
We don’t know how long it’ll take for the Japan national soccer team to win the World Cup, but I do promise that I’ll get this code working by then!
But you know, I think there’s something we can learn from soccer that really applies here—something that’s important for keeping our passion alive while solving problems like this.
In soccer, it’s always the goal or the scorer that gets the spotlight. But in reality, everything that led up to that goal is incredibly important. The person who scores is awesome, no doubt—but don’t forget the players who set it all up.
I think what our Ninja Captain passionately wants to say is something along those lines. And I believe it applies perfectly to coding too.
Are we content with code that just happens to work (a lucky goal)? Or do we strive for reliable, maintainable code—where things work every time based on a well-structured system (a goal that’s the inevitable result of organized play)?
A team that wins the World Cup is almost always the latter.
And as for our current code—well, it’s still in the unstable but kind of working phase. The execution timing, including the animations, is still shaky.
That’s why I think the Captain is emphasizing the importance of defining the user interface properly in order to stabilize the overall behavior.
It’s not just a good habit or best practice in coding—it’s also a key step in helping ourselves understand what approach we’re using to solve the problem.
For simple programs, I personally don’t think this kind of structure is always necessary—but in order to avoid future confusion like what we’re dealing with now, I totally get why the Captain is so passionate about it.
Code generally runs top-to-bottom (though in JavaScript, that comes with caveats). So it’s ideal to have variable declarations and key definitions at the top—just like how a book has a table of contents up front.
This becomes increasingly important the more complex a program gets, or when you’re sharing your code with others.
Also, ideally, code should be broken into single-purpose functions that behave like black boxes—where you don’t need to know how the internals work as long as you provide the correct input and expect a consistent output.
That black-box design is ultimately what contributes to the reproducibility and stability the Ninja Captain is talking about.
While this particular program might not grow into a massive complex one, and yes, it’s technically possible to cram everything into a single onReady callback, it’s still not the best approach.
Even if we can get away with it here, but it’s important to understand that following the proper approach is generally recommended.
The right attitude toward programming is probably something like this.
and still no clue
