Why is the tutorial section so embarassing?

As a fellow aureloid, I’m totally into this awesome framework. But when I tried to go to the todo app tutorial, it scrolls unbearably choppy. Ah just a scroll issue no big deal right? wrong. There’s no excuse for having trouble loading a freakin todo app or several of them. Don’t make excuses; Just fix it or pack this shit up and thank everyone for their hard work cause you’ll have ZERO new users after witnessing that for 2 seconds. I’m evaluating frameworks right now and guess which one just dropped out of the mix? It could just be me, my browser right? I do have a shit ton of tabs open… but uh yeah only your website/framework is struggling with it. My future projects need to support ppl with shit tons of tabs open.

You are right. The behavior you describe can hurt.
Can you help me reproduce the issue?
I have shitloads of tabs open.
Runing on dev branch of chrome (not stable, not even beta)
Never had an issue like that.

Alex, I also experienced what @notme described, but not as that bad.

All guides pages do have choppy scrolling in Safari (I guess @notme is a Mac user too). Better in Chrome, and super smooth in Firefox.

It feels like due to some css complication…

Thanks for reporting. Those are important insights as not everybody has the same workflow/style.

I’d just like to ask for one thing. I know it can be frustrating not seeing things to work as expected. Its not a discussion whether its easy, obvious or whatsoever but the style of how you’ve written your post makes me personally feel hurt. I know this is OSS and people think that its an invisible/unknown group of people that code but please mind your tone as we are all here and reading stuff. We’ll do our best and i’d wish we can keep cool heads as that is the most successful way of getting things done.


All critics is good and welcome no matter if targeting code or docs. None of us is thinking that our stuff is pure gold :wink: its just about the tone Im talking here.

If I were to take a wild guess, I’d say this is because we all pretty much develop and test in Chrome/FF for the most part. Something seems to work fine in Chrome/FF, maybe double check IE if you’re feeling like it -> ok deploy.

It’s good to know that it doesn’t do so well in all browsers, also to make a point of perhaps testing a bit more rigorously across different browsers.

I could probably help out with optimizing some of the CSS if that’s indeed the issue. @notme can you elaborate on which browser/version you were using and which specific pages you’ve noticed the problem on?

Not sure if it’s related but I opened safari and clicked around fast in the tutorial section and eventually got loads of these errors in the console. I tried to get the same error in Chrome but it didn’t happen. It didn’t cause it to slow down but I only had one tab open.

SecurityError (DOM Exception 18): Attempt to use history.replaceState() more than 100 times per 30.000000 seconds

Nice catch…
Safari delivers as usual (-:
How fast you’d been scrolling?

As fast as I could really…

@mttmccb great catch.

Now I understand what’s going on. There is an unrelated Safari bug caused back/forward button doesn’t support in aurelia app. From that issue, I learnt that Safari has security check on history.replaceState because malicious js can use it to hide what it did by faking url.

Did you notice there is a scrollspy on the page to sync document scrolling with left side navigation menu? I bet it calls replaceState on “scroll” event which fires very fast. So Safari runs some security checking routine on every bit of scrolling…

@Alexander-Taran stop make fun of Safari :wink: It’s trying to do something safe, which other browsers don’t bother.

After all, it’s not css, but js to be optimised to avoid unnecessary replaceState calls with same url.

Sorry to disrupt the safari circle jerk, but I use chrome like everyone else. And yeah it still sucks after I restarted everything to install OSX updates. it’s choppy dudes c’mon; i can’t be the only one to notice this… unless you guys use aurelia so much this is pretty much normal to you. Go do a google search, scroll around to get a feel for what’s normal, then come back here.

@notme That has absolutely nothing to do with Aurelia though. It’s that materialize theme and it’s “paper” effects (box shadow). Shadows are always notoriously GPU intensive. The todo guide is simply a particularly long page which has lots of them.

Open up your dev tools and add this to the styles:
* {
box-shadow: none !important;

Does that make a difference?

@zewa666 maybe keep the page a bit more “flat” when it gets long?

Referring back to a fun little post I saw not too long ago, here’s how Aurelia plays out when it’s just Aurelia (and not silly CSS):
React stack: https://claudiopro.github.io/react-fiber-vs-stack-demo/stack.html
React fiber: https://claudiopro.github.io/react-fiber-vs-stack-demo/fiber.html
Aurelia: http://aurelia-thousand-nodes.bigopon.surge.sh/

@notme, really don’t understand why you are so angry about something is not perfect.

Most people in discourse here are only community members like you and me, seeking help and offering help. If the aurelia guides site is open source (it’s not), there will be few guys here already debugging on the source.

Everyday, there are numerous github issues created in OSS world, aurelia is part of that, most of the issues are more annoying than this one. Hardly seeing any users getting angry. But very common to see people outside of core team to help fixing issues.

I can accept Linus Torvalds giving rant on Intel CPU bugs, because he is the only few can write nearly perfect code. Rest of us (including aurelia core team) are mere mortals just like you and me.


Adding to my previous comment, this seems to improve scroll performance even more:

* {
backface-visibility: hidden;

I’m actually a little surprised by how big a difference that makes. I normally only do that for images…

Maybe you can keep the box shadows after all

Never had the issue but I don’t keep that many tabs open or read the tutorials that often. Sounds like there are solutions to the problem now.

Eventually the scrollspy stopped working so I reloaded the page, probably an edge case and it seems like it’s an unrelated bug.

Update two findings.

  1. I am running Safari Technology Preview as my day to day main browser. I just went to test stable Safari, the Safari TP scrolling is much faster than stable Safari, but still slower than Chrome/Firefox.
  • given that Chrome/Safari shared big trunk of code (Chrome forked webkit into blink), it is reasonable to guess that Chrome also suffers the issue but not as bad. Chrome is obviously slower in scrolling comparing to Firefox on my Mac.
  1. @fkleuver, both box-shadow and backface-visibility doesn’t speed up my Safari (both version). And hard to tell difference in Chrome on my Mac.
  • it feels like only happen on Mac Safari/Chrome. Most of you guys are running Chrome on PC, including most of core team I think. It seems this is not a problem on PC based on @Alexander-Taran’s similar usage pattern.

I’m on PC and definitely having choppy scrolling, but exclusively on chrome. Both Edge and FireFox are very smooth with or without the CSS rule. When I’m scrolling as fast as I can on the TODO tutorial page in Chrome, I get these fps results:

  • As-is: 5-7 FPS
  • With backface-visibility: hidden: 13-16 FPS

It seems the culprit is the body>main element. It has position:absolute; an absolutely positioned element needs its position recalculated and will trigger a repaint on each scroll event.

The backface-visibility: hidden (just like transform: translateZ(0) and transform:translate3d(0,0,0)) passes that work on to the GPU which usually speeds it up.

1 Like

Why can’t everybody use nice powerful machines like we use for development? :grin:

I just spent a couple of days debugging an IndexedDb issue which only seems to happen on old “spinny” hard drives. I know, who would use one of those awful things?

The moral of the story is that crappy old laptop you wouldn’t develop on if your life depended on it makes a great test machine!


We ran into something similar with drop-shadows, they looked horrific on old monitors, great on retina screens :stuck_out_tongue: