Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A few years ago I dropped jQuery for plain vanilla js and I've never looked back. Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins", that usually only do what they want to do and not much else.

Yes, the vanilla selectors are more verbose, but any half decent code editor will make them just as fast to type. I don't mean to be penantic, but I don't really understand why so many people still use jQuery at all.

https://youmightnotneedjquery.com/



Look at your own link - the "modern" way of doing it is always about 2-3x as verbose as jQuery. Editors let you type that mess faster, but you'll still have to read through it, maintain it, scroll it into view in your editor, see less of it onscreen at a time, etc. I'll take a clean, succinct API over a noisy verbose cumbersome one any day.

And what are we saving by eschewing it and going vanilla? One little 30kb-gzipped javascript file - smaller than most jpegs. I agree for super simple tasks it might be best to skip it.

The DOM API is a sloppy and hastily-designed pile of crap from the OOP era that we're unfortunately stuck with for legacy reasons. jQuery shows what it could have been.


You just described why I use slim-lang in all of my projects. produces clean, correct HTML with zero noise.

Ends up eliminating 50-60% of the code, and the time for writing and reading it.

As for jquery I haven’t needed it much since stimulusjs but loved it whenever I used it.


I'd only drop jQuery/lodash if you were adding Typescript. And I do prefer dropping them for Typescript, but the previous are still cool.


That is not correct at all. The DOM API is entirely functional based upon traversal of a lexically scoped model. It may not be as declarative as you like but lying about what it is because it makes you feel uncomfortable is rather ignorant.


> The DOM API is entirely functional based upon traversal of a lexically scoped mode

wat

DOM APIs have been, and still are, 90s-era OOP style with zero attempt at being functional, declarative, or composable.

Even the newly developed API are usually stuck in the same mindset (see everything developed for web components)


The DOM is a big in memory object but the DOM APIs are entirely functional. Functional is not the same as declarative.


> DOM APIs are entirely functional.

(Almost) none of the DOM APIs are functional. They are literally `object.methodCall()`


Yes, functional programming can have methods. Methods are functions. OOP is all about polyinstantiation and inheritance. Functional programming is all about functions and input/output, which is entirely what happens in this case. The only OOP here is the method assignment you don’t see: Element.prototype.getElementById = function () {};


You're making no sense. Functional programming is more than just "about functions".

DOM APIs are the embodiment of 90s-era OOP. There's literally nothing functional about them. All [1] "functions" are methods defined on very specific objects. You can't even get a proper reference to them without binding them to specific object instances

What exactly is functional about this?

  const newDiv = document.createElement("div");
  const newContent = document.createTextNode("Hello, world");
  newDiv.appendChild(newContent);
  const currentDiv = document.getElementById("div1");
  document.body.insertBefore(newDiv, currentDiv);
Okay, here's an easier question. What will happen here, and why?

   const function_reference = document.getElementById;
   function_reference("#id");
[1] Technically speaking, not all all. The more recent `fetch` is probably the only piece of browser APIs that can be called functional for some very limited definition of functional

Most (all?) other "global" functions are defined on the instance of the window object: getComputedStyle, getSelection etc.


> What exactly is functional about this?

A series of function calls that each do something and each returns a value.

> Okay, here's an easier question. What will happen here, and why?

A function call that does something and returns a value, because in this language complex types are passed by reference.


> A series of function calls that each do something and each returns a value.

Doesn't make it functional

> A function call that does something and returns a value,

Ah, so you don't know.

Here's what will actually happen:

      TypeError: Can only call Document.getElementById on instances of Document
Because it's a method on an object. And you have to bind that method to a specific object instance before you can call it.

If it was functional this would never be the case. But since this is 90s-era OOP, you have to do this:

      const function_reference = document.getElementById.bind(document);
      function_reference("#id");


> A series of function calls that each do something and each returns a value.

This is not what functional programming is. Functional programming is a completely different paradigm for writing code, and it _is_ declarative by definition. The Wikipedia definition is pretty decent:

    Functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.
The "Comparison to imperative programming" section[1] offers a decent example of the paradigm, but DOM manipulation in JavaScript is pretty much as imperative as it gets. Having functions is necessary, but not sufficient, for functional programming.

