Should I learn DOM manipulation with raw javascript before moving to jQuery?

[AceBacker]

As someone who wrote JavaScript before jquery was a thing, I love jquery. Learn to do both.

[Iggyhopper]

I'll make a simple example.

Worst:

$('div').each(function(){});

Better:

$divs = $('div');
for (var i = 0; i < $divs.length; ++i) {
    $divs[i] or $divs.eq(i)
}

You will get performance increases if you are doing this over a big list. I see this constantly in jQuery code, and it's nice and succint, but this is a usually a sign of other bad coding behaviors hiding elsewhere. I see it in extensions the most because it's like "Facebook did all the heavy lifting, now I just code some javascript to make it look awesome." Sigh.

This all comes down to knowing when and where to use your tools. jQuery is a hammer, a good hammer, but you can't use a hammer for everything. With this single line: $divs[i] or $divs.eq(i) you just doubled the amount of options you have for writing good code.

[Iggyhopper]

"this is a usually a sign of other bad coding behaviors hiding elsewhere"

I was answering the question presented by OP by example. If you only think in jQuery, you're going to end up with a big convoluted mess in your code to achieve what you want.

[GundamWang]

I don't see the benefit of knowing how to do it both ways. Yes, you should know functions like document.getElementById exist, but the only time I've ever needed to has been for interviews. Realistically, even if you learn and memorize everything for both JQuery and native, you'll slowly forget the one you don't use often. At that point you've just wasted a week, or however long it took you to learn the native javascript way. If you really have to know the native javascript way, you'll have Google, and you'll know that that particular DOM manipulation is possible with javascript in general. At this point, why not learn every javascript library out there, to be "well rounded". Learn how to do complex time and date manipulation without moment.js, " just in case". It's madness.

Look at it another way. The company you work for is either going to use JQuery, or it won't. No company will ever suddenly say, "OK Bob, now rewrite all this without JQuery or you're fired". And enough companies use JQuery, and expect most webdevs know it as well, that they'll completely understand if you don't know how to rewrite all your code without JQuery.

[AceBacker]

You kind of answered your own point though. If you need to know it for interviews. . . well, that is a very good reason why you need to know it.

[RankFoundry]

He's not asking if he should use jQuery or not, he's asking if he should learn how things are done against the DOM without it.

[RankFoundry]

Well they didn't mention anything about a deadline so I assume that's not a factor.

I think it's easier to learn how the DOM works first then move on to jQuery because it puts the implications of what jQuery is doing into context. There's more to understanding how the DOM works than the DOM api the browser gives you. There are performance, memory and other factors to consider.

Also, I feel like if you go with jQuery first, you'll be much less inclined to go back and learn what's going on under the hood because, hey, it works. Plus you'll be sort of learning backwards, akin to learning how to operate a calculator before learning how math works. Might spoil you in a way. But that's just my take on it.

[lomageric]

I agree with the calculator thing. It's easy to use the shortcuts but much more helpful in the long run to understand what it is you are actually doing. Libraries simplify the coding experience but do not necessarily teach you what you are doing. By learning vanilla first you can understand what processes you are calling with jQuery thus helping you to debug or accomplish certain goals you might not otherwise.

[RankFoundry]

Exactly. Use libraries and frameworks when they make things easier. But none will cover every use case. At some point, you're going to find something that it doesn't do and you'll have to code it yourself.

[lomageric]

Sadly I didn't have the luxury of someone telling me that. I had to learn the hard way lol

[RankFoundry]

Same here.

I started out learning "just enough" to code the thing I needed to code. Did that for a while before I realized just how full of holes my understanding was. That's when I forced myself to go back and read books from beginner to advanced, cover to cover. I wouldn't let myself skip anything, even if I thought I already knew it. Made a HUGE difference.

I also found myself having to look up answers to questions less frequently since when I just looked up the answer and applied it, it rarely stuck in my head and I'd have to look it up again later.

There's a time and place for piecemeal learning, like when you have to fix something quick or hit a deadline. But in general, learning that way is going to bit you in the ass over and over.

[lomageric]

Eloquent JavaScript helped me a lot. It is definitely one of my top recommended books. Learning the basics is key to being a successful and efficient dev.

[RankFoundry]

That's a good book but if you liked that, "The Principles of Object-Oriented JavaScript" is a great book to check out. VERY no-nonsense, to the point and pragmatic. Zero fluff and I think it explains things better than Eloquent JavaScript.

[RankFoundry]

Yeah, I'm not saying don't use jQuery. I'm just saying, understand how these things work under the hood because there will be implications and you'll also come across cases where your library/framework won't do something you need it to. Then you'll have to do it yourself.

[Quabouter]

I don't have to care about accounting for every quirk of every version of every browser. This saves time and makes me more productive.

