Last Week I Wrote Some jQuery (and no one fired me 🤓)
Tags: discuss, javascript, programming, webdev
Published: 2021-08-15 20:40:42

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](https://www.jquery.com) 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.

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1cggt4n378h9e8xqn4v6.png) <figcaption>Photo by [@Pexels](https://pixabay.com/users/pexels-2286921/)</figcaption>

### jQuery UI

Following the wide usage of jQuery - another lib was released, called [jQuery-UI](https://jqueryui.com/). 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](https://jqueryui.com/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.

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1s796w40abxlj53kulq3.png)
 
### 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):

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

{% jsfiddle https://jsfiddle.net/wrd9mfkz/ result,html,js,css %}

> 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. <hr style="margin:10px auto;"/><sub>Cover photo by [Markus Winkler @ pixabay](https://pixabay.com/users/viarami-13458823/)</sub>