Hear me talk about jQuery on the Polymorphic Podcast
ASP.NET, JavaScript, jQuery By Dave Ward on June 20th, 2009As a longtime listener myself, I was eager when Craig asked me to come on the Polymorphic Podcast to talk about jQuery. I’ve always enjoyed how he doesn’t shy away from talking about HTML and JavaScript, which is still too uncommon in the .NET world.
With that in mind, I knew we’d be able to have a great conversation about jQuery and the concerns that ASP.NET developers run into when using it. I really enjoyed recording the show, and think it turned out pretty well. I hope you’ll enjoy it too:
Polymorphic Podcast: jQuery Secrets with Dave Ward
If you haven’t yet, I highly recommend subscribing to Craig’s podcast. There are some real gems in his previous shows too, so check those out as well.
Possibly related posts
Share this post
What do you think? Your comments are welcome.
I appreciate all of your comments, questions, and other feedback, but please try to stay on topic. If you have a question unrelated to this post, I recommend posting on the ASP.NET forums or Stack Overflow instead.
If you're replying to an existing comment, please use the threading feature. To do this, click the "Reply to this comment" link underneath the comment you're replying to.
Dave – you mentioned in the podcast that using dummy classes (e.g. “.flipped”) was a good way to select items on a page as it had no performance penalty in the browser.
I am wondering if that’s true – you yourself mentioned that in most browsers selecting by class is a loop. Doesn’t that mean there is a penalty and that it’s directly related to the size of the page?
In addition, even if there’s no visible reflow, wouldn’t adding a class that doesn’t appear in CSS necessitate the browser’s building a slightly larger classes hash table and/or performing some extra parsing on all stylesheets?
When I said no penalty, I meant that there was no arbitrary rendering penalty for using a class that doesn’t exist. In other words, a modern browser doesn’t hit any sort of significant speed bump just because it runs into a CSS class that doesn’t exist.
I think most of us have an unfortunate tendency to avoid using classes that way because Visual Studio throws a validation warning about classes that it can’t resolve at design time.
You’re definitely right that selecting by class isn’t the fastest possible way. Though, most (all?) browsers implement getElementsByClassName now, so it’s more a legacy problem than something to avoid going forward.
It’s one of those things where it’s important to understand and monitor the relative performance trade offs, but also not lean too far toward premature optimization at the cost of maintainability.
That was very inspiring, I always seem stop optimizing my code when it works, but this has made me want to improve my code with all your great tips :)