You might not need jQuery (2014)

Post by robertlagrant » Thu, Jan 14, 2021, 8:48 AM UTC

arp242 wrote: post #59

onion2k wrote: post #33

Earlier quoted context omitted.

I would prefer web developers accepted they need to write a few hundred lines of 'ugly' vanilla JS to drive their website than they include a 30KB library that they only really use 0.2KB of. On the web, user experience should really be a higher priority than developer experience.

Hundreds of lines of ugly vanilla JS which duplicate jQuery features which aren't as well tested and probably don't handle all the edge cases. > On the web, user experience should really be a higher priority than developer experience. Those aren't disconnected. The more time I spend on technical implementation details, the less time I have to think about UX and/or implement things that improve UX.

Post by 3131s » Thu, Jan 14, 2021, 8:56 AM UTC

DarkWiiPlayer wrote: post #100

catmanjan wrote: post #79

Earlier quoted context omitted.

I've done this before - you just end up rewriting jQuery hehe.

You'd end up writing a subset of jQuery that only has the parts you need and skips those where you almost wouldn't gain anything.

Post by ratww » Thu, Jan 14, 2021, 9:03 AM UTC

heleninboodler wrote: post #61

jamiesonbecker wrote: post #2

It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.

> In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. "Every single example?" Are we reading the same page? I was fairly surprised to find that 75% of the alternatives are literally one-liners. There are a handful that swell up to 10-15 lines of code, but I would say it's a very small portion, far from "every single example."

Post by littlecranky67 » Thu, Jan 14, 2021, 9:06 AM UTC

csande17 wrote: post #99

acemarke wrote: post #69

Earlier quoted context omitted.

Hi, I'm a Redux maintainer. Please note that "modern Redux" code is very different than what most older tutorials show. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that provide a light abstraction to simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the traditional `connect` API. I strongly recommend reading through the newly rew…

> Hi, I'm a Redux maintainer. We've heard your complaints that Redux adds a lot of unnecessary complexity and abstraction. Please note that we've now solved this problem in typical Redux fashion: by piling on additional layers of abstraction. > Also, I am going to continue posting this same comment on every discussion about Redux over and over for the rest of my life.

Post by jarek-foksa » Thu, Jan 14, 2021, 9:11 AM UTC

arp242 wrote: post #54

bichiliad wrote: post #10

Earlier quoted context omitted.

I think a lot of the initial appeal around jQuery was that it made querying and manipulating the DOM simple. Much of its features have been replaced by broadly-available APIs like Document.querySelector and Element.classList. Loading the entirety of jQuery just to access some of the remaining features just means you're loading JavaScript that you aren't going to use. I miss relying on jQuery because it's familiar and…

I still think the jQuery API is significantly easier than the DOM one. querySelectorAll() returns this NodeList object that's much harder to use than it needs to be. Things like getting the next sibling is much harder than jQuery's .next(), etc. etc. I also don't care much for the fetch() API; I dislike promises and what does it send when you try to POST a JS object ({foo: 'val'})? [object Object]. Yeah, useful... An…