[emirb]

http://youmightnotneedjquery.com/

[cyphar]

To me, all of the JQuery examples are much nicer to read and write. Sure, you can use raw JS, but why copy annoying boilerplate? (I'm not a JS dev, so I don't have a dog in this fight).

[inopinatus]

The authors of that page seem to be making their suggestions principally for library authors, to avoid an otherwise unnecessary dependency on jquery.

[andybak]

That page does an excellent job of convincing me to carry on using jQuery.

  if (el.classList)
    el.classList.contains(className);
  else
    new RegExp('(^| )' + className + '( |$)', 'gi').test(el.className);

vs

  $(el).hasClass(className);

<shivers>

[oneeyedpigeon]

I don't think anyone would suggest you write all of the first codeblock every time you want to check a class. You'd put it in a function and call that, much like jquery does.

The point is that this site explains how you do it because a) that's probably easier than trawling through the jquery source b) including this polyfill when you know you need it might save you from requiring all the rest of jquery.

[andybak]

In that case I'd be much more likely to use a minimal jQuery replacement such as umbrella.js mentioned elsewhere here. That's 3k (vs about 28k for jQuery) so counters most of the 'bloat' objections with jQuery. I'm sure it will still irk some some purists on other grounds however.

[edgarvaldes]

Yep, the use of RegExp is enough.

[Cyph0n]

Is that comparison supposed to show that jQuery is bad or what exactly? Because it's clear that jQuery is much more concise in every single case.

[inopinatus]

No. That site is giving helpful alternatives so that library authors can avoid having jquery as a dependency.

[Touche]

They are just recreating jQuery, no?

[qiller]

Greenspun's tenth rule of js apps?

[Drakim]

You aren't recreating jQuery by using basic JavaScript syntax.

[leviathan]

isn't JavaScript what jQuery is written with?

[Twirrim]

Yes, but why drag in 30k of additional library unnecessarily?

Yes use jQuery if it's really providing benefit, but if you're only using it for a few things, you may be better off just doing in in plain javascript, even if it's a bit longer.

Every library you add has an overhead cost on the end user as they have to fetch it and process it. It's easy to lose track of that when you're developing and testing against local webservers or on computers vs mobile, but there is strong value in keeping things small and with as few unnecessary dependencies as possible :)

[Touche]

Not sure if you read the page, but many of the examples are not "basic JavaScript syntax", the fadeIn approach is a function that attempts to replicate jQuery's, probably poorly.

[Drakim]

No, jQuery did not invent the concept of fading in. It doesn't even have a unique implementation of it, it just does a few CSS changes that you can easily do without jQuery to get the exact same result.

This is as ridiculous as having a "addition" module in jQuery and saying that people who do addition in JavaScript are just reinventing jQuery.

Wrapping jQuery around something simple (like fading in) does not make it into jQuery. If anything this just demonstrates who incredibly unknowledgeable people are about where jQuery ends and JavaScript begins.

[starquake]

The reason the site exists is explained on the site itself.

[eng_monkey]

A good example of why I will continue using jQuery for the time being.

[j1vms]

Yes, but it's always good for us to remember that everything has a cost, and so does jQuery (memory footprint/new dependency/complexity). It's a conscious decision we should make on every project, and yes in most cases it would take 0.5s to make a decision in jQuery's favor. We should do so anyways, since it's good practice. Taking into account the presumed state of Moore's Law and all.

[mhd]

I'm surprised that there's no youmightnotneedprintf.com

[jjnoakes]

I'm surprised you are comparing jQuery (a non-trivial additional dependency with reasonable dependency-less alternatives) to printf (a small piece of a dependency you most likely pull in already with).

[mhd]

One man's trivial is another man's bother. I consider 30k (less than some images or the rather popular fonts) to be quite trivial for most purposes, and if it gives me a nicer syntax for common operations, it's probably worth it.

On the other hand, I've seen actual backlash against printf implementations in libs and the bloat they're causing, never mind potential bugs [1].

So there you go.

[1]: https://www.fefe.de/dietlibc/FAQ.txt

[jjnoakes]

I'm not advocating for or against jQuery or printf. I'm just pointing out that equating the two (in size, utility, or potential gains by avoiding them) doesn't make a lot of sense.

jQuery's ratio of size-versus-additional-utility is much larger than printf's, even more so if you consider typical use cases of each.

But it isn't even a fair comparison to begin with. How about comparing jQuery to libc. I'd still argue the ratio is in libc's favor, but no one would have written "I'm surprised that there's no youmightnotneedlibc.com".

[mhd]

libc seems much more substantial, maybe we can split the difference and call it "youmightnodneedstdio.com", although that sounds much less pithy.

I still wouldn't be so sure about that ratio. The people decrying the printf family of functions are often targeting small statically linked binaries. Where a few kb shaved off might be a bigger chunk than 30kb are for your usual multi-megabyte front page of today's web.

[jjnoakes]

People who target tiny static binaries are by far in the minority of libc users.

[arethuza]

Isn't it more like comparing jQuery with libc?

[jjnoakes]

It would have been if he said "I'm surprised that there's no youmightnotneedlibc.com".

As soon as you do that though (put the two on equal-ish grounds), you realize it doesn't make much sense and it might as well not have been written in the first place.

[mikegerwitz]

libc would be more like the standard DOM specification.

printf is a part of the standard C library.

[Shengbo]

I don't think it's a question of necessity, it's just more convenient and usually a lot less code than doing the same thing without it.