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

jQuery is not a framework by any definition of the word. It's a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation.



It's still much easier to manipulate DOM with jQuery than with any of the "modern times" APIs.

Hell, even querying the DOM is still easier with jQuery.


Barely. document.querySelectorAll() has about 98% of the capability, and 10% extra too.


You probably haven’t used jQuery beyond the basics. Its API is much more powerful, composable and terse than the native one. We lost a great opportunity to standardize on what everybody was already using.


jQuery: returns an array-like structure that is consistent with the rest of the API whether it's one element returned, no elements are returned, or many elements are returned.

DOM:

- few if any DOM methods work on an array of elements. Or even on a NodeList

- `querySelector`: returns null if not found, Element if found. Throws if there's a selector syntax exception.

So you have to wrap it in a try/catch and in a check against null when you need to use it

- `querySelectorAll`: returns NodeList, Throws if there's a selector syntax exception.

NodeList is not an array. It's so badly designed that even the .forEach method was only added to it two years after the method was introduced.

If you need anything but .forEach, it's better to call Array.from() on the result than deal with iterator shenanigans of it's sparse interface

But sure, "it has 98% and 10% extra", whatever that means.

And that's just two of the methods. Everything else is just as bad: 90s-era verbose imperative object-oriented API.


I have never heard of a case where I need to care about selector syntax errors. If it ever happened, I guess I'd just use a try?

Much of the time "checking for null" consists of adding a single question mark.

    document.querySelector("div#options")?.setAttribute("hidden", "true");


> If it ever happened, I guess I'd just use a try?

Exactly, you'd "just use a try". Instead of not using it.

> Much of the time "checking for null" consists of adding a single question mark.

Note: this API was introduced way before the `?` was even thought of. Which tells you a lot about the quality of the API.

So. Just for the simple task of selecting elements:

- you have to different APIs for "select 1 element"/"select multiple elements"

- these APIs differ in their behaviour. They can also throw

- almost none of the DOM APIs work with the return values of one of those APIs (e.g. your example stops working the second you use querySelectorAll)

On top of that:

- none of the DOM APIs can be chained, or combined in any meaningful way, so if you want to do more than just call one method, you're up for some very verbose and tedious boilerplate


> Exactly, you'd "just use a try". Instead of not using it.

This has happened zero times so far, to me.

You can use qsa all the time if you want a consistent interface. I consider throwing to be a good thing if the input was bad.

For me, none of these things represent a significant enough problem to take on another dependency.

I'm probably doing different things than you. If JQuery solves some of your problems, I'm not trying to convince you to stop using it.

I know you're asking/wishing it was the standard library. I don't even disagree, really.


> This has happened zero times so far, to me.

This has happened more than zero times to me.

> You can use qsa all the time if you want a consistent interface.

Indeed. And qsa is so much more verbose.

Note how this whole discussion started with:

- [jQuery] a collection of largely unnecessary (in modern times) utility functions for imperative DOM manipulation

- It's still much easier to manipulate DOM with jQuery than with any of the "modern times" APIs

My last statement is still a fact. "Modern" DOM APIs are anything but. They are the same 90s era OOP that is extremely verbose, cannot be composed in any meaningful way, and provides just a handful of somewhat useful utility functions that don't mean much in a grand scheme of things.

There's a reason that even the most staunch of anti-framework people (like most of the web component crowd) immediately fall back do just dumping strings into DOM via .innerHtml


Library vs framework is a largely pointless distinction, IMO.


Not really. A framework is something that has opinions about the structure and architecture of your whole application. A library doesn't.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: