Should I stop using jQuery and create custom abstractions?

Question

I'm a junior web developer. My current work is on a form-based server side web application. It was set up using jQuery. I'm now the primary person working on it. In a previous job, which was more front-end-centric, they decided to move away from jQuery. It was not needed anymore.* I heard it elsewhere as well. But I sometimes feel like I would like to write my own abstractions for DOM queries and operations.

e.g. quering

var theElement = document.querySelector('.ImTheOneYoureLookingFor')
if (theElement == null) {
 throw new Error('query failed: .ImTheOneYoureLookingFor')
}
// do things

I thought an abstraction would be a good idea. Maybe someting like

/** @global */
function webQuery(selector) {
 // throw if not 1 found
}

But this feels like writing my own jQuery. Is this good practice? Should I care less about my code going "straight" (no detours)?

[ADDITION] *(like Greg Brughardt noted in a comment) the reason to move away from jQuery were simpler and standardized added browser API's.

• devnull: short answer (to the question in the title), no. you'll end up writing something that is close to jQuery but maybe not as mature. if you're rolling your own frontend library for others to use then you probably have a different view of the DOM than jQuery has and it would make sense to create a different implementation.
• Greg Burghardt: "they decided to move away from jQuery. It was not needed anymore." - they were not re-implementing jQuery. They discovered they did not need jQuery anymore.
• Greg Burghardt: To be clear, they were likely replacing jQuery with native DOM methods and operations, rather than calling jQuery, which was probably delegating to native DOM methods.
• Filip Milovanović: "But this feels like writing my own jQuery" - you have a good instinct there. Don't write abstractions that are super-generic (if you're not writing a generic library), where you basically do the same thing as jQuery, but differently. Instead, write more high level abstractions. So, not so much "get this element and that element, and fiddle with attribs and css class names", but more on the level of createItemList(...) or disableInapplicableFields(...) or showHintForInputField(...). Something that has more direct connection to what your application is doing. 1/2
• Filip Milovanović: The reason is, staying at a higher level lets you more easily change the details of how it's done - you can use jQuery, or some other library, or vanilla JS. Whereas, if you basically try and recreate jQuery, it's much less flexible, error prone, and a lot more work. 2/2

Answer 1

Custom abstractions should feel custom. That is, they should take advantage of knowing your particular needs. Without that you’re simply replacing a well known library with an obscure one that has little support.

Code reuse is a fine goal but must always be tempered with the goal of readability. Unfamiliar code comes with a cost. Be sure you find some way to make up for that.

As the "primary person" working on this the best thing you can do is find someone else to review the code. Preferably someone who may end up supporting it one day. Do this while you’re still willing to change your mind.

• pikachu: (I know I'm not allowed to write this kind of comments, but) thank you. These are valuable things to keep in mind. I'll resist my clear code tempation.
• candied_orange: @pikachu don’t resist. Temper. Get feedback early. Sometimes that nagging thought you’re trying to ignore is actually a good idea.

Answer 2

What I did: (We'll see whether this was the right choice.)

---

1. Research on DOM API's

There's more than I knew of:

// jQuery => DOM pseudocode
const jQueryMapping = {
 toggleClass(el, className, shouldBePresent) => el.classList.toggle(className, shouldBePresent),
 parents(el, selector) ≈> el.closest(selector)
}

A good overview is found here: https://youmightnotneedjquery.com/ ^{(from this answer's comments.)}

(also note: you can use different methods for the same result: e.g. see parents mapping above.)

2. Use utils for still oft repeated functions:

I kept 2 extra DOM functions I kept repeating. I felt it would increase conciseness. I added them under <file:./Shared/DOMUtils.js> on the object const Shared_DOMUtils. (We're not using JS modules).

const Shared_DOMUtils = {
 /** throws if not found with an error message containing the selector. */
 querySelectorSingle(parentElement, selector) => ... 
 /** returns as array instead of NodeList. */
 querySelectorArray(parentElement, selector) => ...
}

• I changed the name from webQuery querySelectorX like the native browser functions in order to ensure clarity for others. When there was no similar DOM
• I also used /** double asterisk comments */ in order to give a description in code editors.
• To limit the length of the "pseudo-module" object and to signal these are custom methods, I use it like this:

(function () {
 let my = Shared_DOMUtils
 ...
 my.querySelectorSingle(...)
})()