Drupal 8 will only support IE8+, which mean that we can use querySelectorAll and querySelector in core javascript. This is the main use we have for jQuery in core. This is about core javascript, this is not about removing jQuery from the whole Drupal ecosystem. See at the end for what this issue means for contrib and module maintainers.

Current problems

  • jQuery is big: 32kb of javascript that you have to load on every page that has any javascript added with drupal_add_js().
  • jQuery takes a long time to load and execute on mobile, not having that would greatly help front-end performance (we're talking about at least 200ms on mobile).
  • It is not possible to use Drupal without jQuery. The only way to do that is rewrite all core JS you're using.
  • Not using jQuery will lead to more javascript code in core. This overhead will be much smaller than jQuery's 32kb.
  • jQuery drains the battery life of a mobile phone much more than targeted javascript: http://www2012.wwwconference.org/proceedings/proceedings/p41.pdf

    Using Javascript libraries simplifies web development, but increases the energy used by the resulting pages.

    shrinking Javascript on a mobile page to contain only functions used by the page greatly reduces energy use.

Details

  • A few wrappers for DOM manipulations and AJAX calls will be introduced for ease of development.
  • This is not about NIH. Small and specialized third party libraries will be used when necessary. Events are a good example of something we won't be doing all over again.
  • Depending on how things goes, wrapper functions could be considered private for core use only. We're talking about something like 10-20 helper functions to make the DOM more friendly. Contrib should not assume anything is provided by core at this level.
  • There is now a javascript maintainer to take care of nasty JS bugs.

Benefits

  • The amount of javascript loaded will be much smaller overall. This will make the browsing experience on all device faster.
  • querySelector and querySelectorAll are faster than sizzle. Yes there are quirks to it but nothing impossible to manage.
  • Contrib will be able to use the latest and bestest jQuery/UI version at all times (See notes below).
  • This will help people used to other libraries get into Drupal.
  • Hopefully this will attract non-drupal JS developers that we need.
  • This is about making Drupal "fast by default", not about making contrib life harder.

Notes

You're probably thinking that now every single module will have to depend on jquery_update/jquery module. Since it is not in core anymore, don't forget that jQuery can be added with info files at the theme or module level.

Since so much of contrib relies on jQuery, it's possible to add a drupal_add_jquery function, pointing to google CDN or another more appropriate CDN. As long as the actual jQuery source code is not in core and that core code does not depend on jQuery. That means contrib will simply need to call this function to get jQuery on the page. This would be a bit similar to the current jQuery UI situation: provided by core but not used by core.

Also loading from a CDN mean it's likely that the file is already in the browser's cache.

I'd like to say it clearly, I'm not against jQuery as a library. I actually like it very much, that's the point! I'm against the fact that it's required in Drupal and that it means we're stuck with an outdated version. Newer jQuery version have performance improvement and nice API additions.

Changes for Contrib

  • If we introduce a drupal_add_jquery function in core, as a module maintainer you'll only have to call this function when adding your own javascript and things will work just like before.
  • If we don't have this function in core, your module will have to add the "jquery" module as a dependency. This "jquery" module will provide the jQuery library for you to use.
  • In both situation you will be able to use the latest jQuery version and core will work. Core will not break because of a jQuery API change like it's the case right now.
  • This issue will not make you rewrite all of your module's javascript.
  • It will make you add a either 1 line of PHP or 1 dependency.

Once again, this issue is about removing jQuery from core javascript. This is not about removing jQuery from the Drupal ecosystem, jQuery is incredibly useful, is welcome and has it's place in the community. D8 core has new requirements that jQuery doesn't address as well as before, that's all.

Current status

There have are a few things planned once #1737148: Explicitly declare all JS dependencies, don't use drupal_add_js (or something alike) is in:

Basically this is about removing the need for jQuery on high-profile JS files so that it won't get loaded all the time if it's not needed.

CommentFileSizeAuthor
#42 js-usage.drupal.ods21.03 KBnod_
#31 core-js-no-jQuery-1541860-31.patch5.59 KBnod_
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented

That's... bold.

I see where you are coming from, but I don't see the point of rewriting jQuery / partially forking its API for our own benefits. There are several libraries that promise to implement a lightweight version of the core jQuery API (especially Zepto.js and jquip), we should use one.

Core not depending on jQuery is a noble goal, but we can and should depend on a $(selector) that provides nicer DOM traversal and manipulation then the dreaded DOM API.

While we are talking about the Javascript infrastructure, there are libraries to consider too. Underscore, most notably, could make *many* of our Javascript cleaner and less bug prone.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

The DOM API isn't very nice to work with but can be made easier with some suggar methods. I would prefer talking about introducing a new dependency after it's obvious we can't use good old JS first.

As for zepto and jquip, those are good ideas, unfortunately they are jQuery-specific. AMD would be better if we're talking about modularity: #1542344: Use AMD for JS architecture.

I agree that underscore could be good to have, if you have good examples of what could be made cleaner/simpler that would be nice.

msonnabaum’s picture

msonnabaum CreditAttribution: msonnabaum commented

Why is Zepto being jQuery-specific a bad thing? And how does that relate to AMD at all?

Your main arguments against jQuery seem to be filesize and the selector engine. Zepto is 8.4k and uses querySelectorAll.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Zepto itself doesn't support IE at all and recommends loading jQuery on IE, so it's a no-go.
jquip makes bits and pieces of jQuery and adds underscore and possibly spine, backbone qwery and q to the party. So much for removing dependencies. Also the whole jQuery API is not implemented in jquip, contrib will have to load jQuery to be sure a specific plugin they can't live without is working.

Assuming someone is developing a plugin against jquip, it might want to declare which pieces of jquip it needs, he'll need to define a library or use several drupal_add_js. I'm saying AMD is better at this kind of job. It's likely that an other module will need the full jQuery though, making it load almost twice the code. So it's not a great solution either.

I'm claiming we don't need a library and that all we need is a set of sugar methods to make development nicer (actually, that'll make minification more efficient). By all mean, if you find a case where not using a library like zepto or jquip will make the size of the js we load on a page the same or heavier, tell me. Until then I don't think we need to start considering those solutions.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Actually I have an example.

Here is a library to bind and fire events, it's 1.6k before gzip and looks like it does the job (haven't tested it yet), also it's developed against IE8+: https://github.com/arexkun/Vine. from the doc and source it looks like the kind of thing I'm looking for.

jessebeach’s picture

jessebeach CreditAttribution: jessebeach commented

You mention there are quirks to querySelectorAll, here's one. Check out the unexpected context behavior when chaining.

<!DOCTYPE html>
<html>
	<head>
		<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
		<title>Context demonstration</title>
		<script>
			window.onload = function (e) {
				var a = document.getElementsByTagName("div")[0].querySelectorAll("div span");
				a[0].innerHTML = 'This should not work if context in chaining is respected, yet it does.';
			};
		</script>
	</head>
	<body>
		<div><span>I am just a span.</span></div> 
	</body>
</html>

This is the nice part of a library like jQuery (and therefore Sizzle), that abstracts these quirks and just let's us code.

I will always be an advocate of pluggability. Just because jQuery is the go-to library today does not meet it will be 3 years from now, or even a year. But big libraries are big because they incorporate a lot of learning - lots of smoothing out and bug fixes.

What I don't understand right now is if you'd like to trade 35kb of jQuery with 25kb of other libraries. And then encumber the core developers with yet another sub-system to grok for 10kb of savings.

Are you proposing no js libraries in core? Just straight JavaScript?

jessebeach’s picture

jessebeach CreditAttribution: jessebeach commented

Without a common library, how would we deal with the explosion of library versions?

What I mean is, if every module maintainer is now burdened with decision to include js libraries because they can't depend on one being present, then we'll end up with a mishmash of libraries, and within them versions, in the contrib space. Yes, having jQuery baked into core means our version will always lag the bleeding edge. Yes, it also means that Mootoolers and Prototypers and Yahooligans have to jump through hoops to get their preferred tools in place. But that's a tradeoff of standardizing.

I intuitively feel that the direction you want to go will make Drupal more modern and agile. I'm having a tough time understanding how the day-to-day life of a module dev and themer will change as a result of these proposals.

Is there any sandbox work you can point us to?

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Yep, just updated the issue. I'm proposing straight JS and wrapper functions. For things that are still messy like events we should be using a third party library which will provide wrappers with hopefully sensible names.

For this querySelector thing it actually makes sense if you take it for what it is, a CSS selector. Interpreting from right to left it makes sense this element would be selected. Now it's not what one could expect and that's why you can use ":root > div span" on most browsers, just not on IE8. I'd like to see if this is a real issue with the js we have in core before giving up and relying on a library.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

@jessebeach: that's pretty much the jquery_update situation, no? I added a part about maintainers in the issue summary.

jessebeach’s picture

jessebeach CreditAttribution: jessebeach commented

re: #9, that is the jquery_update situation, but the update happens wholesale for the installation and is not managed by each module.

paul.lovvik’s picture

paul.lovvik CreditAttribution: paul.lovvik commented

I would be very careful about moving away from jQuery. For the most part, JavaScript developers that use jQuery do not obsess about memory leaks. They still exist, are incredibly easy to create, and can be incredibly difficult to fix. With jQuery you get this improvement effectively for free.

Also, the magic of jQuery and the reason it is so popular is because it creates a common way of addressing elements in the DOM. Compare the DOM API with the selectors that you use for CSS. jQuery allows you to address the elements the same whether you are theming the elements or giving them dynamic behavior. It marries the different technologies together under a common interface.

When I hear you talk about getting rid of jQuery and replacing it with wrapper methods, it makes me think we are going to have a less compatible, less useful, less performant version of jQuery that mimics the underlying DOM API. That is is possible to do, but isn't really a move forward in my mind.

Shoseki’s picture

Shoseki CreditAttribution: Shoseki commented

Hiya,

Thought I'd just jot down my concerns, by all means shoot them out of the sky if you don't feel they merit attention.

My concern is, not only that contrib uses jquery, its that it *doesn't* use other libraries, it also *doesn't* use other versions of jquery unnecessarily.

Part of the challenge of Javascript development for a CMS (most of this comes from a Joomla perspective) is that if every module just uses whatever libraries it feels like, you end up with mootools and/or jquery and/or dojo and/or underscore/backbone just randomly thrown together.

The web page is a shared resource and difficult decisions need to be made to ensure that the JS stack remains as simple as possible.

Joomla's hell is that you download 4 more modules, they might even use 2-3 different versions *of the same library*, or from different CDNs, or pollute the global namespace etc so that each module can "just get its little piece of functionality in".

For my money, effort would be better put to testing the different stacks, and deciding going forward how the overall "app" is going to function, I think getting AMD and an MVC/MVVM style overall stack would be of great benefit, but then there are so many to choose from...

(Plus a lot of developers, such as myself, have used jquery extensively and love the sheer number of available plugins / ease of developing new plugins, and worry about trying to integrate that with random contrib modules depending on other libraries...)

TLDR : We need to avoid tragedy of the commons, by deciding as much as is feasible up front how the overall stack is defined...

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Wherever this issue is going we're not getting away from a full JS review of core code. What I'd like here is to see what we're currently using of jQuery, if we need to and if there are lighter alternatives available.

If there is a good library (small and specialized) already doing dom manipulation, i'll happily give up the wrappers I was talking about.

The point here is how much code do we really need from jQuery to do the things we do in core? I've been reviewing code all over core and I'm not sure we're using that much things. Also, jquery is slower than good old JS in some critical places we're using all over the place:
http://jsperf.com/each-vs-array-foreach (looping through results with .each() is in every single js file we have either explicitly or not).
http://jsperf.com/drupal-dom-selector/17 (minding the IE8 quirks, this particular test is from the document so it's exactly the same, no surprises).

Those two things amount to changing $('selector').each() into a querySelectorAll and a for loop, big perf bonus for hardly any cost, maybe it's a couple more lines than before, but it's worth it.

It doesn't matter to me if we keep jquery.js in core because we want modules to be able to use it, we're doing just that for jquery ui already. But I'd like it out of our core JS files. So that people who don't want to use it can, to speed page loading and to speed up our JS.

For the joomla's hell, well that might be because of poor coordination. I don't expect merlinofchaos to rewrite all his JS to make me happy, I'm sure he'll be shipping his own because that'll annoy the hell out of him to make ctools depend on another module. Since everybody uses Views…

jessebeach’s picture

jessebeach CreditAttribution: jessebeach commented

Ok, sorry for being dense. I'm beginning to understand. You're not proposing taking jQuery out of core. You're proposing to make core less reliant on jQuery in order to increase performance. That makes sense. It is definitely true that removing jQuery.each() wherever possible is an improvement.

As a second, related effort, you want to improve the performance of loading libraries and their dependencies. I also support this. Details aside, it's a positive goal.

The HTML5 initiative is a great example of the effort needed to make lots and lots of small changes around core.

http://drupal.org/node/1193054

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

This is definitely the first step. It's the logical continuation of the current clean-up patches (that need reviewers!).

Ultimately the goal is to remove all jQuery usage from our core javascript files. I just don't know how far along we can go yet. Help me out with that and I'll make sure we get some new javascript people into Drupal.

Thanks for the tip, putting that kind of thing up will definitely help with tracking what's going on.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
Issue summary: View changes

add contrib info

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented
Issue tags: +mobile

I for one would like the ability to switch between jQuery and Zepto depending on the browser being used or the functions I require. The fact that the page weight of every Drupal site is getting heavier and heavier will be unacceptable if we are seriously pushing Drupal 8 as a mobile friendly platform.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

I don't think we can reasonably switch one or the other. That'll be a nightmare to maintain, and I'm the maintainer.

A very interesting talk about this topic: http://vimeo.com/40873227

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

Since so much of contrib relies on jQuery, it's possible to add a drupal_add_jquery function, pointing to google CDN or another more appropriate CDN.

This largely isn't necessary, as we already have hook_library() to form dependencies on other libraries. jQuery itself is already defined as a library, but nothing is marked yet as depending upon it because it is assumed to be loaded on all pages. See system_library() for information.

I think a lot of the advantages listed here are a bit overblown. Mobile browsers are hardly any slower than desktop counterparts. With the reach of 3G already and LTE in the near future, a lot of people's mobile connections are as fast as their home internet connections. The assumption that all JS files need jQuery may be inaccurate (there may be 10-20% of JS files in core/contrib that could be done easily without it), but it's extremely likely that at least one file on the page will stil require jQuery.

Depending on how things goes, wrapper functions could be considered private for core use only. We're talking about something like 10-20 helper functions to make the DOM more friendly. Contrib should not assume anything is provided by core at this level.

This sounds like we're re-implementing just the parts of jQuery we need, but not allowing any other modules to use it, thus increasing duplication and code size. Considering most contrib modules will still require jQuery anyway like I said above, this would be completely unnecessary overhead and maintenance.

So the summary of advantages here:

The amount of javascript loaded will be much smaller overall. This will make the browsing experience on all device faster.

While unlikely this would be the case, this patch would at least make this possible.

querySelector and querySelectorAll are faster than sizzle. Yes there are quirks to it but nothing impossible to manage.

Sizzle will use the browser features if they exist, but then layer on the compatibility. The slowness here essentially *is* the compatibility, which is why it's useful.

Contrib will be able to use the latest and bestest jQuery/UI version at all times (See notes below).

I don't see this patch having any real effect on the jQuery/UI version situation. Modules can already update or use external versions of jQuery/UI through hook_library_alter(). It's not difficult to write jQuery that works across the board for different versions of jQuery. If we encounter an incompatibility in core files, backporting a fix isn't out of the question.

This will help people used to other libraries get into Drupal.
Hopefully this will attract non-drupal JS developers that we need.

I'm not sure this is really true. You can already use other libraries *in addition* to jQuery, though it means that you're loading two instead of one. Considering the use of jQuery through contrib, the dual-dependency isn't really likely to change.

This is about making Drupal "fast by default", not about making contrib life harder.

This last point I can agree with. Reducing usage of jQuery in core files will certainly make things faster. I just don't think that removing the dependency on jQuery is practically possible.

So in short, I think you could raise a lot fewer eyebrows and pushback if the point of this issue was "Do not add jQuery automatically to the page" and a separate issue for "Reduce use of jQuery in core JS files for performance". Removing the dependency on jQuery entirely isn't going to give us as many benefits as using it does.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

  • This largely isn't necessary, as we already have hook_library() to form dependencies on other libraries. jQuery itself is already defined as a library, but nothing is marked yet as depending upon it because it is assumed to be loaded on all pages. See system_library() for information.

    It was merely a suggestion. I don't care how it's implemented, I just want people to know this solution exists.

  • I think a lot of the advantages listed here are a bit overblown. Mobile browsers are hardly any slower than desktop counterparts.

    That is not true, on mobile it's 10 times slower, and i'm not just quoting, I actually measured the thing. Some of our JS takes seconds to execute on desktop, it's not fun loading them on mobile.

  • With the reach of 3G already and LTE in the near future, a lot of people's mobile connections are as fast as their home internet connections.

    By a lot you mean China and India? We're not all living in a country with awesome 3-4G mobile connections all over the place.

  • Sizzle will use the browser features if they exist, but then layer on the compatibility. The slowness here essentially *is* the compatibility, which is why it's useful.

    We're allowed to move things around to make this work and without dirty hack, just by thinking more than 2 seconds before slapping a jQuery selector to do the job. Also, make your own benchmarks, Sizzle is always slower, even for very simple selectors like #id, especially for simple selectors. The slowness is not the compatibility, otherwise it wouldn't fare that bad on proper browsers.

  • This sounds like we're re-implementing just the parts of jQuery we need, but not allowing any other modules to use it, thus increasing duplication and code size. Considering most contrib modules will still require jQuery anyway like I said above, this would be completely unnecessary overhead and maintenance.

    I'll consider this once we can see how much code we're talking about. Until then there is no way to say one solution or the other is better. And you're probably thinking i want to wrap some crazy stuff. No, I'm planning on keeping it simple. I've read through all core files a good number of time now, we're not using as much jQuery as you'd think.

  • backporting a fix isn't out of the question.

    Not having to backport anything is even better.

  • I'm not sure this is really true. You can already use other libraries *in addition* to jQuery, though it means that you're loading two instead of one.

    What about the guy who wants to use YUI and still have a fast page load? too bad for him? That's not very nice considering it doesn't have to be this way.

  • Considering the use of jQuery through contrib, the dual-dependency isn't really likely to change.

    That's what you're saying. I'd want to have a site light on the JS I'd chose my modules acordingly. And jQuery plugins are not that great of quality either. I've read through ctools/views JS more than I'd want to, it's the same thing as core, not using jQuery much either.

  • I just don't think that removing the dependency on jQuery is practically possible.

    Well, that's not my opinion.

  • Removing the dependency on jQuery entirely isn't going to give us as many benefits as using it does.

    I'll let the people from the mobile initiative answer this one.

(edit) the blockquote spacing sucks.

rupl’s picture

rupl
he/him
Primary language English
CreditAttribution: rupl commented

With the reach of 3G already and LTE in the near future, a lot of people's mobile connections are as fast as their home internet connections.

This is an assumption that assumes Drupal prefers a first-world audience. It's a really well established fact that mobile latency is much worse than traditional connections.

Separately, I would like to point out that jQuery 1.4.3 (released Oct 2010) and newer rely on native querySelectorAll() when available. Sizzle is only used when the browser can't hang :) From the release blog post:

Note that the the browsers shown are those that actually support querySelectorAll or matchesSelector – existing browsers that don’t support those methods continue to have the same performance characteristics.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

I just don't think that removing the dependency on jQuery is practically possible.

Well, that's not my opinion.

@nod_: If you're up for the task then have at it. Are you planning on eliminating core's use of jQuery dependent libraries also?

jquery.ba-bbq.js: Used in Overlay for back button support.
jquery.form.js: Used in any AJAX-submissions of forms, typically through #ajax.

We've got $.ajax() calls in at least 5 core JS files, are we planning on a library for that or implementing them manually?

This proposal also seems to mean that any attempts at replacing Drupal core's custom implementations with jQuery UI equivalents (progress bars, date pickers, and autocomplete) would be abandoned, if core is not going to be dependent upon jQuery.

#1477550: Bring progressbar to the postmodern era (in which you said you favored using jQuery UI, which I'm not understanding considering your opinion in this issue)
#504524: Extend Authored on field with jQuery UI Date Picker
#675446: Use jQuery UI Autocomplete

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

history.js is better than bbq and doesn't rely on jQuery
jquery.form.js, look at the source the hard part (file upload) is copy/paste from Yahoo code.

ajax, a simple wrapper will do.

progressbar will use html5 progress tag, no JS since it needs to be available with js disabled.
datepicker, <input type="date">
autocomplete is stuck because ui is not accessible enough, ours works better.

The several UI issues have just no traction whatsoever. jQuery UI is useless to us (beside dashboard).

And yeah, I'm prepared to rewrite everything by myself if I had to, so that's happening.

ao5357’s picture

ao5357 CreditAttribution: ao5357 commented

Some of our JS takes seconds to execute on desktop, it's not fun loading them on mobile.

The point here is how much code do we really need from jQuery to do the things we do in core? I've been reviewing code all over core and I'm not sure we're using that much things.

To me, these quotes combined don't work to build an overall case against jQuery. It sounds more like the current (according to nod_) non-jQ JS is slow, not that jQuery is inherently the problem. Also, I'm interested to know whether jQuery best practices (caching then traversing, for instance) could speed up some currently-slow code.

With regard to selector engine: quicksketch and others are right that jQuery uses modern constructs and only falls back to Sizzle, but nod_ is right that it's still slower, since instantiating jQuery objects is part of the process. Part of that performance loss can be remedied by aggressively caching jQ objects and using the library to its full potential.

It's conceivable that wrappers/sugar methods/libraries could replace just a selector engine, just $.ajax, or just effect/manipulation/traversal methods (used at least in ajax.js), but taking #1446166: Use JS events instead of Drupal.behaviors with regard to events, I wouldn't say that saving within a 32kb window is a foregone conclusion.

Since most people seem to agree that contrib is likely to use jQuery overwhelmingly, at least for the near future, and that fragmentation could be an issue if jQ weren't endorsed and supported by core, the case for core support is strong, if not core usage. Support for .on() to delegate bubbling events from #1446166 is a compelling reason to use jQuery in core JS when all other factors are combined, I believe.

jQuery API usage can be future-proofed to some degree. However, the necessity of that brings up a question that's interesting (to me): is there a way to upgrade the core version of jQuery (CDN or not) incrementally within a major version (D8 specifically) without being a nightmare for contrib? Any ideas?

Mobile is sort of a lose-lose scenario for client-side code. You have to worry about both payload and performance. Which is the bigger worry? Consider these two scenarios:

  • Core functionality written in 1k to take advantage of jQuery (+32k)
  • Same functionality in 3k of old-fashioned JavaScript that depends on +20k of [necessarily excellent] sugar and small libs

How much would jQuery have to be used to make this a value proposition? At that point, how much performance difference is acceptable? Is readability and ease of contribution a factor? These seem like reasonable questions to ask and test.

IceCreamYou2’s picture

IceCreamYou2 CreditAttribution: IceCreamYou2 commented

The vast majority of contrib modules use jQuery -- the same version of jQuery -- and that is a good thing to avoid fragmentation and bugs while enforcing consistency. Because of this, most Drupal installations (and definitely the ones that really need to care about speed) will be loading jQuery anyway. This means the only net effect of replacing jQuery in core with our own wrapper functions will be adding more JS than we already have because we will be loading jQuery plus our own wrapper functions. That is surely not a good thing.

I support the goal of using native JS instead of jQuery in core where it will make core faster. However, making core JS faster should be the goal. Removing jQuery is a silly distraction because it is neither realistic nor a good idea to get contrib to stop relying on it.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

My first impression of this is somewhat similar to quicksketch's here:

This sounds like we're re-implementing just the parts of jQuery we need, but not allowing any other modules to use it, thus increasing duplication and code size. Considering most contrib modules will still require jQuery anyway like I said above, this would be completely unnecessary overhead and maintenance.

i.e. that a very large number of sites will end up using jQuery anyway, and depending on what core's js weight looks like without it, it'd end up being a net loss for them since they'd end up with the smaller core stuff + jQuery anyway, however:

- it'd be good to remove the magic adding of jQuery from drupal_add_js(), we already have the libraries dependency system to do this, just special case it and don't use our own API, or move to AMD - either way it's not necessary any longer to have that magically included.

- it seems feasible that some pages in core should not need to load jQuery at all (i.e. a site that uses google analytics and doesn't have any js on it's visitor facing pages), if there's some files that make this not possible at the moment (i.e. they're not mainly aimed at admins/editors and they're not really using jQuery anyway) then removing the jQuery dependency from those files seems reasonable. But that feels like case-by-case clean-up to me?

- the fact we almost immediately lag behind as soon as we release major core versions is really annoying, and jquery_update currently has to do quite a lot of work (and itself can lag behind quite often). However there was some discussion of adding jquery_update to core in http://groups.drupal.org/node/210973 and the actual jquery_update maintainers were not at all keen. Some way of making this less painful would be good, but I'm not sure removing jQuery from core is it (since you'd still have the issue that jQuery's release cycle is so much faster than core's and many contrib modules, with the CDN option as much as anything else).

ao5357’s picture

ao5357 CreditAttribution: ao5357 commented

What if core's javascript was 'versioned' in directories by jQuery version support, and modules that use jQuery put the highest version they support in their .info files? Then, sites would auto-upgrade to the highest-supported jQuery version when all modules are sufficiently upgraded. There would still be a lag, on a site-by-site basis, but Drupal wouldn't be locked at the core level to a particular version of jQuery.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

I agree with @quicksketch and @catch. We are just going to *increase* the size of the payload for real sites with contrib modules, since those would keep using jQuery. If they don't keep using jQuery, then it will be even bigger of a payload, since they will use different libraries, like argued above.

Also, I'd add that beginner or non-JS-savvy contrib developers copy-paste code from core and modify from there. If we don't use any library in core, at the point they'd need some functionality, they'd easily turn to some other library but jQuery. The "suggestive power" of existing code in core is very strong.

rooby’s picture

rooby CreditAttribution: rooby commented

What if core's javascript was 'versioned' in directories by jQuery version support, and modules that use jQuery put the highest version they support in their .info files? Then, sites would auto-upgrade to the highest-supported jQuery version when all modules are sufficiently upgraded. There would still be a lag, on a site-by-site basis, but Drupal wouldn't be locked at the core level to a particular version of jQuery.

I think you would run into issues. For example, what if you have some modules that need an old version and some modules that don't work with that old version, then what? One of the modules will break.
There might be cases where you could get by running different version of jQuery in different areas of your site, which while possible, is not a fun proposition.

I'd be apprehensive about any solution involving multiple versions. Of any library for that matter.

Stolzenhain’s picture

Stolzenhain CreditAttribution: Stolzenhain commented

+1 for not forcing jquery on the frontend theme workflow; I sometimes had to implement several versions of jquery at once (as a hotfix) to keep re-used functions running over multiple sites while battling mobile caching with the regular script set already.
Drupal and jQuery both made rather progressive development decisions in the past which they should be allowed to continue.

bojanz’s picture

bojanz CreditAttribution: bojanz commented

I agree with #27. This just strikes me as odd.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
FileSize
core-js-no-jQuery-1541860-31.patch5.59 KB

First things first. I'm always listening for the concerns you have and will address them as soon as I can. On the other hand, it doesn't matter which point you're trying to make, you need to do your homework and come up with data backing up your arguments. I am not stupid, I change my mind when I see good data showing I'm wrong. Data first, then we can talk about changing the plan.

#23: it's your opinions, please show me benchmarks/rewrites showing jQuery is not as bad as I make it to be. The reason why I want to take everything apart it to only use what we need. I'm hoping we can split events into event binding and custom events firing at least. You have always been able to do event delegation in JS. jQuery is not magical. Your last questions needs answers, let me know if you have others, i'll address them at some point in the process.

#24: read the issue summary please. Contrib is a big boy it can get organized, have some faith. We can always force them to organize if faith doesn't cut it.

#25: as the js maintainer it's either freezing the version or not using jQuery. Anything else will be a real pain to deal with. But yes, there are a few files we can start with to limit the overhead. Not using jQuery.extend() for settings for example. That's nuking any effort to not require jQuery everywhere.

#26: Sorry to say that but it's just crazy, maintaining several time the core codebase for different versions? I'd rather break my leg. I understand it was a long shot, better leave it at that :)

#27: Let's talk at events, you won't need to load core event binders, jQuery already has that. And if we're using AMD, you'll be able to overwrite any library/dependency on the page to provide your own binding functions. So no, you won't have to use/load core JS files as long as you do some work to replace the wrappers with you lib's code. Yes I know the suggestive power is strong. That's the whole point, we don't need to rely on jQuery like before, contrib needs to know that for D8.

#28: +1

#23, #24, #25, #27: I think I can close the size argument. Core JS will be minified so it's entirely possible the overhead of my wrappers/longer non-jQuery code will fit into the current whitespace/comments overhead. If it doesn't then it'll be way under 20k on every page like #23 makes it to be. Also refactoring the code will cut a lot of cruft we currently have, reducing the whole size.

And here is the rewritten version of toolbar.js a pretty serious suspect of requiering jQuery all over the place. So this code need a polyfill of 850 (before gzip!) something byte on IE8 to use classList. we can do that the good old way as well it's a POC. Does the patch look so horrible?

(edit) actually after the patch this file minify better and I'm not even trying to code to optimize minification. So much for overhead. And I don't need the 32kb of jQuery to do that.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

#23, #24, #25, #27: I think I can close the size argument. Core JS will be minified so it's entirely possible the overhead of my wrappers/longer non-jQuery code will fit into the current whitespace/comments overhead. If it doesn't then it'll be way under 20k on every page like #23 makes it to be. Also refactoring the code will cut a lot of cruft we currently have, reducing the whole size.

That might pay for the cost of the duplication relative to Drupal 7, but it would still be more than if we do all those things but don't duplicate, comparing two hypothetical Drupal 8 releases.

From a performance point of view it only makes sense to me to do this if we think there's a realistic chance that pages can be served without including jQuery on real sites - doesn't have to be the entire site, but front page, node pages etc. are good candidates to look at. Then it comes down to the relative trade-off, and how much extra weight there actually is from the wrappers on sites where jQuery is included.

Right now looking at the front page, it looks like the only things explicitly added with drupal_add_js() are html5.js and ajaxPageState settings, so seems like settings and removing the default loading would be enough to actually avoid loading jquery.js?

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Nope, you have drupal.js that needs jquery to do something unrelated (need to be taken out to another file). and as soon as you're admin you have jquery.once.js, contextual.js, toolbar.js jquery.cookie.js that comes to the party.

Then the one you're more likely to run into are more or less in order: tableheader.js, filter.js, file.js, text.js, vertical-tabs.js, contextual.js, user.js, overlay.js and so on. None of these do crazy things, it's on the same level as toolbar.js

The crazy script to rewrite is tabledrag. But that's mainly because it's such a mess, not really jquery-specific.

Comparing to a possible clean Drupal 8 code is cool and all, but who's going to code that? not going to be me. It's already painful enough to get normal patches in because of no reviewers. Refactoring stuff and keeping jQuery around will be as hard as making this patch get in. That's not worth it for me.

(edit) less obnoxious.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

Sorry #32 wasn't very well written.

The only explicit call to drupal_add_js() in Drupal 8 with a vanilla install, is for ajaxPageState.

The first time drupal_add_js() is called with $data set, it adds drupal.js and jquery.js itself, along with a couple of other settings, calling itself recursively, however if we didn't add ajaxPageState as a setting in the theme layer, it wouldn't get called at all.

In Drupal 6, with a vanilla install, there's absolutely no js loaded at all, so it's a clear regression in D7 and 8 at the moment.

attiks’s picture

attiks CreditAttribution: attiks commented

I disabled the adding of ajaxPageState to the page and after removing it from drupal_get_js, drupal_get_css and drupal_theme_initialize, I didn't get any javascript inside my pages. I think this is something that needs to be fixed, but I'll create a new issue.

The 'problem' is that from the moment you'll enable 'Contextual Links', 'Overlay' or 'Toolbar' everything gets added if the user can use any of these. So what's left to gain by replacing the jQuery functions for a custom solution is the 'overhead' for logged in users with enough permissions?

I'm all in favor of a lean and mean Drupal core and Drupal shouldn't output any css/js unless absolutely necessary.

diff --git a/core/includes/theme.inc b/core/includes/theme.inc
index 6872600..f9dc9d3 100644
--- a/core/includes/theme.inc
+++ b/core/includes/theme.inc
@@ -109,7 +109,7 @@ function drupal_theme_initialize() {
     'theme' => $theme_key,
     'theme_token' => drupal_get_token($theme_key),
   );
-  drupal_add_js($setting, 'setting');
+  // ATTIKS drupal_add_js($setting, 'setting');
 }
 
 /**

diff --git a/core/includes/common.inc b/core/includes/common.inc
index 08ce2ab..7b0018a 100644
--- a/core/includes/common.inc
+++ b/core/includes/common.inc
@@ -3063,7 +3063,7 @@ function drupal_get_css($css = NULL, $skip_alter = FALSE) 
     '#items' => $css,
   );
   if (!empty($setting)) {
-    $styles['#attached']['js'][] = array('type' => 'setting', 'data' => $settin
+    // ATTIKS $styles['#attached']['js'][] = array('type' => 'setting', 'data' 
   }
 
   return drupal_render($styles);
@@ -4239,7 +4239,7 @@ function drupal_get_js($scope = 'header', $javascript = NU
 
   // Provide the page with information about the individual JavaScript files
   // used, information not otherwise available when aggregation is enabled.
-  $setting['ajaxPageState']['js'] = array_fill_keys(array_keys($items), 1);
+  // ATTIKS $setting['ajaxPageState']['js'] = array_fill_keys(array_keys($items
   unset($setting['ajaxPageState']['js']['settings']);
   drupal_add_js($setting, 'setting');
nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Agreed, but out of scope, see #1279226: jQuery and Drupal JavaScript libraries and settings are output even when no JS is added to the page. That doesn't solve filter.js, tableheader.js, ajax.js, drupal.js which are very much possible to be used for anonymous.

mfer’s picture

mfer CreditAttribution: mfer commented

@nod_ I have a couple real world problems I see with removing jQuery.

  1. Fragmented versions of jQuery. While having an old version of jQuery can really be a pain. It's even more painful to deal with different modules you want to install that rely on different versions of jQuery. This is especially true for site builders (a huge audience).
  2. A lot of Drupal developers don't know JavaScript. They know just enough jQuery API to be dangerous and get sites out. The fact that jQuery is bundled with Drupal is a bonus for these developers. How do you propose we address this? Note, expecting these developers to learn more JavaScript is a hard expectation to have. There seems to be a pull between low barrier to entry and empowering JS devs to have freedom to do stuff their way. If I had a vote I'd say low barrier to entry needs to stay.

Your concern about performance and JavaScript is a good one. One I really like. Some things we know:

  • Phones now take about 10x as long to execute JS as desktop computers. This has been measured and presented at conferences. Those same phones will be in use when Drupal 8 is released.
  • Less than 50% of the world has a 3g or better connection. This is improving rapidly but it brings into question our target audience. The problem with mobile networks isn't connection speed but in latency which can be 2 - 10 times that of a wired connection. Typically 4g and 3g networks have less latency and are on the lower end of that but it's still important to note.
  • End users don't care about the technical reasons. They still expect mobile site speeds to be the same as desktops. This is different from a few years ago where they were ok with it being slower.
  • Mobile device caches are so small you should expect stuff to be cached. For example, even if jQuery is on a CDN don't expect it to be cached. Instead expect it to be downloaded at CDN speeds.

When it comes to real world site building I wonder if removing jQuery will end up with us having a more complicated setup hurting performance. For example, if a typical site includes 2 different versions of jQuery to support 2 different modules you are now in a worse place than you were originally. Or, if you have jquery plus a support library for common DOM stuff in Drupal. You end up with more JavaScript sent to users.

I'm all for speeding up pages and strategies to remove jQuery from some pageloads where it's not needed. But, I'd like to keep everything as simple as possible with a lower barrier to entry. Removing jQuery looks like it could complicate things and lead to more fragmentation.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

Another +1 for optimizing the page load, ensuring JS is not loaded unnecessarily and improving documentation & best practices, and +1 for not removing use of jQuery.

Remember, Drupal 8 is a year+ away and its widespread adoption probably another 6 months after that, so don't hamper Drupal today when we're aiming at a market 18mos from now. Don't forget that networks will always improve and browsers will always improve.

In summary: IMHO this just feels like going too far down the road of premature optimization.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

1., 2. just ship drupal with javascript. It'll be the same as what we have for jQuery UI. We provide it but don't use it. I don't expect people to learn JS unfortunately. I just want Drupal out of the way we'll be free to decide whatever after that.

major +1 to speed concerns.

I'll crunch some numbers about core js usage. That'll be fun, I'll be able to tell you what we have right now how often it's used, where and how big it is for most (if not all) admin pages. And maybe with some work i'll be able to estimate what it will be after the rewrite. That'll take some time, don't hold your breath.

attiks’s picture

attiks CreditAttribution: attiks commented

1., 2. just ship drupal with javascript

I think you mean ship drupal with jQuery but don't actually use it.

Also really include it in the download, don't force some CDN hosted version (intranets don't really like it)

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Yes, that's what I mean.

I'll have data to show jquery's impact on Drupal very soon, much easier than what i expected.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
FileSize
js-usage.drupal.ods21.03 KB

Here come data, I'm not very awake so be forgiving if I messed up things. You'll have all the data you need to check for yourselves and point out my mistakes. I'm not trying to distort anything I'm doing all of this in good faith.

So the principle is seeing which scripts are on which pages and how much js is loaded every time. The tl;dr; version: over 167 admin pages:
with jquery, no minification and no gzip:

  • average of 7 files per page
  • 111k per page

Substracting jquery.js filesize to the average: (This means i'm keeping 6.5k of overhead from jquery.once, jquery.cookie, jquery.form that should account for my wrapper function and 3rd party libraries planned).

  • Average of 6 files per page
  • 34k of js per page

There are a lot of page with almost no js that loads jquery. This is why the average is so low without jquery. Now considering my rewritten code minify better than the current core code, we're looking at some dramatic improvements over filesize.

Attached is the file i used to get this data. check my navigation timing sandbox to see how data was collected. I only used pages where JS and CSS were activated. If you have more questions about the protocol I'll be happy to answer them. There are data about the actual behaviors run for each pages in the attached doc. If you're interested I should be able to tell you how long each behavior takes to run.

So, what I'm proposing means a reduction of the average js size by 30% with speed improvements. Please be as specific as possible when giving arguments against this change. I'd be happy to give you the code I used to get this data so that you can do benchmarks.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

There are a lot of page with almost no js that loads jquery. This is why the average is so low without jquery. Now considering my rewritten code minify better than the current core code, we're looking at some dramatic improvements over filesize.

No one is saying that jQuery doesn't make the page size larger, or saying that it wouldn't be a good idea to reduce dependency on jQuery as much as possible for both size and performance reasons. Both of those statements are undisputed. However, I think writing custom implementations of things jQuery provides for us already is crazy. I think mfer summed it up best at the end of #37, so I won't rephrase it further.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

well what's your feeling about #31? is it much more complicated? is it not understandable? That's what a crushing majority of the changes will look like. I didn't get any feedback on that, was my patch that useless?

JamesK’s picture

JamesK CreditAttribution: JamesK commented

I think nod_'s argument is quite strong. This offers a way to make Drupal faster by default, with the only cost being that core's JS doesn't "look as pretty" (according to people who love jQuery).
Many of those who've replied to this topic don't appear to have heard what he is saying. People keep arguing against the same two misconceptions:
He is not saying we remove the jQuery library from core.
He is not saying we force module developers to use the same methodology that we use in core. (Although if they do, then it is a double win.)

Can we all agree that core JS should be as fast as possible?

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Status: Active » Closed (won't fix)

https://twitter.com/#!/paul_irish/statuses/195173286261424128

The JavaScript clean-up effort attacked some really good problems so far. This debate here appears to be too ambitious and overall fruitless. The pushback goes far beyond the technical proposal and it is well reasoned.

Adding to that, and I already stated so in IRC, it would be wrong to believe that it is "only us", and that the jQuery core development team wouldn't make mobile a top priority, especially given the recent market trends. In turn, by following this proposal, we would be losing standardization and compatibility (as well as a huge repository of plugins that can be integrated) by introducing custom solutions - whereas, at the same time, jQuery core would evolve on its own, solving the exact same problems we're (poorly) trying to solve on our own.

Various alternative options to improve Drupal core's JS have been proposed already, so I don't see any reason for continuing (and wasting badly needed contributor's time) on this proposal. Let's continue to work on those.

This proposal appears to come "too early." We can try again for D9 or D10.

Lastly, bold and good proposals are always welcome. Do not refrain from submitting your own merely based on this issue.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
Status: Closed (won't fix) » Postponed

Ok he's good but the guy don't even know the Drupal code base. I mean who actually read core JS around here? who read toolbar.js, ajax.js, contextual.js, text.js, file.js? all the files anonymous would likely to encounter?

Close this once you have a roadmap from jquery that fits with drupal 8 release. Don't just close it like that.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

Agreed with sun, especially given #1279226: jQuery and Drupal JavaScript libraries and settings are output even when no JS is added to the page will cover pages that don't need jQuery. Hint: for better mobile performance remove all JS usage :p

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
Title: Remove dependency on jQuery » Reduce dependency on jQuery
Status: Postponed » Active

For now.

We can still use perf boost from using proper loops and queryselectorall.

droplet’s picture

droplet CreditAttribution: droplet commented

I agree with @quicksketch & @Gábor Hojtsy & @mfer & Paul Irish
(but hoping we have a plan to update jQuery to latest version in CORE. Actually, some modules required jQuery_update and some is not. It's already a problem)

@#42,
May only reduce page size to a site never user jQuery at frontend.

D8.
Front end, Most page are load 3 files only. (#34, regression)
Back end, Is it mobile friendly ?? 34KB overhead is a big problem to admin users? (compare to rewritten with own code..etc)
Maybe more than 34KB after rewritten.

Performance. Fastest vs Acceptable. I choose Acceptable if it make core easier for maintenance. Not all code written in C.

eaton’s picture

eaton CreditAttribution: eaton commented

Drupal 8 will only support IE8+, which mean that we can use querySelectorAll and querySelector in core javascript. This is the main use we have for jQuery in core.

Yeah, no.

The opening post to this thread has some intriguing ideas, but those are wrapped up in a fair number of bad assumptions.

First, suggesting that we're only using jQuery as a shortcut for querySelector and querySelectorAll is a little odd. As quicksketch has noted above, we're making relatively heavy use of the ajax features of jQuery, jQuery-dependent libraries to manage UX interactions, and so on. We would have to reinvent all of those wheels using raw JS to keep core functionality.

Second, suggesting that moving away from jQuery will make Drupal more accessible to outside developers is a bit weird. jQuery is currently being used by 46% of the web. The whole web. All of it. While that doesn't mean that we should use it unthinkingly, there's a much larger pool of people familiar with jQuery than any other library, and certainly more familiar than they would be with our own custom implementations of things like AJAX callbacks and DOM manipulation.

Third, Drupal's contrib space already relies heavily on jQuery. Drupal has been using it for over five years, and the vast majority of contrib modules that have JS functionality of any kind use jQuery. They'd either have to be rewritten to avoid jQuery, or we'd be in a worse situation -- side-by-side custom raw JS AND jQuery dependent code, with overlapping functionality because most of contrib assumes that jQuery will be present.

Fourth, developers who really, really want to roll their own (or use non-jQuery libraries) can already do so by writing their own JS from scratch and using hook_library_alter() to ensure jQuery isn't added to the page. As several people have mentioned upthread, it'd be worthwhile to change Drupal's assumption that everything requires jQuery -- code that needs it would list it as a dependency, and it wouldn't be included unnecessarily. That would be a convenience, though, as it would only save developers from writing the alter hook to remove jQuery from the page.

Others have made these points quite effectively up-thread, but I wanted to pull them all together to specifically address those four assumptions, as they seem to underly the entire thread. If the flawed assumptions are abandoned, I'm not sure why we would bother rewriting all of our JS to avoid the theoretical reliance on jQuery on 'core-only' sites.

mfer’s picture

mfer CreditAttribution: mfer commented

First, I firmly agree that we can speed things up. How places to make individual speed improvements get identified and individual cases are open to each thing. Large all consuming issues seem to stall easily and be too wide open for people to toss things in. By keeping individual speed improvements to their own issues we can hopefully move faster and focus on each one.

Second, there is speed of development and speed of the page. In addition to that we have supportability. For certain tasks that we rely on jQuery we get test suite support (in addition to production for half the interwebs) and cross browser/feature compatibility. For us to maintain some of those features in a sane way will require a bunch of people who KNOW js really well and sign up to maintain it over the long haul. The way we've experienced gaps in available js devs who know js really well and have the time to work on core... I'm skeptical.

I'm all for improving speed. Just not at the expense of some of the other things we have going on.

neclimdul’s picture

neclimdul
He/Him
CreditAttribution: neclimdul commented

Path out

So I've got opinions on all this stuff but I think sun's right that this is a bit too ambitious. The title alone is just asking for scope creep and we're falling into it hand over fist. That said, nod_ is obviously an experienced javascript developer and as mfer said we need these sorts of people bad. Really bad. So rather then fueling this discussion and getting everyone frustrated lets give ourselves an out with some easy wins and some follow up discussions.

My suggestion:

  1. #1279226: jQuery and Drupal JavaScript libraries and settings are output even when no JS is added to the page
  2. split off the each/loop thing
  3. If you really think its important, an issue about replacing the jquery selector usage with native js selector functions.
  4. Other discussions about limiting js loading. maybe the AMD issue, maybe a way of specifying when you're using jquery for your js, or others, there's a whole tag for it apparently.
MrMaksimize’s picture

MrMaksimize CreditAttribution: MrMaksimize commented

I'm going to ++ #51 here. As a maintainer of a contrib module based on jQuery I'm not sure how I see this happening without a lot of mess. I'm not too familiar with AMD, but would that mean that every contrib out there depending on jQuery would have to also depend on libraries module in order to bring it in? Or have nasty custom implementations of it? What are we losing by having jQuery in core? I'm not sure I understand.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

@MrMaksimize: The point wasn't to remove jQuery from core but to just not use it due to the perceived belief it was too slow for mobile devices for a fully functioning site; note, the calculations & assumptions above ignored the volume of very common contrib modules & themes that depend upon jQuery, so presumably it would only benefit sites that only used core.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

#51 I hear your arguments. But I'm seeing a lot of people who assume things are in our JS. We have a lot (like everything but 5 files) of low risk/high reward js files using jquery for nothing much.

1. You focus on Ajax and DOM manipulation, that's great, but that's not what people encounter the most. drupal.js, toolbar.js, tableheader.js, that's what you'd see the most and the only tricky thing in these are events. not Ajax or DOM things.

2. That'll be the DOM, if people don't know their underlying technology I can't help them. Actually i'm not even asking them to understand it, you have people not getting PHP classes using views and search_api. This is the same, why should our JS be understandable by someone who don't even care? That's preposterous.

3. Side-by-side code: well turns out the overhead of this kind of situation would weight around 1K before gzip. so it's not as bas as you'd think. and with 32k+ they don't even care anymore about 1k of overhead.

4. If you don't give the opportunity you won't see what's possible, so that's kind of a moot point.

That's great to have that much feedback. It'd be even better if people actually read the code to see what's going on with jQuery in core. Have a look at my data, you have the numbers, you can see which are the most used files, start there.

#52, there are libs out there with maybe not the same coverage but with a test suite: https://github.com/fat/bean and this easily the worst thing to manage in JS cross-browser now. But yeah I understand your point.

#53, thanks.

#54, well you have a whole part dedicated to you in the issue summary, is that not clear enough? what is not clear enough? I've tried my best on this one, help me out.

#55 yeah and mobile-only websites, we have those around and they'll be more and more.

All of this is nice and all, but I'm waiting for #1532996: [Policy, no patch] Strategy for dealing with javascript in IE6/7 because depending on that it might just be impossible. If that's a go, #53 is a good plan and I'll prepare a massive issue with all the files and type of change we can make.

Frank Ralf’s picture

Frank Ralf CreditAttribution: Frank Ralf commented

I've been involved in #467296: Accessibility improvements for vertical tabs and #448292: Drag and Drop for table rows is not accessible to screen-reader users. Contributions to these issues by the accessibility community were only possible because there was no deep JavaScript knowledge necessary. Regarding accessibility an usability jQuery is IMHO a great leap forward compared to native JS. This should be taken into account when pondering whether to remove jQuery from core.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Frank, just tag your issue with "JavaScript" and I'll be around to help, there was no JS maintainer at the time. It's different.

On an unrelated topic, I've asked #jquery about their plan to make jQuery modular (which would render this issue moot). This is not an accurate roadmap/estimate because there is no real plan yet but it gives an idea. This is from someone who know what's going on with jQuery dev.

> lets just say, we are definitely interested in exploring how we can break up the components, but its not slated for 1.8 release
> I would think that in the next year, most of the work will be done - a lot of it depends on the build tool supporting modular compilation

> and I'm not sure if there is anyone on the team who's taken charge of this push yet, although we all pretty much want to see it happen
> i don't want to sound like an authority on the issue, but its my take that it will be a definite goal in this next year

When asked about April 2013
> hard to say - I'd hate to "promise" and be wrong, we still might not do it

Just quoting I'm not trying to make a point, I've included that here since so much people asked me about it, now you know.

MrMaksimize’s picture

MrMaksimize CreditAttribution: MrMaksimize commented

@_nod @DamienMcKenna,

Sorry guys, just skimmed over the issue without reading the bottom part. My bad.

Now that I HAVE read everything, this is actually starting to make a lot of sense. The first module you install that calls this function / dependency will add the jQuery library to the page. I actually don't think this will benefit sites only using core. As more and more contrib modules get ported to d8, now the maintainers / developers won't just use jQuery because it's there, but they'll have a choice to make and an interesting one. If I'm writing a module with a specifically mobile use case, I'll try not to use jQuery so my module won't be responsible for adding it into your installation.

I think what will happen here is choice. The choice to not have jQuery anywhere on your site and that's incredibly powerful. And adding it would be easy. Just a thought...

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Thank you for properly reading the issue. And I'm glad you can see a use-case for yourself.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

@MrMaksimize: Isn't that something that a contrib module could do, though? All of core's JS could be replaced for those few sites that really need to, kind of like how today we have jquery_update there could be a no_jquery module that replaces some of the core pieces with more raw jQuery code. I believe this would be even possible today via hook_js_alter(), BICBW.

dmethvin’s picture

dmethvin CreditAttribution: dmethvin commented

I read through this ticket but I'm still not sure how eliminating jQuery from Drupal core will help things. I just cherry picked some quotes to join the conversation, I apologize if I missed these being answered but it's quite an opus above.

> jQuery drains the battery life of a mobile phone much more than targeted javascript

jQuery has nothing to do with this. If the page developer requires some sort of activity for example via background ajax, animation, or timers, then of course it uses up battery life. If they don't run any JavaScript then battery life won't be impacted.

> jQuery is big: 32kb of javascript that you have to load on every page ... Not using jQuery will lead to more javascript code in core. This overhead will be much smaller than jQuery's 32kb.

The only way to prove this definitively is to write the code and fix the resulting bugs. Both of those require developer time and impact the resulting code quality. You're betting that you can write a subset of jQuery that works for all the target environments and makes the "much smaller" worth it. At the moment the "much smaller" is an unspecified value.

> Depending on how things goes, wrapper functions could be considered private for core use only. We're talking about something like 10-20 helper functions to make the DOM more friendly. Contrib should not assume anything is provided by core at this level.

Which means that developers building on Drupal are going to pay for the custom library size but not be able to use it. They'll instead include jQuery and the *net* size of nearly every page will go up. Won't it?

> querySelector and querySelectorAll are faster than sizzle.

Is Sizzle genuinely even close to being bottleneck for Drupal? I haven't seen that to be the case except in very poorly written code, e.g., constantly requerying in a tight loop. If you have some real-life pages that demonstrate a problem I'd be genuinely interested.

> http://jsperf.com/each-vs-array-foreach

That's not much of a difference. On the iPhone5 where performance is horrible, they are just about equally horrible. On a fast desktop browser like Chrome, even the "slow" $.each runs 1,000/sec. If you are truly interested in performance and don't need the function scope, use a for loop: http://jsperf.com/jquery-each-vs-for-loop/65 If you simply don't like the performance hit of $.each/Array.forEach for high iteration values, just use a loop instead even though you're including jQuery.

> It sounds more like the current (according to nod_) non-jQ JS is slow, not that jQuery is inherently the problem.

I am thinking the same thing, but again I'd like to see the specific code and have an idea of what it is doing that takes so long. It's not possible to address "jQuery is making my page too slow" complaints without seeing the specific code.

> For example, what if you have some modules that need an old version and some modules that don't work with that old version, then what? One of the modules will break.

The jQuery team begs and pleads for people to help us test new releases, and we try hard to fix compatibility issues before a release. We don't want people to be in that situation, and the best way to avoid it is to report bugs before the release.

> On an unrelated topic, I've asked #jquery about their plan to make jQuery modular (which would render this issue moot).

As I understand the situation I don't think "modular jQuery" helps Drupal -- especially since the term "modular jQuery" isn't defined.

For example, we have been looking at Google Closure Compiler Advanced Optimizations, which compresses and optimizes a complete body of code (jQuery, libraries, and the user's code) through global analysis. The modularity we might use to achieve good optimization allows CCAO to remove unused code and compress variable names with no additional input from the developer. But in the case of Drupal that would not help since you cannot easily combine and compress jQuery with dynamically loaded modules where you don't know *what* might be needed.

Another area we're exploring is to provide a build tool to allow devs to create a custom version of jQuery that might eliminate subsystems such as effects or ajax. But again, any franken-jQuery of that sort would be wasted in an environment where the developers "above" you need, want, and are expecting full jQuery. At best you'd be able to eliminate a small number of bytes that are used for IE6/7 support but those are relatively trivial and don't help the cause--plus you can't use a public CDN then. The big payoff comes with removing IE8 support, which I think we can all agree won't happen for a few more years.

The net of it is that if jQuery is specifically too slow or too big, the team would love specific examples of where it is causing trouble and specific suggestions what you think could be done. It doesn't help to say "it's too big" or "it's too slow" without providing more detail about the features that are too slow and/or big. For those of you ready to say "Drop IE6/7 support" we've explained several times that it isn't a large amount of code.

cweagans’s picture

cweagans
He/Him
Primary language English
Location Boise, ID, USA
CreditAttribution: cweagans commented

For those of you ready to say "Drop IE6/7 support" we've explained several times that it isn't a large amount of code.

You must be talking about a different "we", because we've already dropped IE6 and IE7 support in Drupal 8, as indicated by the first sentence of the issue summary.

dmethvin’s picture

dmethvin CreditAttribution: dmethvin commented

Yes, I meant that jQuery dropping IE6/7 support (that Drupal doesn't need) would have negligible size/perf benefit. I'm the lead on the jQuery Core team so when I say "we" I generally mean jQuery. Sorry.

cweagans’s picture

cweagans
He/Him
Primary language English
Location Boise, ID, USA
CreditAttribution: cweagans commented

(For the record: I wasn't trying to be an ass - sorry if it came across that way. I was simply making an observation.)

Thank you for your insight!

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Hello Dave, I'm really happy someone from jQuery stops by and it seems like you're not familiar with the Drupal community so that's even better.

It's quite important so I'll start with that: Drupal is underusing jQuery. Have a look at our code, most of our issues are architectural issues, not DOM manipulation or Animations. We're using a lot of events but in a very straightforward way (and almost no custom event). We are using jQuery UI in only 1 place of the core admin. Unlike everyone assumes (even from Drupal core dev) we are not doing crazy things with our javascript.

Now for the rest of it:

Battery: For the battery thing I refer you to the study linked in the fist post, jquery is a very good candidate to take as an example. Any other big chunk of JS would have worked really. But I hear you.

size shavings: yes it's not defined right now, I'm working on it. From the work I've already done, I have something like 4kb of overhead overall for now. some of it not minified. In general our code could use some tricks to have a better minification, saving off some size. My goal – and I think it's a realistic one – is to aim for 8k overhead, so 24k less than jQuery. In case jQuery is included it's possible to expose the api to use jQuery and currently go from the 4k overhead to 1k. This should work as well for the rest of the 8k. So drupal core + jquery could end up with 2k of overhead. You're free not to believe me, wait a few weeks and I'll be able to show you where I'm at. This is all I have for now.

Sizzle: this might be the worst we have: shortcut.admin.js but there are other places quite horrible as well: tabledrag.js and sometimes it's just plain stupid selectors that would be slow with querySelector as well. This whole issue is an opportunity to review all our code an optimize that. It's not just about the underlying selector engine.

$.each: I'm planning to turn all we can into for loops. Actually all $.each() use has been changed to a for loop, next is $("selector").each() when it's not useful.

perf: like I said earlier we have much bigger architectural issues than actual jQuery perf issues. More or less in order starting with the uncontested slowest script:

  1. simpletest.js
  2. user.permission.js
  3. tableheader.js
  4. tableselect.js
  5. tabledrag.js

module versions: we have exactly the same problems, this code is from someone who don't really know or care about JS and that works for him. Don't assume we're all doing our homework over here.

modular: if we're talking about dependencies, we already have a way to declare dependencies (hook_library_info()). Let's assume this is not an issue for now. As long as our developers declare their dependencies they can have all their franken-jQuery working for them with all the right parts at the right place. And seriously if you have this well underway by december (the time of our feature freeze) and it'll be ready in a bit more than a year (the supposed D8 launch) I'll be very happy to use that.

specifics: We don't have really big jQuery perf issues for the simple reason we're really not using it that much. have a look at all the JS files in the core/modules/ directories, it's some pretty simple JS. where you change 1 selector, one or two function call and you're done. This is why I want to be able to chose which part of jQuery we want to load, because usually, it's just 1 or 2 function.

To sum up my only problem with jQuery is it's size. All our code has not been developed with jQuery in mind, jQuery was brought in to do cross-browser things. We're not using it's strengths and since D8 wants to go mobile shaving 32kb of JS saves us around 200ms of page load time (I did my homework I have actual data backing up this number, used navigation timing to get the data). And it's possible for the reasons I stated earlier, we never used jQuery's full potential. Beside "we need jQuery in small pieces", we wouldn't be able to give you constructive feedback even if we wanted.

.

All in all jQuery is a trojan horse, we proud ourselves that Drupal has 900+ contributors but there are less than 10 doing JS. When I say let's not use jQuery my idea is to get attention on the JS situation, get some devs/reviewers and fix all those architectural issues. Removing jQuery is for the mobile initiative to get traction from those people as well.
Not using jQuery in the vast majority of core files amount to: queryselectorall, for loops, filter. What might be tricky is forms and ajax upload (what we're using right now is yahoo code wrapped in a jQuery plugin). In this situation, with a 2k overhead everyone wins.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

One more data point. On one page i was able to not load jQuery with everything working.
Before 39k – 32k from jQuery
After: 9k – 4k overhead from the event lib

I chose an average drupal admin page. This is the kind of things I'm working for.

dmethvin’s picture

dmethvin CreditAttribution: dmethvin commented

> Sizzle: this might be the worst we have: shortcut.admin.js but there are other places quite horrible as well: tabledrag.js and sometimes it's just plain stupid selectors that would be slow with querySelector as well.

Both of them will definitely be a challenge to fix because nearly every query uses jQuery selector extensions. It will take quite a bit of custom code and loops to implement those in bare DOM or with helper functions, since there is no ":visible" selector for example. Also, even the standard selectors are de-optimized by adding tags like "table#shortcuts" rather than just "#shortcuts" because jQuery has a fast path for the latter. The complex code gives me the impression that the markup may not be right, so it may be possible to avoid some of that mess by choosing better markup (perhaps using multiple tbody elements?).

> modular: if we're talking about dependencies, we already have a way to declare dependencies (hook_library_info()) Let's assume this is not an issue for now. As long as our developers declare their dependencies they can have all their franken-jQuery working for them with all the right parts at the right place.

So you mean "assume this is not an issue" if Drupal doesn't use jQuery? Yes they could include their own copy if you didn't provide it as a basis, but again they are paying whatever byte-price it took to get jQuery out of Drupal core. Also, it is not our goal to break jQuery into multiple dependent AMD modules that are loaded separately. Most third-party jQuery code and plugins would break unless the developer somehow determines which parts of jQuery are required--and how would they know other than trial and error?

> shaving 32kb of JS saves us around 200ms of page load time (I did my homework I have actual data backing up this number, used navigation timing to get the data).

Is that only on the first load, or on every load even when the script is cached? That is, is the delay just the 32KB of bytes being loaded, or is it caused by the 32KB of code executing?

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Completely agree with the makup/selector comment. That's the kind of thing that needs fixing.

I meant this is not an issue because in this case we would have a built in way in Drupal core to make franken-jQuery works for core and contrib. And Drupal would be using franken-jQuery for itself, no overhead here.

Well i would hope you'd have a built-in way for plugins to say what they need, even as documentation. I don't think we have drupal module integrating the JS by only providing the plugin JS file. There is usually a setting form somewhere so PHP is involved and as long as it's readable in the plugin file what are the dependencies it shouldn't be too cumbersome to declare don't know about people integrating from a theme though. But at least even if by default we load the whole jQuery, it will be possible not to use the whole jQuery file. We do have people who know what they're doing too :)

Yes sorry, the 200ms does not include the loading part, it's just the executing part, on mobile (a nexus s if you're curious).

dmethvin’s picture

dmethvin CreditAttribution: dmethvin commented

> Yes sorry, the 200ms does not include the loading part, it's just the executing part, on mobile (a nexus s if you're curious).

If it is due to parsing the code then it's a problem that means the code really needs to be smaller, but perhaps something is executing that doesn't need to execute on mobile platforms? That would be worth investigating. I can talk with the jQuery Mobile team to get their take on it, since they have a very large set of mobile hardware we can tap.

> And Drupal would be using franken-jQuery for itself, no overhead here.

But the jQuery subset used by Drupal core would not provide the full functionality expected by contrib code that used jQuery. So contrib code would end up needing to include the full jQuery, or some other special subset they built for themselves that provided their dependencies. Right? Or would you restrict their code to your subset?

> Well i would hope you'd have a built-in way for plugins to say what they need, even as documentation.

Easier said than done. Today, no jQuery plugin or user code has to say what parts of jQuery it needs. But let's say we ask the user and/or plugin developer to specify this in the future. Can they provide:

  1. Names of all the jQuery methods used?
  2. When used, $.ajax options that might affect the need for transports (xhr, jsonp, script, cors, etc.)
  3. The list of browsers they need to support?
  4. jQuery selector extensions used that require Sizzle? (:first, :even, :odd, :visible, etc.)
  5. The dependencies of any plugins used?

The last one in particular would be critical, if you didn't know the dependencies of every plugin we'd have to assume the worst case: you need everything. With a system like that, we've just placed a large and ongoing burden on every jQuery developer and plugin writer. Even so, I would be surprised if the resulting franken-jQuery was half the size the full one currently is. Most developers would throw up their hands and happily download the full version (and be able to use a public CDN) to save their time and sanity, meaning we've wasted a lot of effort to please a small number of people.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Yes indeed, it needs to be smaller. Since you said only removing IE8 support would have an impact on size, would that be an option to make IE8 support optional? I'd be happy to help in anyway I can and would be very interested to hear what your mobile team have to say.

For this franken-jQuery thing I'm actually thinking about a build tool provided by Drupal where you go like http://mydrupal.com/jquery.js?p=event,ajax and that would pull core and queue or something else as dependencies, i don't know what's what in details. Does that makes sense? We wouldn't be able to do fancy Google Closure optimization but I'm really not worried, that kind of plugin for the build tool would be available very fast as a contrib module.

For plugin dependencies I was thinking about what was after this, when plugins authors actually did figure out what they'd need and was wondering on the Drupal integration already. But ok, I see you point, that's pretty crazy. Then again, if it's available, people will use it. And with the current mobile craziness that might actually get people to keep their hands on the keyboard a tiny bit longer.

I'm nowhere near familiar with the jQuery code base, what I do know is what I'd like to be able to use. And that's something that is similar to what YUI provides. I'm not looking for that much fragmentation, looking at the current jQuery source I see that all individual files from the src/ directory when minified provide a pretty good separation already. I'd definitively split event.js in two at least. jQuery events do a lot and as you can see in Drupal we just don't use half of it. Maybe split ajax, attribute and core but that's really just for the heck of it.

That would be a compromise I'd be happy with. Again, I don't know what's going on in the source, I'm not looking for rocket science where jsonp would be a possible plugin. I'm sure it's possible and it might happen way later but that's not what I'm expecting right now. I'm expecting a page with 40k of js to be cut down by 60-70% when it only uses one or two event handler.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

@Dave Methvin

The jQuery team begs and pleads for people to help us test new releases, and we try hard to fix compatibility issues before a release. We don't want people to be in that situation, and the best way to avoid it is to report bugs before the release.

Drupal 6 was released in February 2008 and ships with jQuery 1.2.6. Drupal 7 was released in January 2011 and ships with jQuery 1.4.4.

These versions are stuck on those jQuery releases (upgrading jQuery can be done through the contrib jquery_update module) primarily for backwards compatibility reasons - we can't test new versions of jQuery with every contrib and custom module that people might write, and we generally avoid breaking APIs in stable releases unless it's necessary to fix a security issue, which includes JavaScript shipped with core.

While I don't follow things as much as I should, it's my understanding there was an intentional API break between jQuery 1.5 and 1.6, but that was a while ago so have things changed?

The lifespan of a Drupal core release is around 5 years at the moment, I don't think you're saying that you'll maintain backwards compatibility over five years but it'd be great to clarify this.

dmethvin’s picture

dmethvin CreditAttribution: dmethvin commented

> Since you said only removing IE8 support would have an impact on size, would that be an option to make IE8 support optional

For who? Would you build a version that has no IE 6/7/8 support? So anyone who wanted IE8 support would have to include a new jQuery?

> I'm actually thinking about a build tool provided by Drupal where you go like http://mydrupal.com/jquery.js?p=event,ajax and that would pull core and queue or something else as dependencies, i don't know what's what in details. Does that makes sense?

You might be able to do that yourself, but my thought was that you would build a single file that contained what you needed. It's not as if you'd have parts of jQuery and cat them together at your server. Also, I am not sure what level of granularity there will be for 1.8, for example the ajax.js FILE contains $.load() which needs some traversal functions, so you can't use that without traversing.js. The more we break down the files, the harder it would be for someone who wants to build their own version to figure out what to do and the harder it would be for us to maintain.

> I'm expecting a page with 40k of js to be cut down by 60-70% when it only uses one or two event handler.

I think you are likely to be disappointed, even if jQuery spends a lot of time trying to create extensive code configuration options and you spend a lot of time trying to figure them out. If your needs are truly that simple and the code like shortcut.admin.js can be rewritten or thrown overboard, then maybe you don't really need jQuery. I kind of doubt it though. In the meantime I think there are other things the jQuery team can try that provide some benefit for a much greater number of people with a lot less effort. We can work on those first and see what that buys everyone.

rooby’s picture

rooby CreditAttribution: rooby commented

Re #62:
I agree with pretty much that whole thing but have one comment.

> For example, what if you have some modules that need an old version and some modules that don't work with that old version, then what? One of the modules will break.

The jQuery team begs and pleads for people to help us test new releases, and we try hard to fix compatibility issues before a release. We don't want people to be in that situation, and the best way to avoid it is to report bugs before the release.

This is taken out of context and was actually an argument against Drupal shipping with multiple jQuery versions and letting people switch between them as thy need newer features.
It refers to different (Drupal) modules that might require functionality that is only in certain (different) jQuery versions.

Anyway, what I mean to say is that point isn't an issue that needs addressing.

(wow, iOS autocomplete is a real PITA)

rooby’s picture

rooby CreditAttribution: rooby commented

For this franken-jQuery thing I'm actually thinking about a build tool provided by Drupal where you go like http://mydrupal.com/jquery.js?p=event,ajax and that would pull core and queue or something else as dependencies, i don't know what's what in details.

So when a site builder (not necessarily someone with super tech skills) installs a new module, they have to rebuild jQuery in case something might break?
I guess it can be automated but I is starting to get a bit complex for a product that is trying to push into a market of users who have little to no tech ability.

And then if your themer is expecting jQuery to use for some reason they don't know if all the functionality of jQuery they would require is even present or not.

I know it takes time but it would be good to see a forked version of core with some of hese changes to see if the speed increase is worth the potential pain.
And to also see how it works out in the very common use case of also having jQuery because it is required for some non-core module.

If the results are good it might be time well spent, but it could also be time better spent elsewhere.

rooby’s picture

rooby CreditAttribution: rooby commented

Deleting duplicate post - stupid mobile devices :)

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

> Would you build a version that has no IE 6/7/8 support?

For mobile I mean. I'm pretty sure we won't be seeing IE8 on mobile so all this compat code don't need to be loaded or executed on mobile. a jQuery without IE8, for mobile use. That's what I meant.

> It's not as if you'd have parts of jQuery and cat them together at your server.

I understand. You have a different set of challenges than us, I was just hoping splitting things would work better.

> If your needs are truly that simple and the code like shortcut.admin.js can be rewritten or thrown overboard, then maybe you don't really need jQuery. I kind of doubt it though.

That's most of what we have in core, have a look at the patch at #42, that's pretty much what it's all about. For shortcut.js and tabledrag.js i don't mind if we still have to use jQuery to make it work an not go crazy. Our tabledrag doesn't even work on mobile so there's that :)

> In the meantime I think there are other things the jQuery team can try that provide some benefit for a much greater number of people with a lot less effort. We can work on those first and see what that buys everyone.

I'm sure go have enough to be kept busy, let me know if I can help on something related to that when you're starting to think about it.

@rooby
> If the results are good it might be time well spent, but it could also be time better spent elsewhere.
Well that's pretty much only my time for now and I can't do anything if nobody reviews the other 10s of JS patches waiting in the queue.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

I've added a new issue to start the work on selectors clean-up which is something we all agree on. #1574470: Selectors clean-up

About the jQuery issue I have some more data about the execution costs of the different pieces of jQuery we use and the ones we don't. I still need some time to clean-up the data and measure what that means for Drupal core JS. It should be ready soon.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Today I was pleasantly surprised by this Modules (new in 1.8). That is very good news.

Our code still needs clean up and jQuery being modular, while helping tremendously, will not be a silver bullet. This issue still needs to be addressed.

(edit) Currently dimensions, effects and offset can be removed from a custom jQuery build, I'm told more will be made modular.

RobLoach’s picture

RobLoach
he/him
CreditAttribution: RobLoach commented

I'd like to use less jQuery, but in the mean time: #1341792: [meta] Ship minified versions of external JavaScript libraries

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Well the good news keep coming from the jQuery side of things: jQuery 1.9 and 2.0 — TL;DR Edition in which it is announced that jQuery 2.0 won't be supporting IE8 and under in order to reduce filesize and CPU footprint while jQuery 1.9 will still maintain IE6+ support with the same API.

Quite a change of heart from #73 :) now the only thing we need to see is the resulting filesize of this jQuery 2.0. For me the butter zone would be around 10kb but I'd live with anything under 18kb provided we get rid of some of the modules like 1.8 allow us to :)

Again, that doesn't mean we don't have to clean our code and isolate the parts where jQuery is used. I haven't seen a roadmap for 2.0 and we should assume for now that it won't be ready for D8 (code freeze in February right?).

donquixote’s picture

donquixote CreditAttribution: donquixote commented

Hi,
I did not read all replies, this is far too long.. time for an issue summary update :)

@nod_
I see no mention of js aggregation in your starting post.
A main concern I have is that not every page has its own version of aggregated js. This would totally kill browser caching, even if the overall file size of every package is reduced. How do you want to solve this issue?
I think AdvAgg attempts to solve this with some smart grouping. But I have not really seen a documentation telling me how exactly this is supposed to work.

Also, I wonder what you worry the most about:
1) jQuery download: Download jquery.js, if it is not in a cache already (hint: CDN)
2) jQuery bootstrap: Initially execute all of jquery.js.
3) execution of jQuery code called by other scripts.

I think performance in point (3) can be improved with some targeted optimizations, and does not require to discard jQuery entirely. In many cases, jQuery does the same that we would do manually anyway, so doing it manually would not improve anything.

For point (2), a partial bootstrap would be nice.. but how does this play with grouping and aggregation?
(given that at some point we will have partial/split-up jquery available)

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

You might want to actually read the post. This is not what this is about.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

One of the concerns you mention is performance. So I was wondering what this means for a real-world site. I don't understand how this is off-topic.

Not having jQuery required by core js would allow some requests to not download and bootstrap jquery.js. Or to download + bootstrap only a part of jquery. Or to download + bootstrap an alternative or home-grown light-weight selector engine. This can be a performance improvement.
Still, there are likely other requests that need to download + bootstrap the full jQuery, due to contrib modules. (depends on your site).

My question was, does this actually bring a benefit, if some pages require full jQuery, and others don't. Or is this actually counter-productive, because now the browser needs to download more different versions of aggregated js - one with jQuery, another without, another with a stripped-down jQuery, another with an alternative selector engine?

Or maybe you are thinking more about the occasional site where the majority of requests does not need jQuery at all?
If we want this, then we also need to ask major contrib modules to do w/o jQuery, whenever they can.

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

It is my sincere hope, even though it is a bit of a pipe-dream, that the introduction of the $40 Windows 8 upgrade option for Windows XP, Windows Vista, and Windows 7 computers will lead to a sharp reduction of oldIE.

IE 10 sounds great, and the best part about it is that it should be the start of a more rapid update cycle.
http://msdn.microsoft.com/library/ie/hh673549.aspx

So our early moves to rid Drupal of it's IE6 and 7 baggage was a huge win and jQuery's effort to remove it in the far-flung future will be a no-brainer.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

@cosmicdream: A $40 upgrade price isn't going to have any effect on someone who's 15 year old computer is barely able to run XP and who's quite happy with what they have.

rj’s picture

rj CreditAttribution: rj commented

Hi, just adding my $.02. Separating jQuery from core is a good idea, imo. Even though most modules require it, having a fixed-version of jQuery tied to Drupal seems counter-intuitive; what happens if you have a site (or a specific page) that requires something other than 1.5.2? I've seen various posts in issue queues and forums for workarounds (eg. here), separating jQuery from core seems the most logical and sustainable.

rj’s picture

rj CreditAttribution: rj commented
Issue summary: View changes

mobile energy study

jessebeach’s picture

jessebeach CreditAttribution: jessebeach commented

@rj, the argument that updating jQuery should be easy is the one that tips me over into the camp of removing jQuery dependencies in core modules.

Sylvain Lecoy’s picture

Sylvain Lecoy CreditAttribution: Sylvain Lecoy commented

Just a quick note about #51, while I mainly agree with you, the following statement is not reasonable:

jQuery is currently being used by 46% of the web. The whole web. All of it.

Sounds like Is the glass half-full or half-empty :D For me it also mean that 54% of the web is not using jQuery. Despite this disagreement eaton is mostly right, but the author concerns should not be dismissed, the minimized version of jQuery takes time to un-compress, and participates to the UI freeze lap before the web page is actually functional.

I do not have a solution either but just wanted to follow the discussion.

Sylvain Lecoy’s picture

Sylvain Lecoy CreditAttribution: Sylvain Lecoy commented

Yep! Found it: http://css.dzone.com/articles/why-use-backbonejs.

adamdicarlo’s picture

adamdicarlo CreditAttribution: adamdicarlo commented

Step by step from jQuery to Backbone shows each step in making a typical blob of jQuery decoupled from the DOM and testable, using Backbone. Pretty much blew my mind.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Next step here is to decide on #1787012: [policy, no patch] Write D8 JS against ECMAScript 5. Prevent errors with feature detection (drop IE8 support) and #1787146: Make IE8 behave as no-js (do not run any Drupal JavaScript on IE8) which would give a much bigger scope to this issue than the current clean-up.

mfer’s picture

mfer CreditAttribution: mfer commented

A quick few questions.

  1. Who are the target audiences of this change?
  2. How does this improve things for these audiences?
  3. What is the impact to core maintainability?
Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented

Also: https://twitter.com/ppk/status/249100988693241856

#93: I'm not the authoritative person on this subject, but I think I can answer this at least partially.

  1. Everybody.
  2. Less JS to load: faster page loads. Furthermore, it'll allow core not to break when a newer version of jQuery is installed.
  3. None; most definitely if we choose to not support IE8.
webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

I would counter those answers, slightly. Sorry for the foul-tasting dose of reality here. :)

1. End-users of Drupal sites, and their visitors, and highly proficient front-end developers familiar with performance best practices. Not typical Drupal developers, who almost always have a PHP background and whose knowledge of JS almost always could at best be described as "barely passable." For them, libraries such as jQuery are a god-send, because there are tons of snippets available, pre-existing libraries to download to do things they need, etc.

2. Yes, what Wim said. The converse is that in order to write such JS, typical Drupal developers need to school up in a big way on how to know what highly proficient front-end developers know. Most of them will not [be able to] do this. Which means that although stock Drupal might be lightning fast, as soon as you add even one contrib module, this will all completely go out the window. Especially if jQuery doesn't come in core, then you get to deal with Module A adding jQuery version Q and Module B adding jQuery version Z (yay, bugs!). Unless we somehow manage to miraculously grow our front-end performance team by a factor of 30, and those people are spread all over the top 100 contributed modules helping educate people. Given that there are only about 3-4 people right now working regularly on JS core, I'm going to call this prospect "extremely unlikely to happen."

3. It depends on what method we use to exclude IE8. But most likely, this is true.

Note that although I realize that this sounds very bleak and depressing, I think there are things we could do to help, both documentation- and tool-wise. For example, a "gate" document akin to http://drupal.org/core-gates that documents JS performance best practices for module developers, and a "lint" tool that ties into something like http://drupal.org/project/drupalcs or http://drupal.org/project/coder to warn people when they use slow things, with suggestions on how to remedy. But this education is going to be a gradual, iterative process IMO. I don't really see how throwing jQuery out the door in D8 is going to be feasible.

jessebeach’s picture

jessebeach CreditAttribution: jessebeach commented

It's good to remember that libraries exist because those developers who came before us ran into the same types of problems over and over again. Their solutions became codified in libraries like jQuery, Dojo, underscore, YUI, Prototype, etc. When we simply toss out these libraries, we toss out years and years of collective developer experience. We will run into the problems that they encountered. We will realize that our solutions can be collected into a single location in Drupal. We will eventually end up building our library of solutions. We'll end up with something like jQuery filled with bugs and inefficiencies, because it's code and code is never perfect. And we'll waste a lot of time resolving so many problems that others have solved already.

The builders of these JS libraries realize that their legitimacy and longetivity depends on their ability to deliver small, fast solutions. It's the same pressure we feel here in Drupal. I'd rather bank on jQuery improving over time, with their dedicated team of JS devs, than bank our our ability to build a small, fast JS utils library that rivals the capabilities of external libraries in the time we have allotted to us.

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

+1 for @jessebeach.

Given two of the big sub-projects for D8 (WYSIWYG, Views-in-Core/VDC) will require jQuery there isn't any way to get around bundling a version of jQuery in core. Obviously we don't have to decide today which version will be included, but it will need to be there. Most of that functionality will be needed for the admin / editor side only, so further optimizing the core JS architecture and code for regular site visitors is worthwhile. I think it's completely naive to believe it can be removed from core entirely - I'm sure there are laudable benefits, but the level of hassle for most sites & developers just isn't there.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia commented

In #1149866: Add Backbone.js and Underscore.js to core, we're exploring whether to add underscore and backbone to core. If we do that, what would be left in core that would need jQuery? #1667742: Add abstracted dialog to core (resolves accessibility bug) is one I can think of, so I'd be hesitant to remove jQuery from core entirely. But this issue doesn't say "eliminate", it says "reduce", so I guess we'd just need to figure out what features in core should use jQuery, what should use Underscore, what should use Backbone, and what should use raw JavaScript?

JamesK’s picture

JamesK CreditAttribution: JamesK commented

@DamienMcKenna I think this has been said a few times already, but this is about reducing use of jQuery where it is not needed. If it is needed for WYSIWYG and Views UI, then so be it, but is there any reason why anonymous users should have to load jQuery for every page request just because content authors are using it for their WYSIWYG editor?

DamienMcKenna’s picture

DamienMcKenna
Location NH, USA
CreditAttribution: DamienMcKenna commented

@JamesK: I just wanted to reiterate it :)

Sylvain Lecoy’s picture

Sylvain Lecoy CreditAttribution: Sylvain Lecoy commented

@jessebeach nice speach, should also apply in #1608878: Add CTools dropbutton to core ;)

edward_or’s picture

edward_or CreditAttribution: edward_or commented

> In #1149866: [meta] JS MVC in core, we're exploring whether to add underscore and backbone to core. If we do that, what would be left in core that would need jQuery?

Backbone has a soft dependency on jQuery or zepto. It uses either one of those libraries to do DOM manipulation. Since Zepto has zero support for IE (maybe support for IE10) I can't see core using that. I don't know what people have in mind that Drupal would use Backbone for but I would guess some DOM manipulation would form a part of it.

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

@#102 we're not planning on using backbone's DOM Manipulation. See the latest in #1149866: Add Backbone.js and Underscore.js to core

zzolo’s picture

zzolo CreditAttribution: zzolo commented

This is an interesting conversation. I don't think there is a real right answer on this, but here is my two sense.

First, this issue is NOT about whether jQuery is useful or whether developers want it. jQuery is a great library and every developer wants to use it, especially ones that are new to JS. Yes, people have there gripes with it, but we have already accepted it as a community. The main reason folks don't use it is because they are not doing DOM manipulation or are need better performance.

The question at hand is: How to we allow better JS performance in Drupal Core (ie removing jQuery as well as other things)

It is obvious that we want better performance, or at least the opportunity for better performance. Pressflow is a really good example of how the community wants this, and how folks will hack core to get better performance from Drupal.

So, we come to two roads, which are the general paths for any architectural decision around performance.

1) Make Drupal Core as lean as possible and allow developers to build on top of that. This is what is laid out by @nod_ originally.

2) Make Drupal Core flexible enough to make it more performant by the contrib space. In this case, this means making APIs that would allow a developer to override Drupal's javascript to be a lot more lean. This option inherently adds a little more overhead.

Regardless of which one is better, it's one or the other. I think #2 can already be accomplished with the ability to overwrite JS includes and libraries (I am mostly guessing here). Though #1 is definitely possible to achieve and has the benefits that have already been outlined.

Historically, Drupal goes towards architectural decisions that are more aligned with #2.

zzolo’s picture

zzolo CreditAttribution: zzolo commented
Issue summary: View changes

Adding current status

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Many good things happening with jQuery this past year: 2.0 stable, custom builds based on an all-AMD source, many optimizations on initialization and so on. As well as on our side: officialy dropping IE8 support, clean JS (in the sense of JSHint), less abuse of jQuery, policy of upgrading JS libs, explicitly declaring all dependencies for scripts, not requiring jQuery in many important places and a few other things.

Now that we can cleanly take jQuery apart, we can decide what to use and what not to use. I'll close this issue soon if anyone has something to add from this past year and use #2137235: Make core JS work with a subset of jQuery as the meta for the actual work on our code (which already started with the JavaScript clean-up effort).

It was a really nice issue, reading back there are lots of good and constructive opinions and even the various stabs makes me grin :)

A few posts that can be read to appreciate what has been going on this past year:
#25
#70
#73 (my favorite post here :)

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
Issue summary: View changes
Status: Active » Fixed

I think we're good here see you all in #2137235: Make core JS work with a subset of jQuery :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

riddhi.addweb’s picture

riddhi.addweb CreditAttribution: riddhi.addweb commented
Issue summary: View changes