8 ms·

I was one of the developers who made http://youmightnotneedjquery.com http://youmightnotneedjquery.com. To be fair, we made it in... 2014? There is a lot you ca

I was one of the developers who made http://youmightnotneedjquery.com http://youmightnotneedjquery.com. To be fair, we made it in... 2014? There is a lot you can do now which you couldn't do then, just with a browser. A lot of the challenging examples, like animation, you're better off doing with straight CSS. Ultimately, I haven't actually used jQuery for anything serious in half a decade, and somehow I manage.

sbjs 8y ago
I kind of imagine we will one day have a basic poly fill for all the cross platform issues jQuery actually excels at, and then we truly won’t need jQuery since that’s all it’s really good at these days. Things like chaining are an anti pattern and lead to brittle code!
- brailsafe 8y ago
  I think those are some broad generalizations that I can't agree with, but Sizzle might be what you're looking for. https://github.com/jquery/sizzle/wiki https://github.com/jquery/sizzle/wiki
  - floatboth 8y ago
    Sizzle is ancient history at this point. It's the selector engine jQuery used before querySelector became available everywhere.
    - brailsafe 8y ago
      Yes, that was the point. What did you think I thought Sizzle was?
      - floatboth 8y ago
        "might be what you're looking for", when that person was looking for a "basic poly fill for all the cross platform issues jQuery actually excels at"
        brailsafe 8y ago
        Exactly rice. A possible answer to a somewhat ambiguous desire.
- emodendroket 8y ago
  I don't think I can agree with that idea about chaining.
- Piskvorrr 8y ago
  Oh, but we already do have that, over there: https://jquery.com/ https://jquery.com/ What's with the trend "jQ is old, old is bad! We need something that does the same thing, and most importantly is not named jQuery"?
  - AmericanChopper 8y ago
    Most DOM manipulation in jQuery goes through jQuery.globalEval, which uses eval(). Meaning if you want to have a CSP, you have to allow unsafe-eval if you need to support jQuery. CSP is an incredibly useful tool, and it’s close to impossible to use it properly with jQuery.
    - lmm 8y ago
      First concrete, legitimate reason I've seen all thread. Is there something fundamental about jQuery's design that forces it to use eval(), or is it possible a new version could avoids that?
      - AmericanChopper 8y ago
        Performing evals is a core part of the design. Take a look at the additional notes section on this documentation of the .html method. http://api.jquery.com/html/ http://api.jquery.com/html/ >By design, any jQuery constructor or method that accepts an HTML string — jQuery(), .append(), .after(), etc. — can potentially execute code This makes jQuery less safe in general, but I think the CSP restrictions this puts in place are probably a greater issue for most people. I’ve been involved in retro-fitting strict CSPs into a few projects, and more than once I’ve been thwarted by very minor use of jQuery in a couple of places.
        sbjs 8y ago
        It's part of the design of the creation of new elements. But that's just one part of jQuery, and a part I would be completely okay with jQuery getting rid of.
sgift 8y ago
> Ultimately, I haven't actually used jQuery for anything serious in half a decade, and somehow I manage. I don't understand that sentiment ... Of course you can "manage" without JQuery. JQuery itself doesn't use JQuery (D'oh) and somehow it can do all these things, so it is possible. The point of JQuery is that I don't have to think about the various (slightly) incompatible implementations of <whatever> in each browser version, but can just use one lib call and be done with it. JQuery to me is like using a car instead of running to another city. Yes, I could run, but why would I do that ..?
- dangerface 8y ago
  > The point of JQuery is that I don't have to think about the various (slightly) incompatible implementations Sure when jQuery was released in 2006, but browsers have had 12 years to improve their compatibility, and they have. Javascript has also had 12 years to improve and simplify its api, and it has. Your analogy was perfect for jQuery 2006 but in 2018 its more like buying a car to drive around the city or you can just take an Uber, you don't have to walk anymore.
  - pjmlp 8y ago
    Tell that to those enterprise customers holding to IE 11, not allowing Chrome and doing their own timely releases of FF ESR.
    - GordonS 8y ago
      Where I work we only just upgraded to IE11 - it was a decent-sized project, involving a lot of people and manhours. I really wish we'd of just ditched it and moved to Chrome or Firefox :(
      - Spivak 8y ago
        So you would have a decent sized project involving lots of people and manhours, but without support from your vendor?
lewisjoe 8y ago
It is not about the possibility. We can achieve anything with native browser's APIs without custom/polyfill layers these days. Point is: $('#somediv').removeClass('class-to-be-removed') is so much better than document.querySelector("#somediv").className = document.querySelector("#somediv").className.replace(/\class-to-be-removed\b/,'');
- masklinn 8y ago
  Broadly speaking I agree with you, but even IE11 supports classList so the "native" version of your bit is really document.getElementById('somediv').classList.remove('class-to-be-removed') Where the native APIs fall down is that 1. they tend not to be chainable/expression-oriented, you can't just `classList.add('foo').remove('bar').toggle('qux')` because the first two methods return `undefined` and the last one a boolean 2. they don't support set-oriented operations at all, it's a chore of manual iterations
  - lewisjoe 8y ago
    Spot on! Those are probably the two most important blunt-sides of native APIs. The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days" I'd be happy if there's a jquery like polyfill library for DOM manipulation, but again - why not just custom jQuery builds and sizzle.js instead of re-inventing jQuery? P.S I'm not sure IE11 supports classList. Source: https://developer.mozilla.org/en-US/docs/Web/API/Element/classList https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
    - megous 8y ago
      IE11 supports classList just fine, except for an argument to toggle. Nothing a little DOMTokenList.prototype change can't fix. > The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days" That will only happen if you're incompetent and will not write a few simple helper functions. And probably not even then. Plain DOM API is not that verbose over jQuery. Anyway, just look at what subset of jQuery you use the most and write helpers for that. Your codebase is already grown by 1000s of lines by using jQuery, so you have quite a head start sizewise if you drop jQuery.
deleted 8y ago
[deleted]
EnderMB 8y ago
Haha, I remember when that site was released, and a few of our developers jumped right on it without actually reading the text - namely the second paragraph. > If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with. Back then, you were 100% correct that if you were writing a library that you intend to use in other places, having jQuery as a hard requirement was a bad idea. However, one developer managed to convince their PM's to completely strip out jQuery for an upcoming project, despite the fact that this website was for a major charity that had huge accessibility requirements AND required legacy browser support. The devs on that project learned a ton about vanilla JS, but that project was an absolute disaster. We did get a solid library out of it, though, and at least that didn't have jQuery as a dependency!
- thomasfedb 8y ago
  It is a little irritating when libraries that really shouldn't need jQuery had it as a dep. I don't mind using jQuery, but I'd rather not add it to a project just as a dep.
  - EnderMB 8y ago
    Absolutely. In the case of libraries it was absolutely solid advice. Sadly, a lot of people didn't actually read the site, and they decided that jQuery was evil and shouldn't be used on websites at all.
- zamber 8y ago
  That's more telling about problematic mechanics in your org than about jQuery itself. Did that convincing developer have more influence than the rest of the team? Why the PM was involved in implementation minutiae? From what I've seen people tend to complain about office politics usually when they don't grok them. The not grokking part is often a choice stemming from a conviction that code monkeys > managers because "engineering". Following your example, who then has more influence over technical decisions? (at least in your somewhat disfunctional org?)
Cthulhu_ 8y ago
Is it time to make that site open source and update it, then? Maybe make a version that targets IE 11+ or even discards Edge, that way you can show promises / async/await for just the ajax one, as well as the straight CSS solutions.
- realityking 8y ago
  It is open source. Repo: https://github.com/HubSpot/YouMightNotNeedjQuery https://github.com/HubSpot/YouMightNotNeedjQuery License is MIT. Unfortunately it seems to be unmaintained.
jdboyd 8y ago
It would be cool if that website was updated then.
EB66 8y ago
FWIW, a few of the non-jQuery alternatives documented on http://youmightnotneedjquery.com http://youmightnotneedjquery.com are not equivalent -- they lack some of the functionality that jQuery offers. For example, take a look at $.replaceWith(). If you use $.replaceWith() you can supply an element that has event handlers bound to it and those event handlers will persist after the replacement. But in your alternative code ( el.outerHTML = string; ) you can only pass in a string which of course cannot have event handlers bound to it.

sbjs 8y ago

I kind of imagine we will one day have a basic poly fill for all the cross platform issues jQuery actually excels at, and then we truly won’t need jQuery since that’s all it’s really good at these days. Things like chaining are an anti pattern and lead to brittle code!

brailsafe 8y ago
I think those are some broad generalizations that I can't agree with, but Sizzle might be what you're looking for. https://github.com/jquery/sizzle/wiki https://github.com/jquery/sizzle/wiki
- floatboth 8y ago
  Sizzle is ancient history at this point. It's the selector engine jQuery used before querySelector became available everywhere.
  - brailsafe 8y ago
    Yes, that was the point. What did you think I thought Sizzle was?
    - floatboth 8y ago
      "might be what you're looking for", when that person was looking for a "basic poly fill for all the cross platform issues jQuery actually excels at"
      - brailsafe 8y ago
        Exactly rice. A possible answer to a somewhat ambiguous desire.
emodendroket 8y ago
I don't think I can agree with that idea about chaining.
Piskvorrr 8y ago
Oh, but we already do have that, over there: https://jquery.com/ https://jquery.com/ What's with the trend "jQ is old, old is bad! We need something that does the same thing, and most importantly is not named jQuery"?
- AmericanChopper 8y ago
  Most DOM manipulation in jQuery goes through jQuery.globalEval, which uses eval(). Meaning if you want to have a CSP, you have to allow unsafe-eval if you need to support jQuery. CSP is an incredibly useful tool, and it’s close to impossible to use it properly with jQuery.
  - lmm 8y ago
    First concrete, legitimate reason I've seen all thread. Is there something fundamental about jQuery's design that forces it to use eval(), or is it possible a new version could avoids that?
    - AmericanChopper 8y ago
      Performing evals is a core part of the design. Take a look at the additional notes section on this documentation of the .html method. http://api.jquery.com/html/ http://api.jquery.com/html/ >By design, any jQuery constructor or method that accepts an HTML string — jQuery(), .append(), .after(), etc. — can potentially execute code This makes jQuery less safe in general, but I think the CSP restrictions this puts in place are probably a greater issue for most people. I’ve been involved in retro-fitting strict CSPs into a few projects, and more than once I’ve been thwarted by very minor use of jQuery in a couple of places.
      - sbjs 8y ago
        It's part of the design of the creation of new elements. But that's just one part of jQuery, and a part I would be completely okay with jQuery getting rid of.

sgift 8y ago

> Ultimately, I haven't actually used jQuery for anything serious in half a decade, and somehow I manage. I don't understand that sentiment ... Of course you can "manage" without JQuery. JQuery itself doesn't use JQuery (D'oh) and somehow it can do all these things, so it is possible. The point of JQuery is that I don't have to think about the various (slightly) incompatible implementations of <whatever> in each browser version, but can just use one lib call and be done with it. JQuery to me is like using a car instead of running to another city. Yes, I could run, but why would I do that ..?

dangerface 8y ago
> The point of JQuery is that I don't have to think about the various (slightly) incompatible implementations Sure when jQuery was released in 2006, but browsers have had 12 years to improve their compatibility, and they have. Javascript has also had 12 years to improve and simplify its api, and it has. Your analogy was perfect for jQuery 2006 but in 2018 its more like buying a car to drive around the city or you can just take an Uber, you don't have to walk anymore.
- pjmlp 8y ago
  Tell that to those enterprise customers holding to IE 11, not allowing Chrome and doing their own timely releases of FF ESR.
  - GordonS 8y ago
    Where I work we only just upgraded to IE11 - it was a decent-sized project, involving a lot of people and manhours. I really wish we'd of just ditched it and moved to Chrome or Firefox :(
    - Spivak 8y ago
      So you would have a decent sized project involving lots of people and manhours, but without support from your vendor?

lewisjoe 8y ago

It is not about the possibility. We can achieve anything with native browser's APIs without custom/polyfill layers these days. Point is: $('#somediv').removeClass('class-to-be-removed') is so much better than document.querySelector("#somediv").className = document.querySelector("#somediv").className.replace(/\class-to-be-removed\b/,'');

masklinn 8y ago
Broadly speaking I agree with you, but even IE11 supports classList so the "native" version of your bit is really document.getElementById('somediv').classList.remove('class-to-be-removed') Where the native APIs fall down is that 1. they tend not to be chainable/expression-oriented, you can't just `classList.add('foo').remove('bar').toggle('qux')` because the first two methods return `undefined` and the last one a boolean 2. they don't support set-oriented operations at all, it's a chore of manual iterations
- lewisjoe 8y ago
  Spot on! Those are probably the two most important blunt-sides of native APIs. The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days" I'd be happy if there's a jquery like polyfill library for DOM manipulation, but again - why not just custom jQuery builds and sizzle.js instead of re-inventing jQuery? P.S I'm not sure IE11 supports classList. Source: https://developer.mozilla.org/en-US/docs/Web/API/Element/classList https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
  - megous 8y ago
    IE11 supports classList just fine, except for an argument to toggle. Nothing a little DOMTokenList.prototype change can't fix. > The last thing I'd want to see is a codebase going from 40 lines of code to 400 lines, because "hey, we removed jQuery and writing verbose js is the new cool these days" That will only happen if you're incompetent and will not write a few simple helper functions. And probably not even then. Plain DOM API is not that verbose over jQuery. Anyway, just look at what subset of jQuery you use the most and write helpers for that. Your codebase is already grown by 1000s of lines by using jQuery, so you have quite a head start sizewise if you drop jQuery.

deleted 8y ago

[deleted]

EnderMB 8y ago

Haha, I remember when that site was released, and a few of our developers jumped right on it without actually reading the text - namely the second paragraph. > If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with. Back then, you were 100% correct that if you were writing a library that you intend to use in other places, having jQuery as a hard requirement was a bad idea. However, one developer managed to convince their PM's to completely strip out jQuery for an upcoming project, despite the fact that this website was for a major charity that had huge accessibility requirements AND required legacy browser support. The devs on that project learned a ton about vanilla JS, but that project was an absolute disaster. We did get a solid library out of it, though, and at least that didn't have jQuery as a dependency!

thomasfedb 8y ago
It is a little irritating when libraries that really shouldn't need jQuery had it as a dep. I don't mind using jQuery, but I'd rather not add it to a project just as a dep.
- EnderMB 8y ago
  Absolutely. In the case of libraries it was absolutely solid advice. Sadly, a lot of people didn't actually read the site, and they decided that jQuery was evil and shouldn't be used on websites at all.
zamber 8y ago
That's more telling about problematic mechanics in your org than about jQuery itself. Did that convincing developer have more influence than the rest of the team? Why the PM was involved in implementation minutiae? From what I've seen people tend to complain about office politics usually when they don't grok them. The not grokking part is often a choice stemming from a conviction that code monkeys > managers because "engineering". Following your example, who then has more influence over technical decisions? (at least in your somewhat disfunctional org?)

Cthulhu_ 8y ago

Is it time to make that site open source and update it, then? Maybe make a version that targets IE 11+ or even discards Edge, that way you can show promises / async/await for just the ajax one, as well as the straight CSS solutions.

realityking 8y ago
It is open source. Repo: https://github.com/HubSpot/YouMightNotNeedjQuery https://github.com/HubSpot/YouMightNotNeedjQuery License is MIT. Unfortunately it seems to be unmaintained.

jdboyd 8y ago

It would be cool if that website was updated then.

EB66 8y ago

FWIW, a few of the non-jQuery alternatives documented on http://youmightnotneedjquery.com http://youmightnotneedjquery.com are not equivalent -- they lack some of the functionality that jQuery offers. For example, take a look at $.replaceWith(). If you use $.replaceWith() you can supply an element that has event handlers bound to it and those event handlers will persist after the replacement. But in your alternative code ( el.outerHTML = string; ) you can only pass in a string which of course cannot have event handlers bound to it.