Materialize: Consider removing the dependency on jQuery

[thednp]

Why don't you guys do a jQuery free framework? Or else this is just another soon to be useless Bootstrap.

[darrynten]

+1 for removal of jQuery

[ginus]

zapto or jquery?
react or mithril, angular?

[thednp]

PLAIN JAVASCRIPT ++

[victorperin]

please remove jquery!

[thednp]

please remove jquery!

check out my project here https://github.com/thednp/bootstrap.native

[Holyphoenix]

Why remove Jquery?

[victorperin]

@Holyphoenix http://youmightnotneedjquery.com/
Also, when you stop using jquery, you have a performance gain.

[obsidienne]

It's true. Jquery does not really help according to the targeted browser.

Maybe using es6 with a compiler...

Le vendredi 29 mai 2015, Victor Perin [email protected] a écrit :

@Holyphoenix https://github.com/Holyphoenix
http://youmightnotneedjquery.com/

—
Reply to this email directly or view it on GitHub
https://github.com/Dogfalo/materialize/issues/877#issuecomment-106867178
.

Claudio BERNARDES

[victorperin]

+1 for es6!

[Holyphoenix]

With the power of our machines these days, I'd put code readability above "performance" worries. I've never had major trouble with performance when I've used JQuery. I know its not as fast for some things as what I could write, but not enough to justify it. JQuery owns when it comes to readability.

[thednp]

@Holyphoenix readability IMO is not the point. Nowadays there's no need for jQuery unless you REALLY heartly want to support legacy browsers. So with ES5, ES6, coming ES7... are you going to include that inside jQuery? Isn't element.value better and more readable than $(element).val and surely better in terms of performance. Yes jQuery handles events properly for old browsers and makes code more "touchable", and that's about it.

[victorperin]

@Holyphoenix When you're building webapps or even normal apps, you really need to focus in performance.
Also you need to load the jquery and it can slow a website loading:

As you can see, jquery added 82,40kb it's 70% of the size of materialize.min.js itself.
If you just delete jquery from it you could save some time from loading.

[Cosmicist]

+1 for no jQuery. Totally agree that jQuery is not necessary, specially in a framework that doesn't have legacy browsers support, which btw, I think is a good thing.
This and flexbox grid would be the things that would make this framework stand out, but that's for another issue (#771) :)

[ugate]

+1 remove jquery. use vanilla js

[MackYoel]

+1 for removal of jQuery!

[acburst]

Just to copy my comment from the duplicate issue:

Its something we plan on doing in the future but because most of our components are written in jQuery it would be a long and arduous process at the moment. We welcome people to help with pull requests to port jQuery plugins to vanilla js. But for us, it is not currently our highest priority because of the time commitment.

[yanickrochon]

Since this is a long standing issue, I'll comment here on this.

1. If jQuery is removed, will Materialize be refactored in ES6, using Babel to transpile and compile the code? For this kind of project, I believe that it should, just like SASS is compiled to CSS. Therefore, before even removing jQuery, the entire framework should be ported to ES6. In any case, a roadmap with a list of changes that need to be made is preferrable.

2. if jQuery is removed, how will JavaScript components be initialized? Currently, the framework has $(selector).modal(options);, etc. What will that become? The positive thing with jQuery is that, since everything is a plugin, there is no need to import anything, but jQuery. So, we'd have to use things like Materialize.modal(selector, options); ? However, another nice thing about jQuery is that we can rely on a uniform way to communicate with a component. Such as $(selector).modal('close');, how will that work : Materialize.modal(selector, "close"); ? I don't really like this. Also, will those using jQuery be able to easily listen to events that Materialize components fire? (i.e what will become of $(selector).on('openModal', handler); ?)

3. With the amount of PRs, issues, and literally lack of interest from this project maintainers, I doubt that this issue can and will be resolved anytime soon. There are processes that are defined for large organizations to work together, but it seems that many of these processes and recommendations are simply ignored by the team members (i.e. versioning, code reviews, proper discussion on issues, issue management, etc.) and this is causing much frustrations. The team say that PRs are welcome, but most of them are ignored, or rewritten (and ignored), or not properly addressed (no review before merge). Please, prove me wrong on this, because at the moment I am questioning the leadership of this project.

[thednp]

@yanickrochon http://youmightnotneedjquery.com/

[yanickrochon]

@thednp I think you should actually read the post you just linked.

If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency.

Because this is the question that I asked in my very first bullet point. It's not because someone asks "Do you really need this?" that it means "You don't need this." Perhaps Materialize does not need jQuery (I personally believe that it can very well benefit from it, due to it's size and component nature), but this is the question to answer. Your link does not add anything concrete to the discussion, and certainly does not prove dropping jQuery at all.

[thednp]

@yanickrochon that's for your question: "if jQuery is removed, how will JavaScript components be initialized?", I gave you a link of things to learn the way of plain JS, a place to start. If you check my repositories you will find the perfect answer to your question.

I didn't want to start talking about "You might not need" vs "You don't need", because I already know plain JS is the way to go, as 400ms more load time makes no sense, especially when JS performance is a priority. There is no benefit with jQuery anymore. If you or anyone else think the sizzle syntax is a life saver, please ignore this thread and find yourself something better to do.

[yanickrochon]

@thednp You suppose a lot of things, which many are simply inaccurate.

If you think the sizzle syntax is a life saver, please ignore this thread and find yourself something better to do.

Where, in all my comments, did I ever argued on this? My main argument is how $.fn.* is not only useful, but something that can hardly be replaced.

For example, let's say that you refactor the Modal component this way (because you said If you check my repositories you will find the perfect answer to your question. and this is how you seem to do things) :

var modal = new Materialize.Modal('#modalElement');

How would you pass this reference around? How would you get that reference from inside an event handler across another component? You would need to carry the instance around and manage these references. If the element is destroyed, you would need to handle that as well. My argument is that, with jQuery, UI components are bound to their respective elements (or at least this is the recommended practice, which is not observed in Materialize....) and you don't need to carry instances around, and all references to the UI are destroyed and removed from memory automatically when the target element is removed from the DOM; just like malloc versus garbage collection.

I agree with you, that if this was a small project, a single component, with minimal features, jQuery could be removed without much consequences. But Materialize is a long way from that, with increasingly many components, and the way these components are accessed (as easily as with jQuery) is a real concern for many projects.

Personally, I argue against removing it because the way components are initialized, and accessed is neat and clean; with jQuery I don't have to worry about instances and component lifecyles. I also love that I can chain many calls, for example

$('ul').append(
  $('<li class="collection-item">', { 
    text: "foo"
  }).on('click', function () { 
    // I do not need to care about if the element exists, or if it's a modal or not.
    // If not for jQuery, I'd have to manually check every time I do this.
    $('#fooModal').modal('open');
  })
);

So, this is why many people do include jQuery in their projects. So, what? Would you suggest to have materialize.js and materialize.jquery.js? Since materialize.js would require an implementation of many features that jQuery already provides (or rely on other third party components, as suggested by the blog post you provided), it's size would be greater than it currently is, and would be a downside to those who actually want to include jQuery for various reasons. Thus, materialize.jquery.js would be smaller, requiring jQuery, etc.

So, you see? You cannot just dumb down the issue with "We can do without, therefore we can remove it's dependency." I do not object that it may be practically faster for some cases without (most speed gain is insignificant, and the loading time of 400ms is quite subjective, here), but my concerns are more on the order of usability as described above with component instances and references, etc.

[yanickrochon]

BTW: Here are two screenshots of an app I am building with Meteor (which is bundled with jQuery, and I added Materialize for it's UI). Both are loaded from the same LAN, and the same machine, so there is no bias and both can be compared. Total size and load time is at the bottom of the screenshots.

Development version

(jQuery is highlighted)

Production version

(combined JS, including jQuery, highlighted)

Thus, the focus should be put on including jQuery, instead of having it a separate library :stuck_out_tongue: But, seriously, @victorperin 's argument is refuted right there.

[victorperin]

@yanickrochon thanks for helping the discussion. Your points are really good and should be considered.

My point of view is mostly because not everyone uses jQuery on their projects. Remember: jQuery have much more features that Materialize doesn't use.

Also, now we have new frameworks like React, Angular, Vue, etc. Those guy's have advantages like virtual DOM, who could easly increase performance on rendering elements, if the user need.

Going out of jQuery could make Materialize easly to implement and improve it's performance.

PS: you can minify everything in the same file or improve even better using http2. But you know, the 28.87 KB of the minified jquery still there. Removing it WILL make things a little bit faster on loading.

[TheColorRed]

I have written a jquery like framework, and it is super minimal

jquery:
$('.my-class').attr('data-my-info');

Mine:
$('.my-class').attr('data-my-info');

There is no difference in usage, but it is faster and much more lightweight, as it uses JavaScript es6 to do everything that jquery does.

Here is the dom file:
https://github.com/TheColorRed/web-framework/blob/master/src/typescript/core/Dom.ts

[tomscholz]

I'm going to lock this issue because it's very old and any new discussion should probably happen on a new issue!

@yanickrochon

With the amount of PRs, issues, and literally lack of interest from this project maintainers, I doubt that this issue can and will be resolved anytime soon. There are processes that are defined for large organizations to work together, but it seems that many of these processes and [...] Please, prove me wrong on this, because at the moment I am questioning the leadership of this project.

We are working on that