Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't advertise .show() on the front page #88
Yes, for example. It's obviously harder to present in a small example but currently we're contradicting ourselves by saing
That's a separate issue, let's not conflate them.
Yet, I think what we're mostly referring to here is the cost of retrieving actual display values when the element is hidden – in a couple cases it is very costly – and then the problems caused when we cache those values, such as breaking responsive layouts. We are still discussing the implications of that and what we might do about it. I'd recommend we wait until we reach a resolution on that issue before we make changes to the homepage.
Let's do that.
I've recently profiled the load of wikipedia's new visual editor https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit
The heaviest self-time stack of JS during the editor load is from curCSS. It's the biggest bottleneck in loading the editor. And most of its work is coming from hide/show.
Was wikimedia surprised when they learned that their largest bottleneck is from calling jQuery(elem).hide()? Very.
Here's a single instance from this app:
And let's look at how it ended up getting used:
The logic inside
Aside: Now that I'm looking, this magic behavior doesn't make much sense. There seem to be two edge cases that have caused jQuery to punish every app's performance:
Is baking in support for these two edge cases into one of jQuery's most simple looking APIs worth being the largest bottleneck in this editor?
Scott, Tim.. I ask you to load up https://en.wikipedia.org/wiki/Barack_Obama?veaction=edit and profile it with the browser and tools of your choice. The engineers behind this app used jQuery in a perfectly rational way, but it's fighting against them.
I'd say @paulirish summed it up well with the question:
It's not even just the bottleneck, I don't think we can reasonably expect any solution other than
I meant if this code gonna change it should follow new code style, but that would mean we would need to update everything, otherwise code examples would be inconsistent. Or we could follow old code style and update everything later.
@paulirish, @scottgonzalez, @timmywil at the meeting, couple months back, we discussed the possibility of significant logic simplification of those methods - throwing away any lookups whatsoever and just doing
I think we need to be more careful with "not recommend" decisions. If there is one bad example out there it shouldn't outweigh all other use-cases.
I remember @Krinkle was working on new editor, maybe he has a bit more info about it.
Piggybacking off of what @markelog said, my concern is that
@paulirish You're the man. Thank you for that write-up!
What's interesting to me is that it doesn't seem to be taking up time in
Further aside: This, or some related behavior, has caused me headache in at least one other situation when working on VisualEditor:
I don't understand why this would be necessary -- the element's just been created, no style is (presumably) changing its display to anything other than the default... -- and when highlighting all text in a 5000×3 table, $.show() accounts for 10s out of the 14s it takes to draw the highlights. $.show() being absurdly slow is a known problem: jquery/jquery.com#88