7 ms·

I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "va

I'm heavily inclined to agree with this. In fact, only this weekend I was working on a very simple one page tool and from the get-go I decided to adopt this "vanilla" only approach, i.e no JS libraries really at all. Pretty quickly I found myself wishing I had just used jQuery or at least some other library to make stuff easier and get things done faster. When I finally got it completed in the end I wasn't sure why I bothered to struggle and waste so much time instead of just including jQuery and making things a bunch easier and less verbose. Sure, there may be other libraries worth using instead but the point against the "vanilla JS is all you need" argument. I actually found the cited website in this post http://youmightnotneedjquery.com http://youmightnotneedjquery.com to be so strange as examples of why you may not need jQuery that it may be satire. I was surprised to find out that it was not satire. So I actually forked it and created https://youmightneedjquery.com https://youmightneedjquery.com, on which I may change some text in the future. It may not load for you yet as the DNS propagates. You can find the fork on my Github account here: https://github.com/JaTochNietDan/youmightnotneedjquery https://github.com/JaTochNietDan/youmightnotneedjquery I'll make some changes later to show the satirical nature of it.

paradoja 7y ago
Getting a > Error code: SSL_ERROR_BAD_CERT_DOMAIN trying to access https://youmightneedjquery.com https://youmightneedjquery.com .
- JaTochNietDan 7y ago
  The Github certificate takes a while to sign so I've turned off enforcement for the time being :).
lampe3 7y ago
So what was the struggle with vanilla js? I'm just curious :) One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.
- skizm 7y ago
  Not really a struggle, but why would you want to type ten lines when two will do?
  - JaTochNietDan 7y ago
    This is exactly it summarised. It's more frustration at the extra verbosity I had to put in to do something I'd become so accustomed to doing in a line or two.
  - RodericDay 7y ago
    what examples do you have in mind?
  - akmittal 7y ago
    Isn't that different reduced a lot with ES6+? By adding jQuery load time increase by almost a second or two
    - dmitriid 7y ago
      > Isn't that different reduced a lot with ES6+? ES6+ does not replace browser APIs. There's no ES6+ way around this: const el = document.createElement(...) el.setAttribute(...) el.classList.toggle(...) const parent = document.getElementById(...) parent.appendChild(el) You either do that in one line of jQuery, or end up writing your own wrappers if you need to do this more than once.
      - 52-6F-62 7y ago
        I personally prefer what you just outlined over jQuery. It's more explicit—that will almost always win with me.
        dmitriid 7y ago
        That was simplified code to create just one element and add it to the DOM. Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.
austincheney 7y ago
Struggle with vanilla JS is my inspiration for writing this, which was up voted 20 times: https://news.ycombinator.com/item?id=19946032 https://news.ycombinator.com/item?id=19946032
- JaTochNietDan 7y ago
  I don't disagree that you should know core concepts of what you're writing. I write a lot of Go without any heavy abstraction libraries (i.e ORMs) and have done with others like PHP in the past too. With abstraction there has to be a balance though. Sure, I concede that knowing how it works is actually important, hence why I've spent a lot of time doing things without libraries in the past, especially as I was learning. It actually enrages me when people who've only ever used ORMs make super basic mistakes when writing and executing SQL themselves for the first time, i.e selecting a bunch of relationships in a loop one by one, instead of getting them all in one query. Stuff like that is a good example of how only ever working with abstracted versions of your tech stack results in mistakes down the line that have costs, since the abstracted version doesn't explain these concepts to you. However, when it comes to actually trying to get things done efficiently, abstraction can help a bunch. Writing a bunch of stuff from scratch every time is not particularly productive either.
  - austincheney 7y ago
    > Writing a bunch of stuff from scratch every time is not particularly productive either. If you were to describe that in offline terms applications would be like books and abstractions would be like parts of the books. In order to make effective use of the book you still have to read, from scratch (whatever that means). When you become well versed in reading and writing it doesn't feel like a chore and you become far more efficient at it than simply guessing at the material from selected paraphrases. Programming is no different.
    - JaTochNietDan 7y ago
      I'm not really sure what you're saying at all? It seems like we have agreed but I simply cannot comprehend your example. The point I was making is that we could all spend our time going as deep as possible with as little abstraction as possible and end up writing stuff in assembly because "it's important to know how something works". There is always a cost/benefit with abstraction when it comes to getting things done.
mgkimsal 7y ago
your link above is https://youmightneedjquery.com" https://youmightneedjquery.com" <--- quote was in the link.
- JaTochNietDan 7y ago
  Ah, I've just removed the quotes. Thanks.
indocomsoft 7y ago
You have some pretty unidiomatic JS in there. For example: Array.prototype.filter.call(document.querySelectorAll(selector), filterFn); What's more idiomatic is document.querySelectorAll(selector).filter(filterFn) The same holds for forEach. I suggest you look into how javascript prototype based OOP works
- JaTochNietDan 7y ago
  I didn't make the site, it's a fork of the original website by Hubspot.
- arp242 7y ago
  .filter() is not a method on the NodeList though, it only has forEach(), and even that is quite recent. This is why people convert it to an array, and one of many reasons the standard JS API (and the DOM one in particular) are annoying to work with.
  - 52-6F-62 7y ago
    There are still more idiomatic methods you can use, ie: [...document.querySelectorAll(selector)].filter(filterFn);
    - jrandm 7y ago
      That's a significantly newer syntax, so I wouldn't say it's "more idiomatic" than explicitly referencing the original function on the prototype (which is idiomatic to JS) and was the way to do it until the spread proposal, Array.from, and similar additions, what, ~5 years ago? If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?
      - 52-6F-62 7y ago
        In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.
saltminer 7y ago
There's a mixed-content warning because the original site doesn't have a valid HTTPS cert but yours forces HTTPS, you might want to fix that.
- JaTochNietDan 7y ago
  Fixed that and edited it up a bit.
bollockitis 7y ago
The text of You Might Not Need jQuery says the following: > 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 I am mistaken but it seems to me that this site targets library developers who use jQuery without realizing that they're forcing it on users as a transitive dependency. It does not seem to apply to end-users writing simple tools.

paradoja 7y ago

Getting a > Error code: SSL_ERROR_BAD_CERT_DOMAIN trying to access https://youmightneedjquery.com https://youmightneedjquery.com .

JaTochNietDan 7y ago
The Github certificate takes a while to sign so I've turned off enforcement for the time being :).

lampe3 7y ago

So what was the struggle with vanilla js? I'm just curious :) One of the first things I learned in web development was jquery but right now I never use it. Even if I create a vanilla html/css/js website.

skizm 7y ago
Not really a struggle, but why would you want to type ten lines when two will do?
- JaTochNietDan 7y ago
  This is exactly it summarised. It's more frustration at the extra verbosity I had to put in to do something I'd become so accustomed to doing in a line or two.
- RodericDay 7y ago
  what examples do you have in mind?
- akmittal 7y ago
  Isn't that different reduced a lot with ES6+? By adding jQuery load time increase by almost a second or two
  - dmitriid 7y ago
    > Isn't that different reduced a lot with ES6+? ES6+ does not replace browser APIs. There's no ES6+ way around this: const el = document.createElement(...) el.setAttribute(...) el.classList.toggle(...) const parent = document.getElementById(...) parent.appendChild(el) You either do that in one line of jQuery, or end up writing your own wrappers if you need to do this more than once.
    - 52-6F-62 7y ago
      I personally prefer what you just outlined over jQuery. It's more explicit—that will almost always win with me.
      - dmitriid 7y ago
        That was simplified code to create just one element and add it to the DOM. Once you write it not once, but twice, or five times, you will either switch to a lib/framework, or to jQuery, or will write your own wrapper not that different from jQuery.

austincheney 7y ago

Struggle with vanilla JS is my inspiration for writing this, which was up voted 20 times: https://news.ycombinator.com/item?id=19946032 https://news.ycombinator.com/item?id=19946032

JaTochNietDan 7y ago
I don't disagree that you should know core concepts of what you're writing. I write a lot of Go without any heavy abstraction libraries (i.e ORMs) and have done with others like PHP in the past too. With abstraction there has to be a balance though. Sure, I concede that knowing how it works is actually important, hence why I've spent a lot of time doing things without libraries in the past, especially as I was learning. It actually enrages me when people who've only ever used ORMs make super basic mistakes when writing and executing SQL themselves for the first time, i.e selecting a bunch of relationships in a loop one by one, instead of getting them all in one query. Stuff like that is a good example of how only ever working with abstracted versions of your tech stack results in mistakes down the line that have costs, since the abstracted version doesn't explain these concepts to you. However, when it comes to actually trying to get things done efficiently, abstraction can help a bunch. Writing a bunch of stuff from scratch every time is not particularly productive either.
- austincheney 7y ago
  > Writing a bunch of stuff from scratch every time is not particularly productive either. If you were to describe that in offline terms applications would be like books and abstractions would be like parts of the books. In order to make effective use of the book you still have to read, from scratch (whatever that means). When you become well versed in reading and writing it doesn't feel like a chore and you become far more efficient at it than simply guessing at the material from selected paraphrases. Programming is no different.
  - JaTochNietDan 7y ago
    I'm not really sure what you're saying at all? It seems like we have agreed but I simply cannot comprehend your example. The point I was making is that we could all spend our time going as deep as possible with as little abstraction as possible and end up writing stuff in assembly because "it's important to know how something works". There is always a cost/benefit with abstraction when it comes to getting things done.

mgkimsal 7y ago

your link above is https://youmightneedjquery.com" https://youmightneedjquery.com" <--- quote was in the link.

JaTochNietDan 7y ago
Ah, I've just removed the quotes. Thanks.

indocomsoft 7y ago

You have some pretty unidiomatic JS in there. For example: Array.prototype.filter.call(document.querySelectorAll(selector), filterFn); What's more idiomatic is document.querySelectorAll(selector).filter(filterFn) The same holds for forEach. I suggest you look into how javascript prototype based OOP works

JaTochNietDan 7y ago
I didn't make the site, it's a fork of the original website by Hubspot.
arp242 7y ago
.filter() is not a method on the NodeList though, it only has forEach(), and even that is quite recent. This is why people convert it to an array, and one of many reasons the standard JS API (and the DOM one in particular) are annoying to work with.
- 52-6F-62 7y ago
  There are still more idiomatic methods you can use, ie: [...document.querySelectorAll(selector)].filter(filterFn);
  - jrandm 7y ago
    That's a significantly newer syntax, so I wouldn't say it's "more idiomatic" than explicitly referencing the original function on the prototype (which is idiomatic to JS) and was the way to do it until the spread proposal, Array.from, and similar additions, what, ~5 years ago? If anything isn't that code _less_ idiomatic in that it's less specific to JS and more of a generic operation?
    - 52-6F-62 7y ago
      In this instance I understood it to be idiomatic as it calls a JS Array constructor and iterates on the passed parameter to create it. It's been more common than the call/apply methods for years—at least as far as I've seen. The use of the array literal is always preferred, AFAIU.

saltminer 7y ago

There's a mixed-content warning because the original site doesn't have a valid HTTPS cert but yours forces HTTPS, you might want to fix that.

JaTochNietDan 7y ago
Fixed that and edited it up a bit.

bollockitis 7y ago

The text of You Might Not Need jQuery says the following: > 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 I am mistaken but it seems to me that this site targets library developers who use jQuery without realizing that they're forcing it on users as a transitive dependency. It does not seem to apply to end-users writing simple tools.