5 ms·
Exactly. It was cute for a few years, but these jQuery bashing thoughtpieces are so worn out now. As React and the long tail of frameworks slides into it's twil
by dccoolgai 4y ago
Exactly. It was cute for a few years, but these jQuery bashing thoughtpieces are so worn out now. As React and the long tail of frameworks slides into it's twilight years, it's clear in retrospect that jQuery was just a much more responsible and sound architecture (mostly because it cleaved to standards) than any of the things that spawned the 1000 "why I'm leaving jQuery for _this_" blogposts every day.
- joshstrange 4y agoI think you are conflating 2 different things. jQuery -> vanilla JS and jQuery -> framework (React/Vue/Angular/etc). Though I'm not sure where you getting the idea that JS/TS frontend frameworks are sliding into their "twilight years".
- calibas 4y agoYou can improve website performance by replacing jQuery with vanilla JS. That's a statement of fact, not a "jQuery bashing thoughtpiece". Several years ago, jQuery was practically a requirement, but now vanilla JS offers many of the same features. There's a huge amount of older websites that relied upon jQuery but don't really need it anymore.
- peterangular 4y agoEven as someone who's largely ripped out jQuery for vanilla JS I still totally understand why people use the API. Vanilla JS is terse comparative to jQuery short-hand syntax, especially for simple event bindings. Sure, I think jQuery these days is largely legacy developer ergonomics... I admit there are parts of those ergonomics that I miss. Especially when comparing it to modern tool-heavy transpiled/compiled/whatever JS development which is way more opinionated than using a simple utility library.
- zerocrates 4y ago> Vanilla JS is terse comparative to jQuery short-hand syntax, especially for simple event bindings. You mean "verbose" here, probably?
- peterangular 4y agoAh yea you're right - I misspoke. Vanilla JS feels verbose, and jQuery feels more terse in regards to general syntax. --- document.querySelector('#sel').addEventListener('click', (e) => {}) Feels way more verbose than the following: $('#sel').on('click', (e) => {}) My bad - apparently the coffee hadn't sunk in yet ha.
- 6510 4y agoOT note: sel.onclick=e=>{} works just fine. https://jsfiddle.net/39h5ynga/ https://jsfiddle.net/39h5ynga/
- joshstrange 4y agoBut only if you (and any libs you use) only plan on adding 1 click handler to an element. That's why I always opt for the addEventListener/on style vs setting the onclick/ondblclick/etc handlers.
- 6510 4y agotrue but I would hope the libs use the event. (one onclick is still allowed in combination) This approach seems the funniest: https://jsfiddle.net/eu60Lwv9/ https://jsfiddle.net/eu60Lwv9/
- strokirk 4y agoIt's even more verbose in a lot of common cases, actually. (Although the ? operator has made things better). --- 1. document.querySelectorAll(".sel").forEach((e) => e.addEventListener("click", (e) => {})) $('.sel').on('click', (e) => {}) 2. document.querySelector(".sel")?.addEventListener("click", (e) => {}) $('.sel').on('click', (e) => {}) 3. const e = document.createElement("div") e.className = "cls" e.setAttribute("title", "Title") e.textContent = "<Content>" const e = $('<div>').addClass("cls").attr("title", "Title").text("<Content>")
- deleted 4y ago[deleted]