Hacker News new | past | comments | ask | show | jobs | submit login

I seriously don't know what these "puritan"/back-to-the-roots people are trying to achieve here.

First, when they mention raw/plain/vanilla js, they 99% of the time mean DOM and not js.

So, there you go, case closed, next please.

But for the sake of argument, let's explore both sides of the debate. Yeah, learning and mastering js and DOM is very important and if you rely only on jQuery or any other library or layer of abstraction to get by with web development, that would definitely hurt your potential and chances of getting ahead within any organization or specifically my team but let's put this point aside for a moment here and discuss an equally if not more important one.

The main criticism leveled against using libraries to manipulate the DOM is that they add another layer of abstraction and subsequent maintenance overhead and also the perceived or alleged performance degradation in terms of time required to complete the necessary operations.

Without downplaying these "legitimate" concerns, I have not seen not even once one of these critics faking being impartial in their assessment of DOM libraries by listing their unquestionable advantages they bring to the table like next-generation selectors like :has(), :contains(), :gt()...etc and not having to write a lot of boring and suffocating boilerplate garbage just to apply some style info to a set/list of DOM elements just to prove to those reactionary folks that I'm a capable dev.

Sorry guys, if jQuery or lo-dash is already used and bundled with the project, I'd use it in a blink of eye, if it is not included, I just wait and see if I'm writing a lot of boilerplate garbage just to get the basic functiosn I expect and take for granted when manipulating the DOM, I'm bringing to the mix to your chagrin.

parents('.classname') >>>>> parentElement.parentElement.parentElement.parentElement Ad nauseam




> The main criticism leveled against using libraries to manipulate the DOM is that it adds another layer of abstraction and subsequent maintenance overhead and also the perceived or alleged performance degradation in terms of time required to complete the operations.

I partially disagree with your assertion; layers of abstraction are not always bad and let's face it the DOM API, while simple, isn't as nice to write as jQuery due to its verboseness. But the main criticism I've seen is the size and speed, not abstraction and speed. If you're working on a project that doesn't require supporting older browsers then you don't really need much of what jQuery includes except maybe its simplified API. Calling native query methods in the browser is always faster if they're fully supported.

I certainly wouldn't recommend dropping jQuery for only performance reasons though. jQuery is awesome; it makes the DOM API less stupid and it helps a lot with older browsers. But I also don't think it's bad at all to completely drop the use of jQuery if you don't have old browser requirements.

> parents('.classname') >>>>> parentElement.parentElement.parentElement.parentElement Ad nauseam

While this looks terrible I would argue your code shouldn't need to do this in native DOM or jQuery. Ever. This looks like something you might do in an emergency / patch but any html structure and / or front-end framework you're using that requires this has a serious issue. In my opinion.


> parents('.classname')

In DOM4, which is available in modern browsers: .closest('.classname') possibly also .parent('.classname'), but haven't looked it up.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: