Materialize: [Suggestion] Get rid of jQuery

Created on 19 Nov 2016 · 12Comments · Source: Dogfalo/materialize

There's a general rule that frameworks should stay un-opinionated
http://youmightnotneedjquery.com/

jQuery might be used by many sites but that still doesn't mean it should be used in a Framework

This will also make the amount of code that has to be loaded for non-jQuery sites smaller

I'm not saying that you should immediately make a transition, but it's still a valid concern

Would a PR removing jQuery even get accepted?
EDIT: If I were to make a PR with it is what I meant, I don't want to waste time on it

Source

ForsakenHarmony

👍20 👎9 ❤6

Most helpful comment

This is really about modularization.

I think many people's objections may stem from the fact that they do not wish to use or have jQuery available in _their projects_ just because they consume Materialize. In an age of tree-shaking and customized builds, people expect their dependencies not to dictate monolithic global exports into their project.

For example, I don't mind that much if Materialize wants to depend on jQuery. However, in my project's build I expect to be able to produce:

A reduced project build containing only the Materialize components my project actually uses.
A reduced subset of jQuery corresponding to only what is used by those Materialize components (or even Materialize as a whole).
A Materialize build which imports jQuery in such a way that $ and jQuery are not in my project's global namespace. This is important because I don't want my team to start using jQuery simply because they found it hanging around as a global - it's a secondary dependency of Materialize, not an explicit dep of my project - which is not well-expressed by the requirement to globally import jQuery in the document <head>.

As a stepping stone that I think could assuage many people's concerns over jQuery here and in #877:

This project could distribute a custom build of jQuery
Or otherwise as an even nearer-term solution, give people the needed info to produce their own reduced jQuery builds.

What's needed to do this is an up-to-date list of jQuery modules that Materialize absolutely depends upon and/or can safely be excluded from the jQuery build.

kriscooke on 4 Dec 2016

👍5

All 12 comments

Love this.

andreujuanc on 20 Nov 2016

My opinion is that jQuery may help reduce the size of this framework. Some components do use jQuery, some don't. And I think the size to be smaller if all components did use jQuery.

In fact, jQuery does allow simple plugin integration with DOM elements, such as $(selector).modal(options) and we can listen to events similarly. Getting rid of jQuery would mean that applications using jQuery would require 1) using different APIs when using Materialize and other third party components, or 2) relying on a third-party project to have adaptors for Materialize to jQuery... meaning that, not only Materialize's code size will increase, but more code will be needed to bring back the simpler API that jQuery provides. Ridiculous!

I get that some people argue that jQuery is wrong, or slow or blah, blah, blah. I just don't buy it. Unless you really need split second optimization, speed is irrelevant in this case, and _it does_ offer a more linear API, with many features already implemented (element size, bounds, inline CSS and classes, events management, user data attached to DOM, etc.) As for the size, jQuery is 86k minified, compared with Materialize at 142k minified (note that, as I said, Materialize could even be smaller if it properly used jQuery, compared to the opposite if not).

-1 for me.

yanickrochon on 20 Nov 2016

👎4 👍4

I strongly disagree. Removing jQuery could increase maintenance and new feature adding costs.

Even Bootstrap the most popular css framework depends on jQuery and it seems pretty fine.

kmmbvnr on 20 Nov 2016

👍3 👎2

I agree, sadly, materialize is heavily bloated with functionalities like parallax. That should be separated.

fega on 20 Nov 2016

👍3

Btw, this is duplicate of #877

kmmbvnr on 23 Nov 2016

Why not modularize it and let developer compile only modules they need in their projects?

Razi91 on 26 Nov 2016

👍2

if removing jQuery is not an option then there has to be official support for react / angular / ...

ForsakenHarmony on 30 Nov 2016

@ForsakenHarmony angular and react would bloat this library way more than just jquery

ncovercash on 30 Nov 2016

I'm not saying that angular or react should be the supported library, just that they don't mix well with jQuery

ForsakenHarmony on 1 Dec 2016

This is really about modularization.

For example, I don't mind that much if Materialize wants to depend on jQuery. However, in my project's build I expect to be able to produce:

A reduced project build containing only the Materialize components my project actually uses.
A reduced subset of jQuery corresponding to only what is used by those Materialize components (or even Materialize as a whole).
A Materialize build which imports jQuery in such a way that $ and jQuery are not in my project's global namespace. This is important because I don't want my team to start using jQuery simply because they found it hanging around as a global - it's a secondary dependency of Materialize, not an explicit dep of my project - which is not well-expressed by the requirement to globally import jQuery in the document <head>.

As a stepping stone that I think could assuage many people's concerns over jQuery here and in #877:

This project could distribute a custom build of jQuery
Or otherwise as an even nearer-term solution, give people the needed info to produce their own reduced jQuery builds.

What's needed to do this is an up-to-date list of jQuery modules that Materialize absolutely depends upon and/or can safely be excluded from the jQuery build.

kriscooke on 4 Dec 2016

👍5

@Dogfalo whats your opinion?