Last Week I Wrote Some jQuery (and no one fired me 🤓)

Short disclaimer - Yes. The title of this post is a bit of a clickbait. Not 100%, but you can definitely read it as one. I’m not your standard full-time employee, so it’s gonna be a bit hard to fire me, but I still decided to write some jQuery code, and everyone was happy with it.

So, let’s rewind a bit

I started using jQuery ~15 years ago (around the time it was released). It was the “go-to” for everything you needed to do, and I think it’s safe to assume that almost every website back in the day included the <script src="jquery.js"></script> line in it. It was even before the days of cdnjs (where the standard for using jquery became <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.0/jquery.min.js" integrity="sha512-894YE6QWD5I59HgZOGReFYm4dnWc1Qt5NtvYSaNcOP+u1T9qYdvdihz0PPSiiqn/+/3e7Jo4EaG7TubfWGUrMQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script> and all javascript content was served directly from the websites you built without using any cdn).

jQuery was used originally to make it easy for developers to write code that just works. Unlike today, back in the day browsers had different standards and in order for your code to run smoothly (or just work?) on different browsers - there were many things you needed to learn and remember how to do, and some of the standard things that we have today (document.querySelector) weren’t available (or didn’t work as expected). Using jQuery provided a very easy and standard way to access elements (DOM manipulation), work with events and know that everything will work, regardless of the browser your users used to access your website.

Photo by @Pexels

jQuery UI

Following the wide usage of jQuery - another lib was released, called jQuery-UI. According to the website:

jQuery UI is a curated set of user interface interactions, effects, widgets, and themes built on top of the jQuery JavaScript Library.

Some of the features that jQuery-UI provides are easy to use APIs for draggable elements, which are super easy and can save us a lot of time if we need to handle everything that is related to drag&drop.

Back To Last Week

So last week I needed to create the following interface:

1. A simple page that shows a container (a rectangle with some background image).
2. Inside the container we need to display circles (we have a list of the x/y position of each circle).
3. Each circle can be dragged, but only on the Y-axis.
4. The dragging/dropping can be only inside the container.
5. When finished - we need to save (console.log, for now) the new positions of the circles.

Since it was a POC I decided it’s best to do “quick-n-dirty” work with jQuery, which eventually took ~3 hours. The jQuery-UI lib with the draggable API saved me a lot of time, and since it was a POC I didn’t really care if it would be written using some up-to-date framework (react/vue).
One of the nice things about the draggable API of jQuery-UI is that the axis (which gave me a quick solution for the Y-axis only dragging) and the containment (which provides a way to hold the dragged circles inside the container):

$("#container span").draggable({
  axis: "y",
  containment: "parent",
  ...
})

The final version also contains an option to upload the image/the dataset (the positions of the circles) and a few more things, but for this post I included this version of the code.

Summary

Working with jQuery might not be the first choice of most people (and probably also not my first choice for most projects), but it really depends on which project you are currently working on. Yes, sometimes it’s better to just write vanilla javascript, and in case you need something that is a bit more than ~20-30-40 lines of code and is more complex - it’s probably better to use one of the standard and up-to-date frameworks, but you shouldn’t be afraid to use everything that you have in your disposable to provide fast solutions.

Thinking about what someone will do with your code is not something you should ignore, but if you work on something that is only a POC and you just need to understand if there is a future for that code and someone will actually use it - before over engineer and start a project that will take a week - it’s ok to do something that is “quick and dirty” just to get a feeling and understand how and what to do from here.

---

_{Cover photo by Markus Winkler @ pixabay}

Comments

[Dekel]

What's your "go-to" when you need to do a quick POC? Do you always start a new project with one of the modern frameworks, or do you go back to jquery from time to time?

[artydev]

:-) There is a whole world between JQuery and Hyped Frameworks.
Look at this one DML the new JQuery :-)

Regards

[Dekel]

Thanks for your reply! I will definitely check it out 😀.

[bigbott]

ExtJs. AKA Yahoo UI. It is as far from jQuery as it can be.

[Emmanuel Barroga]

By POC do you mean proof of concept? Sorry, I'm terrible with acronyms, lol..... but I usually stick it in my "Test" create-react-app generated application.

[Tal]

Indeed, that's what PoC stands for :)

[Cornelia]

For me, if I it's too complex to do it quickly/easily with vanilla JS, I usually try and use whatever technology it should be written in later, and if that's not decided/known yet, I'd use svelte.
I like to use the framework it should end up in to increase the chance of discovering unexpected complications that come with a certain framework choice.

It's been so long since I've used any form of jQuery that it would probably take longer using it because I would most likely end up looking everything up again in the documentation. ^^'

[Dekel]

Eventually it's a question of time. If it's a PoC and you just wanna make sure it works - use what ever language/tool/framework/lib that you can in order to finish it and make sure it works as you expect.

[AlixaProDev]

hhahah this was fun. thanks for the post.

[Dekel]

Thanks @hazratalibit !

[Joseph Mania]

Thanks lol

[Bernd Wechner]

For the record, I have no problem with you or anyone using JQuery. It's hellishly popular and the kind of IT snobbishness that looks down on people using stable, mature and widespread technologies rather than the best of the rest if you will, does no-one any service and damages IMHO the reputation of the snobs more than anything ;-).

Frankly the list of alternatives is huge and time consuming to research and there is a large body of developers and always will be who are looking not at the cutting edge but what the popularity of the given tools they choose to use in the wild world out there, inferring from that likely longevity and portability etc.

[Andrew Bone]

Generally if you can do it in jQuery you can do it without any libraries these days. JQuery was great when it pulled the industry forward but vanilla caught up making jQuery slow in comparison. I would never say don't use jQuery you can use React but I would say use vanilla js.

But that's just me

[Bernd Wechner]

I agree. And it would be nice to lose JQuery. But for better or for worse, its syntax for finding elements remains terser and nicer that vanilla, and well, its embedded in a lot of contexts. That is, migrating away from it involves refactoring and to be honest is generally on the todo list for the very reason you say, that vanilla JS can do most all of what it offered anyhow. But some of that refactoring requires research and reading too as JQuery did do a few things a little differently to the way ES6 for example panned out.

[Andrew Bone]

Aren't $(selector) and document.querySelector(selector) pretty much equivalent?

[Bernd Wechner]

Yes, albeit a tad more verbose. ;-)

[Dekel]

@link2twenty not exactly. Some of the selectors that jQuery support are not standard CSS3 selectors (api.jquery.com/has-selector/ for example).

[Paul Smith]

querySelector() only finds the first result.

querySelectorAll() finds all results as an array which does not support chaining. Requiring you to introduce nested loops in many cases.

$(selector) finds all results and supports chaining. Which means you can often compress 5-20 lines of vanilla JS, into one line with jQuery.

[Andrew Bone]

compress 5-20 lines of vanilla JS, into one line with jQuery.

Though not really because it's calling a whole bunch of other functions just the Dev doesn't see it but the end user feels it.

[Paul Smith]

Readibility and Performance are tradeoffs. And generally readability is actually more important.

That being said, most of the time the performance differences are under 16ms making them invisible to the user.

[Ashley Sheridan]

Yeah, I agree. While it is fewer lines of JS written by the developer, there's actually a whole lot more being pulled in by the users browser. This has several side effects:

• Their browser is downloading more data, often considerable more for the average website and use-case (e.g. where it's only used as a DOM selector). This is very noticeable for those on slower or metered connections, which a large portion of the world is on (including many parts of the USA).
• The browser ends up doing more work to parse that Javascript, which is a blocking call if not set up correctly. This can have a negative impact on the time to first paint depending on what's being done.
• Because the browser is doing more work parsing and executing the library, it actually uses more battery on devices that have one. This is most noticeable on older devices. There was an interesting study done by Stanford University of which this was a part (mobisocial.stanford.edu/papers/bon... ) which saw a 60% increase in battery consumption on some sites using Jquery.

[leob]

jQuery, yeah why not!

[xorock]

amp.reddit.com/r/ProgrammerHumor/c...
It reminded mi of the Putin meme.
BTW. I still think that event support (including namespaces and delegation) in jquery is one of the best in JS world.

[Abhinav Kulshreshtha]

For quick prototyping, Alpine.js is kind of a modern day jquery. I prototype the interactions using alpine, then once the concept is approved, I usually rewrite it using vue.js .

[M. Akbar Nugroho]

I don't know why some people get mad when ohter people use jQuery today. For me jQuery is just JS with simplified API.

Maybe if jQuery team redesign thier website and add API to manage custom element, it could be a game changer for them :D.

[Marc Ziel]

The one reason not to use jQuery is that nobody is learning this library anymore so you're creating an outdated code that fewer and fewer people will be able to understand. But if you're the only one that will be ever interacting with the code it's fine.

[HS]

You get a like just for a title😁. But honestly my reaction to a title was not a "clickbait" but rather "he probably had a simple task and didn't overengineer it"

[Dekel]

Thanks @greenroommate ! The post in general talks about using whatever tool you (as a developer) have in order to get the work done, and sometimes using a bit "old-dated" framework/language/tool - is good enough (and might be a better choice!).

[RedEyeMedia⭕]

Interesting read 👍

[Dekel]

Thanks @redeyemedia !

[𒎏Wii 🏳️‍⚧️]

Not that there's anything wrong with using jQuery for some quick'n'dirty prototype, but why use it at all? This seems like it could easily be achieved with plain JS without that much effort

[Dekel]

A few things that the jQuery-UI gives me out of the box helped me decide to choose that instead of vanilla. Not saying it isn't possible, but much easier and shorter code.

[Charlie J Smotherman]

Lets not forget JQuery-Mobile.

Per their website:

A Touch-Optimized Web Framework

jQuery Mobile is a HTML5-based user interface system designed to make responsive web sites and apps that are accessible on all smartphone, tablet and desktop devices.

As mentioned above the differences between browsers was horrible back when JQuery-Moblile was first developed, and this was there attempt to address the browser/reactivity problems. I used it when it first came out and it was a god send back then, but now there are much better solutions.

I really don't see any sane person starting a new project with this, but it's out there if you so desire.

Happy Coding

[Abdul Rahman Sabbagh]

I tried Angular and React, and I hated them both. In fact, I hate all javascript libraries except JQuery. It's understandable, simple to read, write and maintain and I still use it in all my MVC projects.

[Dekel]

Working on large projects - I think the approach of the new frameworks work a bit better. The larger your project is, the more complex it is, and getting into a large & complex jQuery code is (usually) not as easy as getting into a codebase that is written in one of the modern frameworks.

[Dekel]

Never tried Alpine. I'll give it a try 😀 thanks for recommending it!

[Dekel]

Thanks for the vanilla demo! Note that you can drag the circles on any axis, and you can also drag them outside of the container. Yes, it's definitely possible to create the same using vanilla js, but to get the entire functionality you will need to work a bit harder (and jQuery-UI draggable API gives you this out of the box).