The given example of element.nextSibling is a great example of what jQuery gets wrong. In jQuery, that's going to be $(el).next();
On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing?
element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic.
The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot. What they are referring to here is an idiosyncrasy, and jQuery is jam packed with them. The difference is they have learned them already.
If you learn jQuery today, you're not learning core JavaScript, and considering the trajectory of web technologies you'll be doing yourself a disservice not to use that learning time on actual JavaScript that you could use in future tools. jQuery isn't a bad choice if you know it already, but if you are a new developer do yourself a favor and learn the foundation it's built on first.
> element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic.
The only catch here is that it will give you the wrong answer, and that you should (almost) never use it since it includes whitespace nodes, which you practically never want. This is why nextElementSibling exists (get the next sibling that is an element).
As for the naming: this is an old old discussion we will never agree on, but I think that in the context of a DOM traversal library "next" is pretty clear.
> The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot.
Your assumptions about my knowledge couldn't be more wrong. I spent years writing plain JavaScript. I even wrote a jQuery alternative back in the day as I didn't like various aspects of it (I think I was the only user), before giving in and "just using jQuery". I still don't like those same aspects, but it's not bad enough to use something else.
I have also, recently, tried very hard to use plain JS, and this post is the result.
> if you are a new developer do yourself a favor and learn the foundation it's built on first.
This is just a variant of the old "kids these days, they just learn Python instead of REAL development with C, they don't even know the difference between the stack and heap!!" Okay, shrug. In the meanwhile, those "kids" are solving real problems, so well... Programming isn't some kind of intellectual exercise, it's a tool to solve problems.
> The only catch here is that it will give you the wrong answer, and that you should (almost) never use it since it includes whitespace nodes
But that's perfect, because it does what it says. If I wanted to get the next element only I would used the correctly named nextElementSibling. How do you get the next text node sibling in jQuery?
> Your assumptions about my knowledge couldn't be more wrong.
My apologies. I was reading between the lines and I guess I got it wrong.
> This is just a variant of the old "kids these days...
Not at all, it's advice for the future of the web which will be more plain javascript based but within frameworks like React and Vue. They're grabbing more and more of the job market share. I am being pragmatic here, knowing jQuery won't help you navigate the world the "kids" are busy building right now with frontend SPA frameworks.
jQuery obviously has it's place, and if you prefer using it then no one can stop you. I just don't agree that it's better, and I don't believe it's as useful to know for new developers with the way the industry is changing.
element.querySelector('span') is the equivalent. Just as elegant, one fewer function call.
1) People like me care obviously. It's all bike-shedding anyway, so it's just a point of discussion.
2) nextSibling and nextElementSibling are two different properties, and you can't do the former in jQuery at all. In a typical usage you would need to do $('.my-class')[0].nextSibling, or in other words, dig down to the native DOM API anyway.
element.querySelector('span') would work from parent but not sibling as $(element).next('span') does.
You could certainly use that if you selected the parent, then did querySelector from parent (which for all I know is how $(el).next('span') works). So not equivalent, it's an extra step.
And that's kind of the point I think. Instead of writing this stuff (with much longer syntax) over and over again, jQuery might be better for casual web dev. Still. In 2019.
But whatever works for you. If you don't like it cool.
Yeah in JS that would be element.parentNode.querySelector('span').
I guess to me, that's not a bad thing. Verbosity is good, it's clear what's happening which leads to fewer unexpected outcomes.
What I have learned from this thread is that people don't really like the native versions of these kinds of things, whereas I think the above is much cleaner. It's not my place to say one is correct and one is false, and the popularity of jQuery speaks for itself. I am just one point of view.
It is not a equivalent to $(el).next('span') .
Your code means selecting the first span in the parent of current element, while the jQuery one means the first span after current element. It will produce different result when there are a span before current element.
Perhaps that's where the impasse is, because I see the platform APIs to have a reasonable experience now. I much prefer the browser implementations most of the time. Except drag and drop and Ajax. Those are terrible.
I also preferred PrototypeJS over jQuery, it's approach of extending objects made way more sense than a god object that wrapped itself around my existing objects. I have simply never liked jQuery's approach or API.
> Except drag and drop and Ajax. Those are terrible.
And except actual DOM manipulation which is tedious, error-prone, and requires tons of boilerplate.
> I also preferred PrototypeJS over jQuery, its approach of extending objects made way more sense than a god object that wrapped itself around my existing objects.
Prototype extended global objects which made them even more magic and would break vanilla JS. jQuery creates a wrapper object with well-defined methods and lets you access the actual unaltered underlying DOM object.
Vanilla Javascript has nothing to do with DOM APIs. DOM APIs is just another interface/library/abstraction that you need to learn after you've learned JS.
> If you learn jQuery today, you're not learning core JavaScript
You are right, but it's kind of beside the point given the context is web libraries. jQuery is built on top of the DOM API, so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from?
jQuery will eventually go away while the DOM API is part of the web's core stack. Maybe it changes over time, but there will likely be a DOM API as long as there are HTML based browsers.
I agree that learning the DOM API is an important core skill for web developers. But not that you should avoid using jQuery.
jQuery, or something like, it will be around "forever" because a core problem it solves is inherent to the DOM API.
("forever" actually means for the foreseeable future, projecting out where trends will take us in the future.)
The core problem is, there is no DOM API... there's a collection of DOM APIs which overlap (a lot) but that have various differences from browser to browser and from release to release. Just as importantly to software development, the wholly stable parts aren't really a single API either, but a group of APIs with a lot of duplication and variation in the patterns and idioms used.
For good software of any complexity, you're going to want to build as much of your code as possible in terms of a simple, concise, consistent, stable foundation and the DOM API is not those things. It doesn't have to be jQuery.
(BTW, I'm mainly talking about application-level code here. For utilities, plugins or other lighter-weight libraries, NOT requiring a separate library is a significant advantage. And your DOM access may be limited and well-defined so that a vanilla approach isn't burdensome.)
> You are right, but it's kind of beside the point given the context is web libraries.
I don't think it is.
> so it's a library on top of an abstraction. It is just as simple to learn, so why not learn the core abstraction, with which all other DOM based abstractions are built from?
DOM APIs are not as easy to learn. They are verbose, cumbersome, inconsistent in behaviour and capabilities. Even the staunchest evangelists of the "use the platform" movement run head over heels to anything that frees them from DOM APIs [1].
There's nothing wrong with learning jQuery (or any of the other libraries or frameworks) first, and then learn the core APIs to see how stuff works (and run away in horror). However, they are not a prerequisite for "vanilla js" or "core JavaScript".
> jQuery will eventually go away while the DOM API is part of the web's core stack.
That's the end goal of jQuery: to become the disappearing library. That is, to become irrelevant when the capabilities it offers appear in the browsers themselves. However, this will never happen as long as w3c goes out of its way not to offer any APIs with a sensible developer experience.
----
[1] You can see it in Web Components where "use the platform" is immediately abandoned the moment lit-html hits the scene or Template Instantiation is proposed.
> That's the end goal of jQuery: to become the disappearing library.
I guess my argument is simply that for the most part it's already happened, there is nothing particular scary about "jQuery style" general usage of the platform APIs.
Anything more complicated and I would prefer to enlist libraries other than jQuery. Drag and Drop, animation, AJAX, UI, all have libraries I would prefer. For anything less complicated I can just use what's currently in the platforms. For animation, CSS and class toggles are usually enough. Anything more complicated and there are better libraries for that.
> Even the staunchest evangelists of the "use the platform" movement run head over heels to anything that frees them from DOM API
Tongue in cheek but, that might make me the staunchest then, because I developed a workflow for using Web Components that uses only the spec, includes templating, data binding and is very simple. Shame it only works in firefox!
> There's nothing wrong with learning jQuery first
Practically speaking probably not, and you could make it through your entire career jumping from jQuery to React or Vue or whatever is next and never learn the platform APIs. I don't think there's anything wrong with that either. But if it's a hobby or your passion for web technology exists outside of work, I really do think you would be doing yourself a disservice not to thoroughly learn the platform.
> Drag and Drop, animation, AJAX, UI, all have libraries I would prefer. For anything less complicated I can just use what's currently in the platforms. For animation, CSS and class toggles are usually enough. Anything more complicated and there are better libraries for that.
And that's the thing: there are always libraries. There are very few use cases where you want to use DOM APIs directly. They all but sream "use a lib/wrapper/framework".
On first encountering $(el).next(), you need to answer a bunch of questions. Next what? Why is this a function and not a property of the object? Why not call it getNextSibling? What the hell is $() doing?
element.nextSibling is very clear. It's the next sibling of the element. It's idiomatic javascript, and it follows a good naming convention, which is a skill that is language agnostic.
The author is also conflating their time learning as a pro for jQuery. Had they learned vanilla javascript first, their point about not knowing which nextSibling to use would be moot. What they are referring to here is an idiosyncrasy, and jQuery is jam packed with them. The difference is they have learned them already.
If you learn jQuery today, you're not learning core JavaScript, and considering the trajectory of web technologies you'll be doing yourself a disservice not to use that learning time on actual JavaScript that you could use in future tools. jQuery isn't a bad choice if you know it already, but if you are a new developer do yourself a favor and learn the foundation it's built on first.