New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't advertise .show() on the front page #88
Comments
And switch to We should update |
And yeah, since jquery/contribute.jquery.org#104 is a done deal, we would need to update all code examples so they would adhere to code style changes? /cc @arthurvr |
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. |
I disagree that |
@scottgonzalez Agreed. There seems to be a misconception growing in the community that all JavaScript animations are bad. That isn't true. It's that applications should use tools to analyze performance and discover real bottlenecks. CSS animations can be very slow too. 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 With 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. |
Let's assume 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: |
@MatmaRex: Your second headache appears to be jquery/jquery#1767, which we hope to resolve in 3.0 by ignoring cascaded |
We discussed this on the last meeting, it was decided that we would like to improve those methods instead - jquery/jquery#2057 |
(Edit: moved to jquery/jquery#2057 (comment)) |
You can use safely $().hide(), if you've load jquery.gsap.js :) |
It's a performance anti-pattern; see <jquery/jquery.com#88 (comment)> Change-Id: If6e521c27975f7d64932268fde5778aa63fd08ee
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
The
.show()
&.hide()
methods are costly and they don't play well with responsive design. We shouldn't advertise them right on the front page.The text was updated successfully, but these errors were encountered: