Last week I wrote about a little tool I had developed for client-side content internationalization, and at some point I mentioned a certain opinion being formed lately, among some front-end developers, accounting jQuery to be living on borrowed time, until ES6 takes the big stage.
I have come across a particularly interesting article, written by Patrick Kunka, going straight to the point of this argument:
Stating ES6 as the headsman of jQuery is a pure fallacy!
Although I disagree with his opinion that you should abandon jQuery at once, it is true you could do it right away (if maintaining backwards compatibility with old IEs is not a requirement for you), and not wait for the generalization of ES6 to move away. Native DOM manipulation API exists to some extent -
Element.addEventListener() - and more sophisticated functions can be built on top of that.
And although I recognize Patrick's brilliant effort, I do not think devoting to vanilla will be the path for most of us. Simply because dropping jQuery for nothing else means one immediate thing: rewriting parts of that functionality! And nothing you come up with will be as effortless and bug-free as jQuery, no matter how skilled you are. Will you get better performance if you fine-tune and shape your own tools to your own needs? Sure, but will you find yourself in such a position where you will have to tread that road? Certainly not everyone, and I risk saying most won't.
This really takes me back to an occasion when I had to write a firmware for an electronic picture frame. For those of you that have never worked with embedded systems this might sound shocking, but the generous 78kB EPROM was barely big enough to accomodate this firmware (that would just display and slide pictures), a really simple file system and some IO routines. No OS available meant no glibc available, so I had to design my own (simplified)
malloc() implementation. I felt really proud about my own tweaked memory allocator, that fitted my purpose just fine. However, would I have incorporated glibc had I had the chance? You bet.
Just as with jQuery. If it isn't part of your problem, then I see no point in retiring it. The API is clean and robust. It favours a functional approach, which tends to make your code more readable and compact. So, if you are not squeezing those extra milliseconds, you should be fine sticking to it. And I must say I am also an adept of following the paradigm of having UI objects decoupled from the markup semantics (unlike Angular or React's JSX), and often use indexed jQuery wrappers for that purpose, which allow me to call
$() on a strict need-to-use policy.
And so, the question remains: Is jQuery really doomed? Certainly not by ES6. If anything, I expect jQuery to benefit from it, improving its API with the sweet new sugar coating we are getting. Is it doomed by something else? Angular changed the paradigm of how Single Page Applications are designed and built, and jQuery's DOM manipulation world does not ordinarily fit Angular's paradigm.
But for as long as people specify content in the form of html markup and define class based styling, scripted behaviour will largely benefit from a trustworthy library that provides you transparent traversing and reliable event binding. And that, jQuery does better than anything else out there.
Good night and good coding.