[1]: https://en.wikipedia.org/wiki/Functional_programming#Compari...


Hate to pile on, but this is absolutely not the definition of functional programming.

Functional programming uses stateless, immutable transformations to contorl data flow. The second you instantiate an object with some internal properties that change in memory, you are no longer programming functionally


Some of those examples aren't really equivalent. If you use that vanilla js way to show/hide, it won't restore the display property to the value it was before using hiding. It will just shift it between display: "none" and display: "". If you need something to be a display: "inline-block", the vanilla js example will lose that and break your styling.

You can modify the code to set the display property as inline-block, but now you need a different show function for every possible display value you want to restore. Or you need to build a layer of state to remember what the original value was and hey you've rewritten the jquery version.

And this is all ignoring that the jquery versions just look so much simpler to remember and are cleaner to read.


Except you can do this:

```css .hide { display: none important!; } ```

```js function hide(el) { el.classList.add('hide'); } ```


LMFAO every example of "modern" looks like a course in how not to design an API, etc. The jQuery examples are so clean and expressive. Imagine landing on a page like that and thinking, "hey, that 'modern' option looks good." You'll end up with 28KB (jQuery gzipped size) of just extra syntax before you're done with your app, not to mention the additional 160 hours of work.

You'll likely be adding 6-700KB of React and its ilk anyway (I see it in every project now).


The code I write these days is cleaner and more readable than anything I did back in the jQuery days. The only thing I add (for bigger projects) is Typescript.

With jQuery it feels like a lot of functionality is hidden away, which can lead to unexpected situations that are harder to debug.

In my experience writing vanilla code takes less time, not more, because I have a better grip on what is happening.


[flagged]


Just in case this comment gets flagged, here is the original text:

---

Sigh. There are people who cannot program and fortunately for those people there is jQuery. Writing any kind of UI in vanilla JS is trivial and even more so with TypeScript. If that takes you a 160 hours to complete you are not the guy to be doing that work. I could pay my pest control guy to figure it out. Maybe it might take him 160 hours.

JQuery used to make sense back in the days of IE, especially before IE9, and your team was green. Even then most cross browser issues were in CSS, not JS. Those days are long gone.


oh the arrogance! love it this is why I read the comments on hacker news before (or mostly in place of) the article :P


> Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins"

The great things about these plugins is that you can strip them down to what you need and patch them yourself (remember lib or vendor directory). NPM and build tools make this a chore.


Stripping them down is work, especially with the type of code that can often be found in random jQuery plugins.

It could be argued that avoiding unnecessary work is my main job function. It's a lot more efficient to just get something that already does what I need, without requiring patches. In my experience leaving the jQuery ecosystem made this a lot easier.


"I don't really understand why so many people still use jQuery at all."

Because it has a beautifully designed API. I don't directly use jQuery usually anymore. But I use the API in a basic DOM wrapper I've written. https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...


> https://youmightnotneedjquery.com/

I'm convinced this site is actually satire and it designed to promote jQuery. In nearly every example, the native version is far more verbose.


It's just a random site I remembered from a long time ago, there are better ones out there. One of them convinced me that jQuery is just a crutch. I tried a small project without it and it really did not take long to adjust.

These days I find vanilla far easier to read and it is a lot more clear to me what is actually happening in the code.

Depending on jQuery limits your ability to work with code that does not use it. Ie a lot of the more professional libraries.

For me dropping jQuery feels like a step up. Why don't you just try it, see what happens. It's just a day of being a little bit annoyed and then you should be fine.


FWIW, I'm not a front-end developer. I've had to do some over the years, but it's certainly not my area of expertise (I work in AppSec), so my opinion is worth very little.

jQuery might be a crutch, sure, but I'm not sure crutches are a bad thing. There's no reason to make something harder than it has to be. I just like how some things take far fewer key stroke and are less verbose, but still readable.

Readability is subjective. There are people that think Perl is fine and I think it ranks as one of the least readable languages to ever reach popular status. Meanwhile, I think Python is the most readable language to have ever been created, and somehow some people struggle with it, and tbh it kind of blows my mind.


your link actually convinced me that jQuery is a much better alternative to vanilla js.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

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

Search: