Weaning yourself off jQuery
substack.net
substack.net
TBH with an attitude like that, you're keeping yourself dependent on jQuery and therefore preventing yourself from progressing as a professional software engineer.
Well said. Sometimes the easiest way isn't the best for your own future. jQuery will not be here forever. I can promise that much.
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.
The point of the original article is valid though, you can't have modules including jQuery, just not gonna scale.
jQuery made sense before you had somewhat sane module systems like CommonJS+Browserify and Require.js and accompanying build systems.
To keep using a monolithic library that includes kitchens sinks from 2006 when much better approaches exist in 2013 is asinine. I'm really happy that many engineers from the worlds of Python, C, Ruby, Java, Clojure, Haskell, etc. are all crossing over more and more into JavaScript over the past 3 years or so. 90% of all the progress I've seen in the JavaScript work has come from outsiders that show up in the world of JavaScript and DOM and think to themselves "WTF is this shit?!?1 How in the hell have these guys gone almost 18 years without a proper module system and package system"?" and then proceed to code up solutions in JavaScript that provide them the comforts and niceties that they are used to from other programming environments.
I'm primarily a JavaScript developer and I'm very thankful for all the outsiders improving our ecosystem because most of the people in the JavaScript work gave up long ago by not looking beyond jQuery.
Alan Kay said it best when he uttered, "They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs."
No, jQuery may not be around forever...but then again browsers might not be around forever. Should one be completely dependent on jQuery? Probably not. But should one discount the level of genius that's been input into something like jQuery? Sure, if you think that you can write something better than their team. And that brings me to my main point:
jQuery isn't just "Easier." In most cases, it's BETTER.
"Oh but I can write in ajax functionality that's faster/ follows standards/ etc."
Great, but while the edge case dev is doing that 100 others have released their product. And I honestly doubt that whatever the edge case developer has written is THAT much better than what the jQuery team has written.
The best software engineers, especially in a high-paced entrepreneur role, GET SHIT DONE.
Using a tool because you recognize that it is more reliable than not using the tool is not the same as being dependent on the tool. I've worked on projects well-suited to jQuery where the client didn't want any jQuery dependencies, and I made it cross browser compatible. But it took longer to write that code, and will take longer to maintain in the future, than if I had just used jQuery.