Live data from Hacker News

I loved jQuery, and still do (2019)

withblue.ink

171–180 of 189 posts

Re: I loved jQuery, and still do (2019)

#171

Earlier quoted context omitted.

That's not how I see jQuery hate. jQuery promotes bad development patterns, AND brings a cost for end users. Developers will do themselves and futures devs a favor by not choosing to use it. Is it really gatekeeping to expect people to be aware of commonly used 10 year old features? I assume developers who share YMNNJQ are just sick of inheriting messy projects built with jQuery. I know I am.

You've never inherited a terrible, unmaintainable React or Angular app? I have on multiple occasions, and in fact my team is dealing with one right now. I'd prefer a jQuery mess to an Angular/React mess any day of the week. With old-school jQuery apps, at least I can get them to build and can debug the control flow.

A couple of years ago I inherited a client's static site that was written in React before Next.js took off. It is a real accomplishment to make a static site as unnecessarily unmaintainable and convoluted as that one was.

Part of my screening process is making sure something like that doesn't fall in my lap again. Even static sites aren't safe these days.

Re: I loved jQuery, and still do (2019)

#172
jQuery is great, especially when you are low on time available and wanted to put together your product with minimal friction. VueJS, React etc. are great, but not when you have no more than 2 developers working. We are in the age of 5G internet and high bandwidth network streams, downloading a couple of hundred extra kilobytes of js files on mobile clients and desktop browsers should be no problem to at least 85% of the users.

Oh and BTW it pairs really well with StimulusJS. I've used it thoroughly and it's been a godsend

Re: I loved jQuery, and still do (2019)

#173
post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

You can just assign document.QuerySelector and document.QuerySelectorAll to $ and $$ yourself.

You can, and some JS consoles provide this for convenience if those vars are unused, but jQuery really shines with method chaining. That’s what I miss the most from it. You could manipulate the DOM in incredible ways in “one line” of code.

Re: I loved jQuery, and still do (2019)

#174

Earlier quoted context omitted.

You can just assign document.QuerySelector and document.QuerySelectorAll to $ and $$ yourself.

You can, and some JS consoles provide this for convenience if those vars are unused, but jQuery really shines with method chaining. That’s what I miss the most from it. You could manipulate the DOM in incredible ways in “one line” of code.

Depends what you want to do, but I've kind of come around because I feel like if what I want to do is so complicated that I can't easily do it in vanilla JS, it's also complicated enough that I don't necessarily want to do it by manual DOM manipulation. Changes the calculation if you have to support older browsers and such though.

Re: I loved jQuery, and still do (2019)

#175
post #45

I still use jQuery even for new projects. Yes, these days it's possible to do everything jQuery does using native JS, but I find the native version to be much more verbose and its naming conventions to be far less clear. For example, natively getting a list of children is `el.children` but natively getting the parent is `el.parentNode`, not `el.parent`. Meanwhile, natively getting a list of classes is `el.classList`,…

> but natively is the mouthful of `document.querySelectorAll('selector')` I'm curious as to whether there's a proper use case for querySelectorAll. I always use the getElementsByClassName, getElementById, and getElementsByTagName based on what I want. I find the more general querySelectorAll to be too likely to produce a bug when someone uses a CSS class name that equals a tag or ID. You can make it work, but I find…

class, id, and tag name are only a small subset of the things you can get with a css query, and you can't combine them with anything when you use the dedicated querySelector methods.

document.querySelectorAll("[data-my-attr=something]")

document.querySelectorAll(".foo > [data-my-attr=something]")

etc.

Re: I loved jQuery, and still do (2019)

#176

Earlier quoted context omitted.

You can just assign document.QuerySelector and document.QuerySelectorAll to $ and $$ yourself.

You can, and some JS consoles provide this for convenience if those vars are unused, but jQuery really shines with method chaining. That’s what I miss the most from it. You could manipulate the DOM in incredible ways in “one line” of code.

FYI chaining and a handful of the most common operations can be implemented in just a few lines of code: https://gist.github.com/paulirish/12fb951a8b893a454b32

(Although I reach for the "cash" library instead of this or jQuery when I need something jQuery like)

Re: I loved jQuery, and still do (2019)

#177

They loved it still in 2019. How about since then?

I'm the author of the post. I was not expecting this to surface out of the blue 2 years later, so I had to go back and re-read what I wrote I still stand behind what I wrote for the most part. If what you are looking for is not building a full SPA and you need compatibility with most browsers, for most users, then jQuery is still a very solid alternative. A few things have changed however since then: - As others have…

Right, not expecting this to surface out of the blue 2 years later, OP.

Thanks for the addition insights anyways

Re: I loved jQuery, and still do (2019)

#178

Earlier quoted context omitted.

I don't use Django but I use Ruby on Rails, and turning a server-side rendered page into an API is trivial. Rails requests automatically understand the format of a request and let you specify what do when a specific kind of format comes in: ie. when it's an html request, render this page, when it's a "js" request, render a jbuilder template. ezpz whatever frontend framework you're using has really nothing to do with…

Confirmed this is also trivial with Django, have done it to my crud, and even have a view that parses my url router for views and return an openapi definition with a swagger ui.

Do you use Django REST Framework with Web Swagger Console UI?

Re: I loved jQuery, and still do (2019)

#179
post #22

Earlier quoted context omitted.

If jQuery helps the developer achieve their design and development goals, that will play out better for the end-user. That's not the dilemma though. Developer can build solutions without jQuery. They'll be faster, smaller, and have fewer dependencies. Plus, if you're only using jQuery for DOM and events then it probably isn't helping you. Those are two areas where writing vanilla JS is can often be easier than writin…

jQuery versus vanilla DOM is slower, larger, and adds dependencies. jQuery versus [framework of the month] is "faster, smaller, and [has] fewer dependencies". Simpler build, too, while still keeping you from having to worry about which browser supports what. Depends on what the most likely alternative is, then.

There are plenty of modern frameworks that are smaller than jQuery (svelte, Preact, etc). In some apps they may also be faster. If you pick svelte there's the same number of dependencies.

Re: I loved jQuery, and still do (2019)

#180

Earlier quoted context omitted.

> little bit of a facelift Proceeds to download 30kb (compressed) swiss army knife of a library when just a toothpick would do. jQuery is about as much of a gateway to ES6 as pot is to heroin. Devs who still use jQuery have had 10+ years to learn `document/element.querySelectorAll()`. Longer for event listeners.

When you learnt something with better more easily readable syntax, it's kinda hard to make yourself use something worse to save 30kb, when that saving will be lost with a single image on the page you're loading...

Incidentally, there's a few lightweight jQuery-likes you can use if you just want a nicer syntax. Zepto and umbrella are popular.
Post reply on HN