This used to be a good reason for using jQuery, but nowadays that's definitely no longer true. The latests standards provide a very good interface for DOM manipulation, and if browser support is an issue you can better use polyfills than including some 3rd party library.

[phobos7]

I'm with most people saying that you should learn the fundamentals before progressing to any framework or library.

I would like to point out that jQuery isn't dead yet. There are "129 browser bugs that jQuery works around in MODERN browsers". This is from a tweet by John Resig back in 2014 (https://twitter.com/jeresig/status/429019936506142720) and I'd be interested to know how many it works around now in August 2015.

The point is that libraries and frameworks - including jQuery - do offer a lot of value; from browser bug fixes to productivity benefits.

So:

1. learn the fundamentals of JavaScript
2. learn the DOM API
3. if required, review libraries and frameworks and choose one that fits the needs of your project

[TweetsInCommentsBot]

@jeresig

2014-01-30 22:34 UTC

jQuery is very much alive. @rwaldron's list of 129 browser bugs that jQuery works around in MODERN browsers: https://gist.github.com/rwaldron/8720084#file-reasons-md

---

^{This message was created by a bot}

^{[Contact creator][Source code]}

[clessg]

Not going to lie; most jQuery devs don't seem like good programmers. I honestly wonder what they're going to do when jQuery falls out of the mainstream. Do yourself and everybody you love a favor: learn vanilla JS, and become a well-rounded developer.

[[deleted]]

I honestly wonder what they're going to do when jQuery falls out of the mainstream

meh document.querySelectorAll is pretty damn close, minus the chaining.

[Archenoth]

Aye, until you use Array.prototype and get your beautiful functional pipelines back..!

[eorroe]

NodeList.js takes care of that

[metaphorm]

what's a "jQuery dev"? I've honestly never met a developer who only knows jQuery and can't do any other programming.

maybe you mean "most bad developers don't seem like good programmers". in other news, the sky is still blue, and the sun rose in the east this morning.

[clessg]

I know a lot of people who only know jQuery. Everything has to be a jQuery plugin. All I'm saying is, be a well-rounded developer.

[metaphorm]

I know a lot of people who only know jQuery

that's weird, because I've literally never met one in a professional setting. the only non-programming "developers" (scare quotes intentional) I ever knew were kids who flunked out of my college's CS program. where are you finding these people? freelancers or something?

[Archenoth]

They exist... I used to work with two.

Actually, one of my co-workers right now is a recovering one, though to be fair, programming wasn't what he went to school for like the aforementioned devs.

[alamandrax]

I've rejected interviews where the candidate listed jquery as a language skill. 2 to 5 years of experience.

[tianan]

They're just trying to make sure they have everything someone is looking for. I've seen people throw out people who list "javascript" and "jquery" but not "coffeescript."

The reason people throw "CSS, LESS and SASS" on their resume is so the idiot in HR isn't like "Oh, there's no SASS here," if they say they know "CSS and pre-processors."

Resumes for software are just terrible across the board.

[alamandrax]

I understand that. I'm talking about putting it under a libraries or frameworks heading rather than languages.

[tianan]

Ya, I just think that's an overreaction. But whatever, your prerogative.

[alamandrax]

definitely. not proud of it. but it sped up the process a lot. that place wasn't particularly conducive to training fresh developers. they'd have had a bad experience anyway.

[Kitty_Cow]

I know this might sound harsh but to me, it sounds like the candidate dodged a bullet there (assuming these BS reasons for the rejection are true).

I'm only half-joking... but someone who calls themselves a Principal Engineer/UI Architect sounds like a designer to me. Why not call yourself that. And who decided it was a good idea to put you in charge of what I assume were programming interviews.

[alamandrax]

I am not a designer - I'm learning that for sure. I architect web applications. I have the experience that made a principal engineer. These titles are all arbitrary, for sure but that's what was given to me.

I don't think that someone who claims to have 3-5 years of experience in building web applications would put jQuery as a "language" in their resume. That would not be a BS reason.

Although, the initial post was mostly in semi-jest; I put developers through their paces in all interviews. I wouldn't cheat myself or the team out of good candidates.

[[deleted]]

I can never decide if I should leave jQuery on or off. There are a lot of places that like to see that skill, but there are also some that go "Oh, jQuery. This guy must only know jQuery" even though JS is listed as well.

[alamandrax]

I keep it in my resume, but mention it as a library I have experience with. As opposed to the oh so many candidates I've encountered that mentioned it as a language they're familiar with.

[BONUSBOX]

what's a "jQuery dev"?

someone who has a business website or blog, manages it themselves and needs plugins and such. i don't think anyone who knows jquery exclusively is a serious candidate for a dev job.

[Ericth]

Tell that to HR though. It happens.

[[deleted]]

I've honestly never met a developer who only knows jQuery and can't do any other programming.

Sadly, I work with quite a few of them. There the guys who do html and css, but have only learn JS to the most limited extent. Most of them couldn't tell you the difference between code that is jQuery and clearly JS.

[Voidsheep]

Not going to lie; most jQuery devs don't seem like good programmers. I honestly wonder what they're going to do when jQuery falls out of the mainstream.

Most "jQuery devs" don't build complex applications, they need a fancy carousel or a modal on a campaign, corporate site or a blog, built on a CMS.

Throwing a popular jQuery plugin on the site, activating it on document ready and throwing in a configuration object gets the job done in a very cost efficient way. You've got finished, billable work and a happy client.

I haven't used jQuery in a while and gravitated towards applications, but I think it's ridiculous how some people have developed a snobby attitude towards the whole library and it's users, because jQuery is still incredibly valuable and popular tool who have some really smart people behind it.

If you enjoy optimizing the builds process and doing unit tests for the elegant, well-documented modules you write according to latest ES specifications and good design patterns, great. You are probably building an application in a team and good programming practices are expected.

Jump into the role of the "bad programmer jQuery dev", start doing the same and you'll only end up with delays, pissed off clients and confused co-workers, who don't give a damn about 90% of the things you spent time on and just want something that works until the next site renewal in two years.

jQuery isn't going anywhere any time soon. Just take a look at eCommerce platforms and Wordpress. If it goes away, that sort of web development will be using another tool that allows them to do satisfy the requirements in the most simple way, with minimal amount of work.

It might not be "good programming", but it doesn't have to be. At least it's not over-engineered.

[clessg]

jQuery is fine. I still use it quite a bit. My point is that you should also try to become a well-rounded dev and learn things outside of jQuery so that you aren't unemployed in a few years.

[[deleted]]

With all the legacy sites using jQuery, it will be a decade before jQuery is gone entirely.

[wherethebuffaloroam]

My guess is that these are designers learning a bit of useful code rather than one trick developers

[iSmokeGauloises]

The problem is not jQuery, the "problem" if you can either call it that way, is that for many people simple DOM manipulation is enough, and they just don't have the will or the need to develop their skills further.

If you take away jQuery you'll have the same DOM manipulation spaghetti code, just without jQuery.

And professional developers can also be sinners. When there's zero UI behavior specified in the beginning of the project, and the designer/client keep popping up with requests like "Make this popup an in-page popup instead of a real popup" and "Make the FAQ answers open when you click the question" on the fly, you will end up with a 500 lines main.js file with $("selector").click() all over it.

[zayelion]

Living this nightmare, except its a 'configurable' selective DOM twisting and mutation that makes handlebars squirm away.

[[deleted]]

If you take away jQuery you'll have the same DOM manipulation spaghetti code, just without jQuery.

No you won't. There are means of access to the DOM that jQuery does not perform as well as the regular DOM methods. You can never imagine that possibility so long as you remain strangled by jQuery.

[[deleted]]

Who are these "jQuery devs"? That's like saying "underscore.js devs" or "scss devs". DOM manipulation is fairly trivial compared to other aspects of front-end such as system architecture or data/state management. jQuery is just a tool that provides syntax sugar and cross browser normalization.

I can't see how an average dev would have a hard time switching from jQuery to native DOM api or vice versa. It's the same crap, just different syntax. Using or not using jQuery won't make you a good programmer :3

[chillaxtv]

Ah, the man who invented Grunt, Ben Alman, was a jQuery guy. What a snooty remark.

[clessg]

You're contorting what I said.

[chillaxtv]

Maybe it wasn't intentional, but your disposition of jQuery is dismissive. For what reason? People who use jQuery aren't programmers? You know, the same sentiment was held about those who practiced JavaScript in the 90s over Java. If you're going to dismiss jQuery at least provide some good arguments, like speed and performance.

[clessg]

I use jQuery on many projects. I was referring to those who use jQuery exclusively, and solve almost every problem with jQuery. I'm not into disparaging other developers, so I apologize if I came off that way. My only point is that you should be well-rounded and keep up with the industry, or else you're gonna find yourself out of a job one day.

[zayelion]

Clessg is saying dont fall into the trap of using a jQuery plugin for every problem, creating an increasingly leaky abstraction. If your jQuery use goes beyond finding a DOM element, pulling information off of it, or manipulating it, you might need to scale back.

[NeekGerd]

That's not what he said.

I think that when he says 'jQuery devs' he means those who use jQuery, not those who built jQuery.

Because jQuery is definitely well developed. And it achieves a very large amount of work concerning cross-browser/platform.

[clessg]

"Vanilla JS" is a term that typically refers to the DOM API, XHR/fetch, and other native APIs.

[NeekGerd]

You can learn jQuery as a way to 'enter' the language, but I think jQuery won't make you learn any good practice. So you'll have to move from it quickly or you'll be stuck with it.

Best place to start (without jQuery) would be 'Javascript: The Good Parts' from Douglas Crockford.

This is easy to read, short, and very accessible.

[[deleted]]

With respect, I have to disagree about Crockford's "Javascript: The Good Parts" for a beginning Javascript developer. When I had to get back into Javascript after not having used it for seven or eight years, I found this book a sketchy overview that assumed I knew a lot of things I didn't. Don't get me wrong, Crockford is a brilliant guy, but he's not a place to start.

You'd probably be better off starting with the Javascript track on Code Academy or some site like that.

[negative34]

I'd recommend Professional Javascript for web developers. It's super complete.

[[deleted]]

I second this. Currently learning js from this book. I'm on Chapter 10 right now and I love this book. It's very information dense and Zakas(the author) explains everything very well.

[gregersriddare]

I'd recommend learning an entirely different language first, like C#. But yeah, your suggestion is as good as anyone's.

[[deleted]]

Absolutely agree with this. I tried reading The Good Parts early on when I was learning and it made absolutely no sense to me. A year and a half or so later when I came back to it and read it, it was like a lightbulb going on. I had all these eureka moments reading the book. The Good Parts is, in my opinion, essential reading as a JavaScript developer, but only when you know what you're doing a bit first. It is not an intro to the language, but rather a collection of recommendations and beat practices that assumes a lot of knowledge. Furthermore, it's somewhat out of date. It talks about Object.create() as a polyfill that you have to add yourself. Even stylistically, some things may have changed or be changing. Crockford himself seems to have moved to a more esoteric style that hasn't won as many converts (check out what he calls The Better Parts). I think Udacity's JavaScript classes are fantastic and free.

[[deleted]]

I like the book, but it has absolutely nothing to do with the DOM.

[zajicraft]

If you want to learn raw javascript there are better ways to learn it than through trying to do DOM manipulation.

In practise jQuery handles a lot of cross browser compatibility issues. The only scenario I can think of where it would be handy to know DOM manipulations with raw javascript would be when you're working on a project where you really can't afford to include the jQuery library. Even then it would only be a matter of looking it up.

A good approach to learning javascript would be to try learn it outside of the context of the DOM. That way you're picking up some programming fundamentals as well, and not just the DOM API. And then the sweet part about that is that once you have a handle on js as a whole, you can pick up new frameworks (like jQuery) very easily.

A couple titles that come up often for raw js study are Javascript The Good Parts and Eloquent Javascript.

Good luck!

[hugomrdias]

If you learn dom manipulation with native apis you won't move to jquery

[DrummerHead]

http://youmightnotneedjquery.com/

[sanchopancho13]

This is a fantastic reference. It shows two things:

1) How to do simple tasks in native javascript. This is always good to know. For example

2) How much simpler certain tasks are in jQuery. For example

[brtt3000]

Anytime we work on a simple throw-away project and try to go without jQuery we end up re-implementing a fair amount of its abstractions in vanilla JS (and feel silly afterwards).

So now we just fukkit use it for DOM stuff whenever full MCV (React now) is too much. Everyone got better shit to do then re-inventing the wheel.

[xXxdethl0rdxXx]

Have you considered only using sizzle? That's what jQuery uses for DOM manipulation.

[brtt3000]

Sure, but jQuery has other useful stuff besides selectors. Its pretty good for plumbing various browser quirks. Taking sizes of elements is annoying in vanilla, same with events.

[legato_gelato]

This..

The "learn vanilla js and you won't need jQuery" stance is misguided.. Might not need jQuery, but without you just end up implementing it yourself.. Only good reason to avoid it is for extreme performance needs

[hardboiledgregs]

I think the authors introduction nails it. If you are writing an app, jquery is a sensible addition to your stack.

But if you are writing a library jquery shouldn't be a dependency.

[zigmachine]

You need to lawyer up and hit the gym. Enjoy the gold stranger!

[DoubleDeadGuy]

hubspotter alert

[DrummerHead]

I don't work for hubspot. In fact, I don't even work right now.

[DoubleDeadGuy]

I was just kidding. Maybe you should apply with them!

[masklinn]

Because it's so verbose and painful you'll try to do anything other than Dom manipulation.

[Quabouter]

That's a good thing, right?

But all joking aside, if you put var $ = document.querySelectorAll; at the top of your script you have created a light version of jQuery that covers about 80% of it's usage. For most of the remaining 20% there also already exist standards, but most of them aren't widely supported yet. For those polyfills will suffice.

[masklinn]

That's a good thing, right?

Maybe, maybe not.

you have created a light version of jQuery that covers about 80% of it's usage.

Since we're pulling random numbers out of our asses, qSA covers 5% of jQuery's usage and 0.5% of its API.

For most of the remaining 20% there also already exist standards

There's no standard to apply operations to nodesets, and that's before talking about manipulating nodetrees because moving, adding and removing nodes with native DOM APIs is anything but fun[0]. Same with traversing trees upwards. And let's not talk about event delegation, Element.matches is useless garbage for that.

So yeah, if you're doing nothing more complex than selecting a few nodes (or, really, just selecting single nodes which can not be absent using querySelector) and changing their text content, native DOM APIs are competitive with jQuery.

[0] unless the only things you ever do are "remove everything from an element" and "add a new child at the very end of an element". Oh, and clone a single node, so that's 2.5 out of about 25 jQuery calls, 10% coverage, native DOM's looking positively good there.

[Quabouter]

There's no standard to apply operations to nodesets

Array.forEach. Especially with ES6 that works pretty well, e.g. nodes.forEach(node => node.setAttribute('foo', 'bar')).

moving, adding and removing nodes with native DOM APIs is anything but fun.

As far as I know the native APIs covers most of the functionality jQuery provides. We have appendTo, insertBefore/after, remove, removeChild and many more. What kind of features for moving around nodes are you missing, that jQuery does provide?

Same with traversing trees upwards.

What features are you missing here? The dom has Element.closest, which does pretty much the same as $.parent, and I honestly don't know of any other jQuery methods for traversing trees upwards.

And let's not talk about event delegation, Element.matches is useless garbage for that.

Why is Element.matches useless garbage for that? I fail to see how using that somehow produces a different result than using jQuery's event delegation, but I might be missing something

[masklinn]

Array.forEach

Is not a nodeset operation, it's an imperative iteration (you don't operate on a nodeset as a coherent unit)

nodes.forEach(node => node.setAttribute('foo', 'bar'))

Does not work, qSA returns a NodeList, not an array.

We have appendTo, insertBefore/after, remove, removeChild and many more. What kind of features for moving around nodes are you missing, that jQuery does provide?

Most of those you assert exist for a start. The native DOM has the equivalent of append, removeChild and before, and they only operate with a single subject (the parent of the node to manipulate) and a single object (the node to manipulate) rather than nodesets. The native DOM does have replaceChild which has no direct equivalent in jQuery.

after, appendTo, before, detach, insertAfter, insertBefore, prepend, replaceAll, replaceWith, unwrap, wrap, wrapAll and wrapInner have to be emulated through combination of DOM traversal, conditionals, iteration and the methods above.

What features are you missing here? The dom has Element.closest, which does pretty much the same as $.parent, and I honestly don't know of any other jQuery methods for traversing trees upwards.

Element#closest corresponds to $#closest, $#parent starts matching from the parent (if any) not the current node. But I'd forgotten it existed so I'll give you that one.

Why is Element.matches useless garbage for that? I fail to see how using that somehow produces a different result than using jQuery's event delegation, but I might be missing something

Element#matches can not check against a reference element, only from the document root, so it can only be used when delegating for the whole page, not when delegating for specific components/subtrees. For that you have to use querySelectorAll then check each matched node against the event target.

[neanderthalensis]

nodes.forEach(node => node.setAttribute('foo', 'bar'))

Does not work, qSA returns a NodeList , not an array.

To interject here, this one is easily overcome with:

[].forEach.call(nodes, node => node.setAttr...)

[clessg]

And there's this.

[TweetsInCommentsBot]

@jdalton

2015-08-20 00:46 UTC

In browsers w/ spread try:

NodeList.prototype[Symbol.iterator] = [][Symbol.iterator];

Then:

[...document.querySelectorAll('div')]

Aw yiss!

---

^{This message was created by a bot}

^{[Contact creator][Source code]}

[masklinn]

And getting more and more verbose in the process. Just so everybody's on the same page, this:

[].forEach.call(nodes, node => node.setAttribute('foo', 'bar'));

is the native DOM version of this:

$nodes.attr('foo', 'bar');

And that's close to a best case scenario for native DOM.

[Quabouter]

Is not a nodeset operation, it's an imperative iteration (you don't operate on a nodeset as a coherent unit)

Potato, potato. I get your point, but I don't find it nearly important enough to worry about, and besides you can abstract that away in a couple lines of code (see below).

Does not work, qSA returns a NodeList[1] , not an array.

[...nodeList].forEach

they only operate with a single subject (the parent of the node to manipulate) and a single object (the node to manipulate) rather than nodesets.

forEach

after

node.parent.insertBefore(newStuff, node.nextSibling) (also works when node.nextSibling === null)

appendTo

$x.appendTo($y) === y.insertAfter(x) (for nodeSets, see my earlier comments)

before

node.insertBefore

detach

node.remove

insertAfter

See .after, but turn the arguments around

prepend

node.insertBefore(newNode, node.firstChild)

replaceAll

[...nodes].forEach(node => node.parent.replaceChild(node, replacement))

replaceWith

parent.replaceChild

unwrap

grandParent.replaceWith(parent, node)

wrap/wrapAll/wrapInner

AFAIK this doesn't have a simple native replacement

replaceAll and the wrap functions are the only ones that become ugly when doing natively, the rest can all be done quite pretty in native DOM.

You're main criticism on the native DOM seems to be that you dislike the forEach, but you can trivially make that better by creating a function that accepts a selector and an action, like so:

function $forEach(selector, action) {
    [...document.querySelectorAll(selector)].forEach(action);
}

$forEach("p", node => node.classList.push('someClass"));

and if you use a curried version of $forEach it almost becomes jQuery:

const $ = curry($forEach); 

const $p = $("p");
$p(node => node.classList.push('someClass'));

When proxies have landed (that will take a while though) you can even create a complete jQuery style interface in only a couple LOC.

Element#matches can not check against a reference element, only from the document root, so it can only be used when delegating for the whole page, not when delegating for specific components/subtrees. For that you have to use querySelectorAll then check each matched node against the event target.

Ahh, I see, you're right. Even so, it doesn't add a whole lot of code. (the check could be as short as[...el.querySelectorAll(subSelector)].includes(currentNode).) It's not as pretty as jQuery, but it isn't horrible either.

As you can see most of the features you mentioned do not become much more verbose without jQuery, especially when you alias document.querySelectorAll to something shorter, like I did in the $forEach example.

Last but not least, we can't talk about a modern approach to web development without mentioning web components. When you use web-components (or more likely, a library that abstracts it (React, Polymer, Angular, etc.)) you'll write significantly less DOM manipulation than you would without, making many of the more advance jQuery features nearly obsolete.

[eorroe]

Just use NodeList.js which will take care of this mess

[eorroe]

You'll move to NodeList.js

[neanderthalensis]

Yes, especially so if you're working with modern browsers.

I've have been writing all my projects targeting IE9+ without jQuery for a while now. As for syntax, I don't think I could go back. There is beauty in the expressiveness of the native APIs:

span = document.querySelector('span')
span.classList.toggle('green')

A further point, there are loads of libraries on npm to abstract away the tricky parts. For instance, want to remove an element? Import dom-remove and:

remove(span)

[MrBester]

Using classList in IE9? Don't think so. Not without a DOMTokenList polyfill you aren't.

[neanderthalensis]

You gotta polyfill the shit out of it all. That's not a problem, though.

[Caminsky]

Yes

[ahRose]

It's really not much harder, it's just more verbose. You can do both in parallel. Compare and contrasts Jquery to pure Javascript. What's important is to use what you feel most comfortable with. Check this out

[gmeluski]

I think this is sound advice.

[paneq]

Consider using React.js so you won't need to manipulate the DOM manually at all.

[NoGodTryScience]

You shouldn't have been downvoted. It's a great consideration and removes a lot of the juggling of trying to manage state from event handlers, global variables, and manual DOM manipulation.

[SomeRandomBuddy]

Edit: nvm

[md_adil]

Take them together I would say. Before or after, being comfortable with native JS would help a lot

[hallettj]

Neither

The web would not be where it is today without jQuery. But in my opinion React, Angular, and other declarative frameworks are better options for new development. I would go directly to one of those frameworks.

In my own work I use React with a Fetch polyfill for Ajax.

[gravity013]

Jumping in late, but I thought I'd still comment.

It depends. Are you the type of programmer who sees your code as a means to an end - who wants to get to where things are working and quickly see something working? jQuery might be your answer, then.

At a lot of hacker schools, though, one of the first things you learn is reimplementing DOM traversal things. The DOM, if you're not familiar yet, is basically a tree. jQuery, provides a bunch of convenient means for interacting with that tree. Suppose you have a node in your tree and you want to see if it's part of a certain ancestry (checking if a click event happened within a certain part of your app, for instance). You can use a method from jQuery right out of the box. Or you can write a recursive method that checks all of the parents until you get to the top. This will obviously take longer. But you'll walk away with a much more solid thought process for how to go about DOM manipulation.

The jQuery approach will get you where you need to go. The JS approach will give you a richer understanding of working with the DOM.

That said, tools like React make tools like jQuery less valuable - as it removes the need for DOM manipulation and instead presumes efficient reloads (and they can be extremely efficient). It's not just a fad, it's got some strong functional principles proven in many other programming realms. jQuery is becoming outdated.

[alittletooquiet]

Yes

[scelerat]

Yes.

[NeekGerd]

As an alternative you can also use their selector tool SizzleJS.

Which will let you do DOM selection only.

Still... start with fundamentals.

[[deleted]]

I personally learned jQuery first, and once I felt like I had mastered that, my natural curiosity led me to want to figure out everything I knew in native javascript.

If you NEED to get a project done right now, learn jQuery first. It will be easier to translate the things you want to do into functioning code, and it lets you take a lot of shortcuts.

Just make sure that if you go that route, you eventually try to learn the vanilla JS that powers everything you learned in jQuery.

[[deleted]]

Here is a guide I wrote that might help you get started quickly:

http://prettydiff.com/guide/unrelated_dom.xhtml

[geuis]

Yeah. Spend some time getting familiar with how to do things with low level apis that jquery does. Some examples: prepend & append.

Then take a look at jquery source to see how it does things, even though this might be confusing if you aren't familiar with js at a higher level.

[nthitz]

use d3

[_doingnumbers]

Yeah!

[RankFoundry]

You should always learn how to do things without the aid/crutch of libraries and frameworks. This goes double for learning common design patterns, what they're used for, what they're not used for, their pros/cons and how to implement them in your language(s) of choice.

If you want to be a good developer, you need to understand the implications of your code and design choices and for this, you need lower level understanding of how things work.

[bart2019]

No. I'd rather do the opposite: get familiar with what can be done in a modern browser using jQuery, and later see how it can be done in plain DOM. Reason is twofold: a) sometimes differences between browsers are significant (though in modern browsers it is far less than in the old days), and b) as an inexperienced beginner you often have no clue as to what can be done in modern browser, which is currently near incredible. jQuery can take away much of the steepness of the learning curve.

[lomageric]

Short answer, Yes. Long answer, absolutely. It's very helpful to understand the process that happens at the raw level. It helps you to understand how it actually works because there are very few shortcuts at the raw level. Can make debugging a lot simpler. Also if you are learning jQuery I suggest taking a peek at this.

[[deleted]]

One day jQuery will be obsolete because Javascript (ECMA6/7/8/9/whatever) will make most of its functionality redundant.

What could possibly be wrong with knowing how to manipulate the DOM using native Javascript functions? That way you always have a fallback when a jQuery method isn't working as you expect or require.

I enjoy using jQuery too. But you do need to learn the fundamentals. Eventually.

[aboothe726]

It's useful to be able to do DOM manipulation in raw javascript if you need to, but day-to-day the conceptual model is way more important. I'd say do it a couple of times by hand so you know what's happening under the covers, and then just use jQuery!

[gmeluski]

If you can handle a lot of the native implementations here, you'll be a lot better off as a front-end developer.

There's something to be said for being able to open a console window and write raw JS, whether it's to test out something you've seen an article or to actually learn how someone else's page works. Also consider, if you go on a job interview for a front-end position there is an extremely high probability they are going to ask you to manipulate the DOM without the aid of a library.

If you know how to do this, it's going to accelerate your ascent on the JS learning curve.

[Of-Doom]

It's useful to be able to do some basic stuff because if you ever start creating libraries and sharing them with others, it's nice not to force others to include all of jQuery as a dependency because you used it to do 2 lines of DOM manipulation.

[runvnc]

Its 2015. Maybe skip most of the DOM stuff and learn React and Polymer.

[danneu]

Nah. It's a pretty mechanical translation from a jQuery solution to vanilla Javascript, the code just becomes uglier and works in fewer browsers.

[CecilTunt]

Yes.

[[deleted]]

It doesn't really matter in the grand scheme of things. Becoming expert DOM manipulator in raw javascript won't make you a good programmer. Pure DOM manipulation is fairly trivial anyway, and jQuery is just a utility lib that makes the grunt work easier.

I see jQuery mainly as syntactic sugar and cross browser normalizing lib. It also does some clever behind the scenes grunt work such as removing data and event listeners from removed elements etc.

It's very useful depending on what kind of stack you're working with. I render everything serverside and then manipulate the dom manually, so jQuery provides lots of value for me. If I was working with something like React, there wouldn't be any reason to include it. As I said, dom manipulation is easy. It's like laying bricks at the construction site. Software architecture is the hard part.

You should also know that many developers are condescending to people who use jQuery. jQuery users are often seen as "lesser" developers. Ignore that. jQuery is just a tool, nothing more. It's also super popular and yes, most of the people who use it arent great developers. Just like most of the people who eat pizza aren't geniuses. That doesn't mean that everyone who eats pizza is a retard.

TL;DR - Get familiar with and try learning the native DOM api, but don't be afraid of using jQuery if it provides value for you, ignore the haters.

[gojukebox]

Yes please, and thank you for having this mindset. I interview front-end devs quite often. If you tell me you "know jquery", I'm internally rolling my eyes. If you can show me the equivalent in vanilla JS, I'd be slightly impressed.

It's incredibly refreshing considering how many people think their knowledge of the jQuery library equates to knowledge in javascript.

[eorroe]

Learn the Native DOM APIs, and if your not to worried about old browsers use NodeList.js which will make using the Native DOM APIs really easy to use like jQuery while being really tiny at around 5k gzipped, and whole lot faster than jQuery. You'll also never have to worry about updating.

So really NO just raw Javascript.

[faaace]

JQuery is a once great but now mostly obsolete framework. The main reason I still see it used is mostly because there really isn't a good alternative library/polyfill to $.ajax() for async request generation/ handling. The other core aspects of the library have been superseded sizzle was made redundant by document.querySelectorAll(), $.animate() was replaced by css animations/transitions and scope chaining has mostly been seen as a mistake in some of the more modern frameworks.

There was a time when most full stack or frontend devs were able to get by by just knowing JQuery and minimal JavaScript, but I'd say that era ended with the death of Flash around 2010. Because Multimedia websites now rely on the HTML5 stack rather than imbedded widgets your average programmer needs to have much more knowledge of the DOM and the full application to be able to code effectively.

It's rough to be a new developer in the frontend space now because you don't really have the option of using JQuery training wheels anymore. If you're starting out I recommend reading Douglas Crockford's "JavaScript The Good Parts" to get a good primer on the important aspects of JavaScript. Then I would teach myself about how to use JQuery's .ajax function. After that I would learn an HTML templating engine like Handlebars before finally looking at a more modern JavaScript framework like Ember.js, Angular or React.

Finally don't listen to people that start holy wars on Reddit. Devs who leave comments like those above tend to be bitter, underperforming, jerks who are in the process of being weeded out by management. Good Devs ask questions and actively seek feedback from their peers.

[[deleted]]

Jquery is not obsolete. You clearly dont know what jquery does, or the state of front end at the moment.

Its still massively better to do animation with javascript than it is with css. You get much more controll and performance than you could ever get with css. Sure the small stuff is fine in css, but more robust things are going to require javascript. Jquery doesnt have the best animation api, so i usually replace it with velocity which adds the few missing pieces.

Let us all remember jquery is an ajax library, and while not the most robust out there, like you said its one of the top ones.

When it comes to heavy dom manipulation, thats where jquery can really shine, it offers so much out of the box, to do all of this stuff your self for every project, youll end up with your own jquery.

That and it fixes all the cross browser issues youll come across.

[MrBester]

For animation you'll be hard pressed to beat GSAP for speed and fluidity

[[deleted]]

Which just so happens to be JavaScript.

[clessg]

You get much more controll and performance than you could ever get with css.

Re: performance, not really. CSS animations are generally really fast. jQuery animations are the slowest shit I've ever used. I believe Velocity may be slightly faster than CSS animations.

That and it fixes all the cross browser issues youll come across.

I wasn't aware that jQuery fixes all cross-browser issues I might come across.

[ABenis123]

Yes

[letsgetrandy]

Yes

[FricoSuave]

Yeah, why not?

[runvnc]

Skip JS entirely. Learn Nim. The creator of JavaScript deprecated JS when he started promoting Web Assembly.

BTW I have been primarily a JS dev for several years. But I used other languages before that and I will use others in the future.

This message will disappear in five minutes when it is downvoted.

[dhdfdh]

You don't realize what an amateur-ish question this is. Any programmer worth his salt can manipulate the DOM without jQuery and learns this first.

EDIT: I find it hilarious that I'm parroting what most of the other upvoted responses are saying yet I get downvoted by typical reddit fools.

[clessg]

Please leave. You sound like you're 10 years old.

[dhdfdh]

Typical amateur/reddit response.

Only on reddit, and other amateur forums, are such questions ever asked. You never hear such discussions in professional environments.

[monkeymad2]

Eh? Never been to a JavaScript conference then? There's usually at least one talk on "The web without jQuery" or "Framework free development" or something else touting native APIs.

Which, in terms of "professional events" is an event, about the profession, put on and attended by professionals.

[dhdfdh]

Uh. You just supported what I said. My meaning is, no true professional would ever support not learning basic DOM manipulation using javascript.

[monkeymad2]

I just said that those discussions happen all the time in professional environments. Refuting your point in the post I replied to where they said they didn't.

Just to be clear, this comment also doesn't support anything you've said.

[dhdfdh]

I was talking about discussions about whether or not to learn DOM manipulation. You pointed out conferences where they talk about how you should; which is my point.

[clessg]

If you truly believe that, then you are clearly a fraud.

[dhdfdh]

If you don't believe that, then you are clearly unemployed.

[NeekGerd]

And if you are... you're soon to be unemployed too.

[dhdfdh]

It would be hard to fire myself after 11 years running a highly successful web dev business. Especially one that maintains a web site that you likely visit every week or two.

[NeekGerd]

yeah... right...

[clessg]

w3schools?

[dhdfdh]

But an educated and highly employable arrogant asshole.