![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Libraries can use jQuery all they want internally without a developer needing to 'know jQuery'. Of course, most libraries, at least the ones where the authors actually want people to use their stuff, don't use jQuery or at minimum don't pull in full jQuery, because jQuery is both large and largely unnecessary. Angular uses jQuery's API for DOM interactions, but by default it uses a stripped down version due to jQuery's weight.
jQuery served a purpose in the last decade. It provided an 'easy' way to do most things in a 'cross-browser' fashion, since it used to be a pain in the ass to do things like get the text content of an HTML node in cross browser code. Luckily, both the standards and the currently used browsers have advanced heavily, and doing things in vanilla JavaScript is not hard. ES6 has fetch, so I don't need jQuery for AJAX, ES6 has a promise spec that isn't idiotic, so I don't need jQuery Deferreds, and for anybody using shadow DOM or shady DOM, jQuery's DOM features become largely neutered and useless. Any expressive methods jQuery offers, like extend, are better provided by something like lodash.
In 2008, jQuery was fairly fundamental. In 2015, the world doesn't really need it anymore.
That's because the boot camps focus on teaching things like jQuery and CSS (probably in a 'use bootstrap for all of your CSS' manner, too), instead of teaching a good computer science foundation. You've just pointed out the exact reason why CS programs should not be teaching jQuery and CSS...The last thing we need is for computer science programs to be MORE like those bootcamps.
I'd rather hire someone who understands that the DOM and CSSOM are trees, and the implications that has on manipulating and rendering in the browser who hasn't ever touched jQuery than someone who doesn't really understand trees but can barf out tons of jQuery spaghetti.
So do a lot of people. There's a bottomless pit of opportunities cleaning up the messes people who don't understand what's going on under the hood can create in entirely client-side single page web applications built with a framework like Angular that runs a synchronous digest loop with ditry-checking based two way data-binding. If someone is going to be writing a large scale AngularJS application, whether or not they know how to use jQuery is the least of my concerns.
Anybody who's been around web development through the shift to client-side frameworks knows the kind of trouble people got into with Backbone and Angular because they weren't paying attention to what was really going on when they were using features of those frameworks. They're great, powerful frameworks, but only if you have a good understanding of their inner mechanics and what's going on under the hood. People who skipped out on learning about algorithms and compilers in pursuit of learning jQuery and CSS are not going to have an easy time learning how their platforms actually work, and that spells trouble with a capital T.
Which is probably a problem of delivery rather than potential for practical application. Too much of the post-secondary education world doesn't do a good job of encouraging students to learn. Algorithms, compilers, and computer architecture are probably the three classes that will set you apart as a web application developer, yet these are the things often cited by so-called web developers as 'useless' or 'impractical'. It really is a sad state of affairs, because these are the tools of true engineering.
To bring this back around to the idea of whether or not people should learn C, even though they're probably going to go off and get a job writing C# or JavaScript or TypeScript and 'never touch C': C forces you to get into the habit of caring what's happening lower down. You develop the ability to figure out what a sort function you're trying to use is doing under the hood, what its performance characteristics may be, and what implications it could have on your larger application. Writing fast C code teaches you to learn whether or not a cache miss or a branch mispredict will matter for you. It teaches you to be able to make back-of-the-napkin predictions about how much time something might take to run, or whether or not a given approach will work for an input size of a certain order of magnitude. Even when a library or system API is handling something for you, you often wind up being mindful of what it's actually doing. Maybe not down to exact line numbers, but you at least try to figure out how it works.
This same skill turns out to be very important for web developers. A good JavaScript developer should be able to learn how traversing scope chains and prototype chains to resolve variables can impact their application's performance, how the garbage collector works, how memory leaks in JavaScript can occur, why sparse arrays are so expensive to work with, etc. A good JavaScript developer needs to be able to understand what the libraries and frameworks they're using are actually doing if they're going to write fast, maintainable, scalable applications. A lot of these skills come naturally to someone with a good background in computer science and with experience working closer to the machine. The JavaScript runtime is a 'virtual' machine after all, and while it's much more abstract than an i386, the ability to intimately understand what it's doing is of the same nature.
Last edited: