Great Plugin – But please make it jQuery Free

Hi,

Thank you for your suggestion, but I’m afraid we can’t do that in the nearest future. Using jQuery is more convenient, since it is already part of WordPress core.

Best,
Ernest M.

Yes, it’s part of WP Core. But while building a performant website we often remove jQuery for the front end pages as it is simply useless to let the browser download and parse the whole library just to use 0.00001% of it. And as now vanilla JS is so powerful, all the same things can be done with vanilla JS where the browser doesn’t have to wait for a large library to parse to execute some code.

I can understand what you are saying but I think people should put more focus on writing highly optimized code to ensure a faster web experience.

I agree vanilla JS has came very far in the last couple of years. There are however many benefits of using some of the features jQuery offers. For example I know we utilize these methods:

.addClass()
.removeClass()
.parents()
.closest()
.filter()
.find()
.attr()
.prop()
.val()
.css()

And these are just from the top of my head. Probably some of these could be resolved with a different approach, and others with an inhouse custom function for sure. jQuery however offers a very convenient and working solution for these.

However consider the case if we develop replacement methods for all the currently used jQuery assets. That means the code will grow in size for sure. Nowadays almost all WP sites include jQuery either way – so overall it would cause a negative effect for most users with more code included on their side.
Maybe having both a jQuery and non-jQuery version could resolve that, but then we would have to maintain two separate versions.

Best,
Ernest M.

Hi @wpdreams,
All the things you have mentioned above can be done in vanilla js without any special tricks. If you want, you can share your jquery script (properly commented) and I can convert then to JS if I get some free time.

so overall it would cause a negative effect for most users with more code included on their side.

– That’s a big misconception man. The size of your code doesn’t matter. The browser will convert them to byte code anyways. What mattes is dependency on other things. For example if you have a jquery code of 100 lines and a vanilla js counterpart of the same which has 200 lines. The vanilla js will run faster as it has no dependency and the browser can interpret it easily without depending on another library and then pass every operation through that library to understand what’s happening.

So, if you just have the vanilla JS version you don’t need to have a jquery version of the same code as that will mean more maintenance which makes no sense. Your vanilla js code will work perfectly whether someone uses jquery or not.

If you try out the WP Cloudflare Super page cache plugin which Salvatore and I wrote which uses no jquery you will see it will work perfectly whether you include jquery or not as the scripts has no dependency.

But because most sites don’t care about web perf and writing performant code, doesn’t mean you need to do the same.

Thank you for the clarification.

The vanilla js will run faster as it has no dependency and the browser can interpret it easily without depending on another library and then pass every operation through that library to understand what’s happening.

But isn’t jQuery coverted to byte code as well? I mean the call stack is definitely larger, when a call is resolved via jQuery. Using for example $.fn.removeClass() the browser gets the method from the $.fn object and executes it. If there was a single native built-in JS function capable of doing exactly the same, it should be much faster. But what if there isn’t? I need to create a counterpart for it, and isn’t it basically the same in terms of performance? I mean calling a random function, which I created vs calling a jQuery function. (if we assume I can make it just as efficient)
I feel like if the jQuery version is efficiently written, then shouldn’t it be just as good?

Best,
Ernest M.

But isn’t jQuery coverted to byte code as well?

– Yes it is. But for your scripts to run first jQuery needs to be parsed and then every bit of your code needs to be passed through jQuery library to make an understanding of what you want to do. So, basically jQuery will tell the browser what you are trying to do in vallia JS way. So, example when you do $('.some-class') and the browser pass that code through jQuery library, it will tell the browser to do document.querySelector('.some-class'). It’s a very over simplified example just to give you an idea. So, it can understand this is extra work for the system CPU (specially on the single core of the CPU) as browser rendering mostly depends on the CPU single core performance. So, on a low end mobile device it can easily overwhelm the CPU due to all the extra computation it needs to do.

Using for example $.fn.removeClass() the browser gets the method from the $.fn object and executes it. If there was a single native built-in JS function capable of doing exactly the same, it should be much faster.

– There is an alternate way of doing the same thing. But without looking at the code it’s very hard to say that. For example I’ve taken this code from here: https://api.jquery.com/jquery.fn.extend/ which you can see in action here: https://codepen.io/isaumya/pen/WNRvypE
and then I’ve replicated the same with vanilla JS by showing the versatility of it and what you can possibly do: https://codepen.io/isaumya/pen/XWpbYYG

But what if there isn’t? I need to create a counterpart for it, and isn’t it basically the same in terms of performance?

– That is not the same in terms of performance. Even if you need to create a custom fution for something that would be like creating 0.0000000000000000001% of jQuery library and without any dependency on anything else. Not to mention, the custom function you will create will be defined just for what you need it to do without any extra overhead, whereas all jQuery function needs to have internal function dependency, multiple parameters, multiple checks for multiple things. You won’t have any of those things. As your function will do exactly what you wrote it to do.

Moreover you can find smart ways implement the same without much hassle. Trust me man, the old days of vanilla JS is gone. jQuery in systems like WP is simply there for backward compatibility but when you are creating a plugin you can focus on making it most performant and fast. You don’t need to use a system that will hurt your users and not help them (in terms of web perf).

I feel like if the jQuery version is efficiently written, then shouldn’t it be just as good?

– No because of many reasons:
1. instead of loading 1 script now we need to load 3 scripts. jquery core, jquery migrate and then your jquery script. Even if you hypothetically load all of them in defer way, still the browser will load and execute them all. Not to mention WP loads jquery in the head by default.
2. Then the core you have written is basically unreadable by the browser and it needs to pass every single thing of your code though the large jquery library to get the vanilla js version of it that the browser understand and execute. This puts a lot of strain on the main thread and CPU single core.

Imagine it in this way. Let’s say you don’t know French. But I gave you a French novel to read, understand and make a play out of it. So, for every single word of that book, you will basically go back to a dictionary to convert it to your language and then make a meaning of it.

@isaumya is right.

All themes and plugins should by now use Vanilla js and not jQuery.

If they are not yet on pure javascript, they really should ASAP do that.

In the near future, WordPress back-end will also be Vanilla js. Ofcourse, there will be jQuery compatibility for the plugins/themes that need jQuery in the back-end.

No worries, I just reworked the Pro version core to be jQueryless. To spare much of the code, I made a small modular ES6+ library (sort of fill for some of jQuery features) – which makes the final plugin script only about 10kB larger. The execution is noticably faster, so is the page insights score and the code coverage.
Once we get through the testing and the initial issues after release, the lite version follows.

Best,
Ernest M.