|
|
|
|
|
|
by bulatb
4813 days ago
|
|
|
Where's it gonna go? Even if jquery.com and all the CDN-hosted copies just fell off the face of the earth, you'd probably still have a dusty fork somewhere. Worse case: you go digging through your browser cache. It's certainly good to know about the DOM and have some clue about what jQuery is doing, but getting to the point where you can switch to native DOM at will without losing any speed, just to say you can, seems like a textbook case of premature optimization. Do it if you're interested, but not to solve a business problem. And remembering which browsers use textContent and which ones use innerText is not nearly as important as understanding that the DOM is there, what it does, and being able to use JavaScript to do things that jQuery doesn't have a method for. In the unlikely case that the Internet explodes and changes such that jQuery is busted but your old DOM knowledge still applies, or you very quickly switch environments to something where it's not an option, what would you do? Well, jQuery was more or less a DOM replacement with some promises and stuff built in. You'd probably just write that. So why not skip the hassle and just stick to jQuery? Learning how things work underneath is valuable and good, but only when it's really an investment—or you do it in a way that doesn't cut your current productivity. |
|
|
jQuery was great. Emphasis on the was. It's monolithic and has become long in the tooth and there are now much much better approaches to DOM manipulation that are now achievable. If you keep doing things the jQuery way you're always going to hit performance issues that cause jitter and jank in a web app. You'll never get buttery smooth, consistent 60fps performance with jQuery approaches. The biggest problems with jQuery is that it makes selecting and updating DOM elements so easy that almost no one caches their DOM pointers and that it doesn't really support performance deferrable atomic updates when performing batch updates on nodes. There are more issues than just that too. The number of layers of indirections that must be calculated through to perform even trivial updates is very wasteful, especially when you consider that many of those layers of indirection are there to support older buggy as hell browsers that only continue to lose market share.
If you want 60fps in your web app, then you need to program to 16.66ms cycles. If any of you updates take more than that, then it blocks the event loop and your FPS drops. Many many operations in jQuery are in the 100+ms territory. Your top framerate at 100ms is a mere 10fps.
When it comes to the DOM it most certainly is not premature optimization. If you think otherwise then you probably haven't built a serious web app on par with the native apps on iOS and Android. With the DOM, you need to code for performance from day 1. Like the turtles, it's abstractions all the way down and with each layer you lose some performance. The DOM is an abstraction that needs to be handled very very careful for it not to become a performance killer.