[adrianonantua]

You lost me at "to do X in browser Y". One of the main reasons to adopt an experimented and highly used library such a jQuery is that it already deals with the complication of multiple HTML engines. They already solved that problem. Their code is tested and less likely to have bugs than my code.

[malandrew]

Most of the "to do X in browser Y" apply to older browsers (cough IE6 cough) and is rarely an issue in newer browsers which have been much better about following standards. If you use automated testing and do cross browser testing via Karma or JS TestDriver, you'll spot the very rare cross browser gotcha.

TBH with an attitude like that, you're keeping yourself dependent on jQuery and therefore preventing yourself from progressing as a professional software engineer.

[colemorrison]

Progressing as a professional software engineer? Who says that's the goal? What defines a professional? Being able to reinvent the wheel to be a couple of milliseconds faster than one that exists?

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.

[mistercow]

>TBH with an attitude like that, you're keeping yourself dependent on jQuery and therefore preventing yourself from progressing as a professional software engineer.

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.

[xfour]

Wow that's an asinine elitest sounding statement. So reinventing the wheel to feature test or browser test pieces of javascript code for rudimentary differences within browsers, that will probably be around less time than the jQuery library, is the only way to progress, as a "professional software engineer" your programming world view is very narrow.

The point of the original article is valid though, you can't have modules including jQuery, just not gonna scale.

[malandrew]

It is only by reinventing the wheel that progress is made. Do you want an internet that is still mostly jQuery-based in 5-10 years? Ya know, "640K ought to be enough for anybody."

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."

[farinasa]

>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.

[bulatb]

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.

[malandrew]

I know jQuery pretty well as I worked with it a lot until about 1-2 years ago and now I'm working on a product that achieves iOS CoreAnimation levels of performance when performing DOM manipulation. That being said, I don't think people should perform native DOM manipulation directly in any app, only via libraries and frameworks.

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.

[farinasa]

So you MUST be an avid fortran developer right? Have an excellent geocities/angelfire site with marquee and blinks? Still pushing java applets? This is basically the fastest changing field you can choose. I know you must have invested a lot of time in jQuery and would hate for that investment to be marginalized, but the sooner you realize that it will be, the sooner you'll accept that transitioning to the next investment is the only real investment you can make in this field.