Non-jQuery version of DataTables. Is this gonna happen?
Non-jQuery version of DataTables. Is this gonna happen?
daytonoutar
Posts: 25Questions: 7Answers: 1
in DataTables
Is there any initiative to have DataTables operate without jQuery as a dependency?
This question has an accepted answers - jump to answer
Answers
Its something I keep considering - but then I keep coming back to the fact that it would be a very significant amount of work to re-implement the parts of jQuery we do use. For example event namespaces, events (keeping in mind that DT supports IE8+ - actually the current version is IE6+, but that will change soon) and various other things.
Perhaps I might be wrong, but I feel my time working on DataTables would be better spent improving its core and features, rather than effectively rewriting parts jQuery and increasing the size and testing of the library. I'm not even certain how much space it would save once that has been done.
That said, another option is to effectively abstract jQuery out, so it can be used if available, and if not then some compatibility layer that uses querySelectorAll will be used and that would support only evergreen browsers. Again, there is a good bit of work involved in that, and I've not yet made my mind up about if it is worth the trade off and size increase. It is probably the way I will go as I'm thinking about that as I'm writing the stuff for DataTables 2, but it does need to be noted the amount of value there is in using jQuery.
Allan
I've been looking through the source code. It is respectable work.
I've seen an attempt to abstract jQuery out through this project, https://github.com/Mobius1/Vanilla-DataTables
It's not complete though and no where near the maturity that jQuery DataTables have. I may make an attempt at contributing to that project while making reference and going through your source code.
I do understand your goals and the focus you have on improving the core and features of jQuery DataTables.
I may be just one of the few developers that prefer to use DataTables in any framework including Angular, which discourages the use of jQuery.
I'll make an attempt at abstracting away jQuery but time will tell. It's not a priority, since I am mostly focused now on learning Angular while building an app that delivers value to users/customers.
Not to bump the thread, but I have also been looking a bit at it. But it is significant work and not sure it will be worth it as Allan mentioned for various reasons.
@daytonoutar if you do plan on having a look, let me know. I am going to have a look at that github repository. If I do decide to do it, I will probably drop support for any unofficially supported browsers.
@allan is there a roadmap for DataTables 2?
Its somewhat out of date I'm afraid, but this is the roadmap. I need to update it!
Allan
Hi @allan. I've been using DataTables for a long time now. Still my preferred data table on the web. But since the years have passed, I have been moving away from jQuery and am now coding everything in Vanilla JS. So my question, are there any plans for DataTables without jQuery?
There is a loose plan - we have briefly looked at alternatives, and that is still on the backburner, but it's not the main priority for us right now, I'm afraid.
Colin
I saw a pure js datatable https://github.com/fiduswriter/Simple-DataTables
Everyone? Really?
https://trends.builtwith.com/javascript/jQuery
Currently no - we have no immediate plans to move away from jQuery.
I mean we could spend the next month or so rewriting major parts of of what jQuery does for us (the hardest part would be the eventing probably) which is more or less what the Bootstrap team have done for Bootstrap 5, but honestly, why bother for a team of our size?
Will it save some KB on download? Possibly - but then we'd be better just levelling up with Cash (which I plan to do). Beyond that - I'm not clear what the benefit would be other than to say we don't require jQuery. It would also massively increase our support surface if we needed to write a bunch of utility code.
In terms of the frameworks - we'll probably provide wrappers around DataTables as it is - we won't be rewriting DataTables with just Vue for example though (since then Vue would be the dependency rather than jQuery!).
On the Vue point - I use DataTables extensively with Vue and it works really well (just not with Vue's reactive data - a wrapper might be able to resolve that).
I'm happy to be convinced that there is a good technical reason for why we should drop our requirement on jQuery, balancing the increased development and maintenance, but I personally don't have one yet. If you do, I'd be very happy to discuss further!
Allan
@allan The trend is to stop using jQuery.
It doesn't make much sense to use it now in 2020. Browsers are updated frequently, support new javascript features, and almost all of them use the Blink engine. What the jQuery was used for is no longer relevant...
My projects are written in vanilla javascript, but I have to include a jQuery for your wonderful and the best table and other front-end programmers "think that my projects are written using jQuery, which is not cool now in 2020"
.
And also when the project is rewritten in vanilla javascript, it is easier to export it to other frameworks (React, Vue.JS, etc.).
You correctly noticed about Bootstrap 5, one of the examples...
BTW Yes, using Cash for basic functions is a good idea.
And this is already a working implementation in vanilla js.
Hi @Epexa,
Thanks for the feedback - the more we know about how folks are using DataTables, the more we can develop it to optimise for those use cases. And thank you for your kind words.
My view of jQuery has changed over the years. As you note, its original intention was to abstract away browser bugs and inconstancies. That is largely irrelevant now, but now I see jQuery as a utility library. The link you gave to "You might not need jQuery" gives an excellent idea of why a library such as DataTables benefits from a utility library - the code size is massively smaller also reducing the amount of code we need to maintain.
Do you use Underscore or Lodash? Does that make your code non-vanilla JS? The same applies to Cash - if we made DataTables work with Cash, would it be non-vanilla JS? Or can that term only be used if you don't depend on any other library (Bootstrap still depends on Popper, despite removing their jQuery dependency)?
I tried to port DataTables to Cash in September - this is a report of my findings at the time.
There is no question that it is absolutely possibly to make a non-jQuery version of DataTables. However, it would increase the code size and maintenance of the code, and it is not yet clear to me that it is worth that, just to claim that it is Vanilla JS.
Allan
Hello allan!
Hope you're fine.
Any news on this?
As time passes, i only have jQuery for select2 and DataTables.
Best regards
My thoughts haven't really changed from my comment immediately preceding yours. If we were to drop jQuery, we'd just need to implement our own DOM abstractions, event handling and so on. The size of DataTables core would go up, the maintenance work involved in it would go up and I'm just not really seeing the benefit? Is there a clear benefit you can see?
Allan
It's just to remove a dependency that i don't use anymore but need to use DataTables (instantiate, add event listener etc...). More and more projects remove jQuery (like Bootstrap 5). But i totally understand.
Are you just looking for a way to not have to deal with the dependency (let a bundler handle it) or write any jQuery code yourself? If so, I can add and document that.
Allan
Yes it's about not writing jQuery code, and free ~30k of jQuery dependency as i don't use it.
For example, if i want to add event listeners for Datatables event, i must use jQuery on() function and not native addEventListener js function.
@lugus You can use Javascript events. The key is to use event delegation. Maybe this tutorial will help. I took this jQuery events example and changed it. to use the technique in the tutorial in this example:
http://live.datatables.net/capabofi/1/edit
You can click on a row in any page and get the proper row data. Is this what you are looking for?
Kevin
Thank you @kthorngren, i will take a look, in my memories events dispatched with jQuery are not compatible with native js addEventListener because they are not really dispatched.
Here is a slight modification of Kevin's example with native event listeners. As you'll see, jQuery events are fully compatible with native event listeners since they are just using the underlying DOM. jQuery is just an abstraction layer on top of that to make it much easier to traverse and manipulate the DOM. There are parts of it now which aren't as relevant as they once were such as
.
$.ajax(replace withfetchnow), and animation (replace with CSS animation) but jQuery slim helps with that, leaving just the core goodnessThe only line of jQuery left in the example is the initialisation of the DataTable, and that I can abstract out if you don't want to write any jQuery at all?
We'll still have the jQuery dependency ourselves, if we removed jQuery, we'd just end up writing the same abstractions they already give us. DataTables would get bigger and hard to maintain, so the net savings in bandwidth would likely be a rounding error, particularly if you are loading other libraries such as Angular, Vue or React.
Allan
Thank you @allan!
Ended up here looking to see if there was any change/development on this one since the last time I looked. Like many others I use bootstrap and will be converting over to BS5 soon which is now free of jquery. As the release of BS5 got closer, and now released, I am noticing the vast majority of the plugins I use converting over to vanilla js.
I've read over the comments here and one that wasn't mentioned was performance. There is a night and day difference here - js performs waaaay better in every aspect compared to its jquery alternative overtop of it. Sure, one can argue that some milliseconds here and there aren't going to add up to much, but that all depends how extensive your application is and being used of course - which could be a very big difference.
The other thing to think of is how long do you want to support the older browsers? At some point you need to cut the cord for the better of everyone - forcing those who are 'stuck' on old browsers to use current options. The time has come where we don't need separate code/logic to handle older browsers. Collectively people have realized the benefits of standardized methods/coding and its actually happening after all the years of complaints.
I see you've mentioned a larger codebase and more to maintain, but when you do add/modify a feature is there really going to be more to do or make it harder to accomplish versus the same with jquery? From my own experience as I start changing over my own code I am not really seeing this occur - there might be more lines here and there (and a little familiarity curve to get through for me), but I'm not looking at that as a negative, but rather a positive in the end grand scheme of it all. As far as larger code goes in a few years you just might be having to consider the extra ~80kb of jquery as 'part of' datatables if most people are only including it purely to use datatables. You wouldn't need to maintain jquery of course, but if its the only reason people are including it is your code to the end-user really smaller now vs a version without jquery?
There is a lot more to this movement of removing jquery dependency than 'its the cool thing to do', 'the latest trend', or saving a hit and the bandwidth of loading it. I would not even call those reasons or arguments.
Just throwing out my opinion. Even though there would be work involved initially to change over I feel this should be considered more strongly than it is.
Hi,
Thanks for your comments here!
I’m actually not too concerned about the performance aspect of jQuery. I’ll notice if you look through the DataTables code that we don’t use jQuery in performance sensitive areas - particularly the scrolling calculations and the actual draw. If there is any area of concern for performance due to jQuery, let me know and I’ll get it removed.
Agreed - this is a strong point. As I noted above, I don’t actually see jQuery as a compatibility library now (I certainly used to in the old days), but rather as a set of utility tools which make the DOM much easier to work with. For all that
fetchmakes Ajax easy,querySelectormakes selection easy and so on, actually manipulating the DOM is still a huge pain imho. I find this site to be a good advert for why jQuery is really useful as a library author. It removes a ton of boiler plate code.Event handling and synthetic events is my main concern. I did have thoughts about doing our own in DT2 for performance reasons (jQuery events use the DOM which slows them down, although in turn can make them much easier to listen for).
We could most certainly do it - it would take a sizeable chunk of time and I’m not yet clear about the benefits (return on investment) in my head. Plugins for Angular, React and Vue might be a better time investment at the moment.
Allan
The main problem is that jQuery has becoming useless as JavaScript is becoming powerful, also there are many conflicts when we use jQuery and React for example. Therefore, a vanilla implementation of Datatables will be important in the future.
I don't quite understand that view point to be honest. jQuery is just a utility library - if we didn't use jQuery, we'd be rewriting a lot of the utilities it provides ourselves, which seems like a waste of development effort to me.
React and jQuery don't really work nicely together because they are both trying to control the same DOM - just stripping jQuery out of DataTables or any other library isn't going to immediately resolve that.
I don't disagree that we can increasingly move away from jQuery - as I noted above the days of browser incompatibilities that it resolved for us as basically gone (for the APIs we use), so it really is only a utility library - its ability to manipulate the DOM are so nice compared to the native methods for example!
Allan
There is a lot of legacy baggage that comes with jQuery. You may only use 1% of jQuery's utilities, but that means the whole of jQuery has to be included. Just the other day I was looking into upgrading browser security in my apps, and came across trusted-types which are not supported by jQuery (will come in 4.0.0). This means my apps cannot use trusted types just because I have to include jQuery. (Sure this is some bleeding edge security feature that isn't even supported by browsers yet. Although considering 70%+ browsers are Chrome, and 90%+ are Chromium based, and Chrome 83 I believe supports this, the question of browser support is really irrelevant and comes down to obscure niche browsers and Firefox, but Firefox is 100% gonna support it once it gets finalised.) Eliminating jQuery would still not solve this, because I'd bet the vanilla JS rewrite wouldn't support trusted types either, so in this case relying on a 3rd party library actually helps, because if they fix it, and you only use their apis, then it should "just work".
I'm totally onboard the "Stop jQuery" train. I think jQuery usage statistics are totally false today. I bet my webapp counts towards a user of JQuery when in fact, I don't have a single line of jQuery in my code, I only need it because it's a dependency for other libraries I use. Relying on jQuery has the unintended side-effects of actual bugs being used as legacy features, and when those bugs are fixed things break and both library authors and contributors are fumbling around to try to fix it.
Thanks for your input!
We certainly don't use only 1% of jQuery, which is actually the problem. If we did, it would be trivial to remove, but we make extensive use of the DOM and events - the two biggest parts of jQuery, so we probably make use of a large part of the library. That's the whole point of it as a utility library - if we didn't use those methods, we'd need to rewrite them and the whole page size would just be the same anyway - the key difference being that we would now have more code to develop and maintain, and there would be less reuse with other modules.
I am removing bits of jQuery where appropriate (I dropped a
$.mergecall yesterday for example) and eventually it will be possible to replace jQuery with another library such as Cash (same idea, but smaller) or some other abstraction of the DOM if you prefer.I'm 100% onboard with reducing library size (which is what the remove jQuery moment is about) and you'll notice from over the years that is something I've been very keen on in DataTables. My feeling, at the moment, is that we get more benefit from using jQuery than we would do from removing it.
Allan
If the event system doesn't require jQuery (I thought it did), can you simply drop the jQuery examples and replace them with ES6?
The examples and documentation feel dated because they unnecessarily rely on jQuery.
I'll probably not replacement outright - but rather have the code in two forms allowing you to switch between them. I've started that process already.
For the moment, there are non-jQuery initialisation examples.
Allan