Training wheels are an additional wheel or wheels mounted parallel to the rear wheel of a bicycle that assist learners until they have developed a usable sense of balance on the bicycle. Wikipedia
I remember when jQuery developers announced that they have the coolest thing around. It was so precious to them that they put it in chain syntax.
Mocking people who heavily depend on using jQuery is like ridicule the newborn baby for not being able to walk.
Personally I don’t like chain syntax. Still, sometimes situation and overall environment makes perfect conditions to implement your feature with a chain. I do it and you should do it too.
There are libraries that almost exclusively implement chain as the way to go while writing code. Take a look at more than popular data visualization solution D3js (https://develoger.com/d3js-demystifying-the-magic)
$(document).ready
My first desire was to write an article with title “You might need jQuery”.
Then I realized two things.
- I had desire to do it mainly because I wanted to show that this http://youmightnotneedjquery.com must not be taken as it is. But then I reminded myself that I am not the guy whose main goal is to prove that other people are wrong. Everybody is free to write stories and code in which ever way he / she thinks it’s the best (still, I agree with Douglas Crockford about the topic and how people often fight for freedom to write awful things).
- Even though I like to think that I know quite a few things, I always additionally prepare myself for each article. As part of that process I visited official page of jQuery API. My goal there was to find methods that are providing solutions for problems of modern Front-End development. Kind of things that can fall into category of reinvention of the wheel.
Sadly result of that search failed to impress me.
jQuery alone is just not enough at the moment. Actually it was never enough, because there is no such thing as writing jQuery, it was always all about JavaScript.
Most of the time people needed jQuery not to base their codebase on it. But to use it as dependency for 3rd party solutions that they needed to implement into their projects (sliders, carousels, light-boxes…)
$(window).load
Since API page was big disappointment I naturally clicked on the plugins section…
It looks like jQuery team realized that times changed (as described in https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016).
At the moment of writing this article there are 2424 packages found for “jquery-plugin” on npmjs.com.
Now lets get back to the main reason why I disliked clickbait part of http://youmightnotneedjquery.com project (I still think that it have lots of value and ironically I fully support it). But at the end, intentionally or not, it managed to miss the whole point of using jQuery in 2016, 2017, 2018…
jQuery is not library it’s platform.
To use jQuery or not to use jQuery isn’t the question that needs to be answered based on revolutionary features that we can’t live without in this modern era of Front-End. Instead it’s about possibilities that it brought to us, being universal way of writing things.
Standardization
90s
Windows didn’t won PC Operating System game because it was most advanced nor the best. People and market in general needed standard and Microsoft managed to provide just that. Imagine the world in which manufacturers of hardware need to make drivers for 10 different operation systems…
Beyond 2000
Now you know why jQuery (among other great things) was standard for so many years. When Cross-browser incompatibility was at it’s peak world needed standard so badly and that’s where jQuery made revolution.
This was in the days when things like selectors were actual problem. Or the way we set / get attributes… It was matter of syntax and it’s implementation on the browser level. Which jQuery solved very well.
Modern age
ES5 syntax is pretty much a standard in the current era. The problems that jQuery was solving on the app level are now solved on the level of browsers.
Today we care about transpiling modern ES code into ES5 compatible and that is something that’s not being done on the fly nor in the browser. Instead we introduced the build system which takes care of it. Jquery developers didn’t had chance to compete for their place there and I believe that they never had intention to do that.
$(selector).slideUp()
I remember when CSS3 came and how people instantly started to mock jQuery animations. I mean yeah, CSS3 implements it on the level of browser where we have much more possibilities to optimize. JavaScript can change inline styles dynamically. That is how slideUp() is implemented. There is a function that recursively calls itself until some goal is made. It changes the inline styles one step at a time, until animation is over.
This implementation may seem convenient and cool but it faces hardware limitations. Which are crucial on Mobile or on any platform where device CPU isn’t strong as beast.
JavaScript is being executed inside the browser which is already consuming CPU. Even the browser itself is never only app that is using it.
You see how performances and code optimization become important…
Luckily jQuery developers understood this and as soon as window.requestAnimationFrame() became widely supported they took the chance and improved jQuery animations performance quite a bit.
Instead of fixed (calculated from execution time and height) amount of executions done by recursive setTimeout, animation steps today are rendered as much as it is physically possible. If device can support 10 frames per second, that’s how jQuery will execute it’s animations.
Forbidden love
Trying to force React and jQuery to work together is decision based either on laziness / ignorance or bad project management.
Thing is that if you want this whole virtual DOM thing to work in efficient way all manipulation of elements must be done through React. I personally don’t see how jQuery fits into that scenario. You sure can use it as set of helpers (without actual usage on the level of selectors or DOM manipulations) but there are much better libraries than jQuery for that particular purpose (https://lodash.com or http://underscorejs.org).
We already have some nice React plugins for common Front-End implementations (sliders, carousels, input mask…).
Instead of trying to patch jQuery into React find appropriate solution or write it yourself, since believe it or not it’s not that hard (still it may take some time).
All of this applies to VueJS or any other reactive framework.
new Date().getTime to say goodbye
jQuery gave so much to us. Even though it provided set of copy / paste tools for people that live and work in their comfort zone, it sure was amazing.
Sad truth is that it’s not solving problems of today. Somehow it remained to live in the past. Maybe that will change, or maybe the whole industry will change again to align to what jQuery can offer.
No matter of what will come tomorrow I can say…
Thank you jQuery for all moments of joy. When I coupled my projects with you I didn’t done that because of selectors, I did it because of platform.
If you are reading this it means that you are curious and passionated about JavaScript and Front-End in general. That makes two of us!
Consider joining me on this adventure of discover by following me here, maybe clicking that heart or checkout my twitter account https://twitter.com/develoger
Once I hit 1000 followers on the blog I will share the prizes (public draw) -- 2 yearly subscriptions to https://egghead.io
