Introduce domReady to remove jQuery dependency from drupal.js and clean it up.

Overall, I like this step. However, I think this causes us to be in a fairly schizophrenic place :)

• drupal.js does not depend on jQuery anymore, but it depends on drupal.init.js, which depends on jQuery. Which is the most schizophrenic part probably.
• drupal.js does not depend on jQuery anymore, but for Drupal.attachBehaviors() to be called, it needs jQuery. Is it not feasible to have something like the jQuery.ready event without jQuery?
• drupal.init.js does 4 things:
  1. Drupal.settings = drupalSettings, which is temporary, and can easily live in drupal.js
  2. Drupal.(un)freezeHeight(), which is very dependent on jQuery, but is only a few LoC. Is it not feasible to rewrite this to not use jQuery? Then it can live in drupal.js.
  3. Setting the "js" classname, which you already converted to not use jQuery. Hence it can live in drupal.js. Furthermore, the "js" class on the "html" element is already being set by Modernizr! So should we even keep it? I guess we should, because sites should be allowed to not load Modernizr and still not break things.
  4. Finally, the "on ready, attach behaviors" thing mentioned above.

Overall, it seems that it might be easier to just make Drupal.js *not* depend on jQuery? Assuming it's possible to refactor items 2 and 4 in the above list to not use jQuery, of course.

During clean-up phase of the release is generally not the point to introduce things that need further clean-up. I'd rather do #1 & #2 in this issue, rather than commit us to a weird state that makes Drupal harder to grok for people.

Basically everything in drupal.init.js is stuff I want to get rid of.

#1, #2 worst case, I'm planning on making a module or something that will get rid of drupal.init.js and it's jquery dep. If we can do it in core, all the better.

#3
1. I'd put all the cruft in drupal.init.js it's clear what needs to go away this way.
2. that's an ajax thing. It's not used anywhere else and I don't think contrib uses it. if it can't be in .init.js then it should be moved to ajax.js
3. that's tricky. We have CSS depending on this class and modernizr is not on every pages like you said. I'd say it's safer to keep.
4. that's tricky. Getting the ready event seems to be painful, just look at what jQuery does, it's pretty ugly i wouldn't want that.

Thanks for getting the discussion going :)

4. If all you need is a "domready" function, we could just add a small library. Ded's domready.js looks like a decent one, and according to GitHub is only 0.74kb in the minified version. Yes it would mean adding another js "library" to core, and possibly having duplicate code (well sort of => $(document).ready()), but I think the benefit is large enough to at least consider it (0.74kb vs 92kb for jquery-1.9.1.min.js). This way we can have a decent cross-browser ready event, without having to figure it out ourselves...

Just my 2 cents.

#3: Indeed. This is a small patch anyway, so it wouldn't hurt to do it all in one patch.
#4: Thanks — that's very useful :)

Looks very nice! Any tricky aspects I'm not aware of? :)

@@ -1,11 +1,14 @@
-var Drupal = Drupal || { 'behaviors': {}, 'locale': {} };
+var Drupal = { behaviors: {}, locale: {} };

Any particular reason we're not trying to prevent overriding any global Drupal object already present?

Also, it feels very much like "I have a dependency on domReady" actually means "I should probably run in the footer", but I guess that's not an assumption we should be making.

Ideally we'd need something like "domReady is defined as dependency, but another script requires jQuery, so dropping domReady in favor of jQuery", but then we'd need some sort of unified syntax, which would require custom code. But I guess contrib could very well handle that...

figured as much.

I don't have any other questions/objections, but would like to take this for a manual spin.

Should be able to do so later today.

+++ b/core/misc/drupal.jsundefined
@@ -1,11 +1,14 @@
 // Allow other JavaScript libraries to use $.
 jQuery.noConflict();

This will error out when using drupal.js without jQuery, won't it?

core/misc/domready/ready.min.js is missing from the patch, hence the test failure.

Going once, going twice... Sold! No more AJAX stuff where it doesn't belong!

Why are freezeHeight and unfreezeHeight moved to ajax.js?

OK maybe a follow-up issue to try to remove them? They look generic-ish but if they're only used in one place and not doing anything useful it's worth trying to clean up.

Since we're adding a new javascript library (https://github.com/ded/domready) assigning to Dries to make the call.

In my opinion this fantastic improvement in overall page weight justifies adding the new library.

Is it safe to use above domready script in Drupal ?
https://github.com/jquery/jquery/blob/master/src/core.js#L799
https://github.com/ded/domready/issues/14

I assumed you going to remove jQuery-like stuff, otherwise I see no point to replace it. Everywehre in Drupal using jQuery, doesn't it?

Also, any chance add unload support to drupal_add_library ??
half of sites loading jQuery. (http://trends.builtwith.com/javascript/jQuery)
(another half may load other scripts, eg. Dojo)
Is that means 50% Drupal site loading extra 1kb + 1 extra http request?

I'm not sure I fully understood droplet's comment in #29 but it seems like it could be an important point. It sounds like droplet is suggesting that this may cause an extra HTTP request for many sites. If so, we should certainly discuss this more.

Sites with js aggregation enabled (which should be every production site) won't get an extra HTTP request.

The 1kb of extra js I think is fine given it's going to result in a 90kb reduction for most pages without jQuery loaded - which is going to include a lot of real sites in the wild if we get the js refactoring in core right.

#24: core-js-untangle-drupal.js-1974580-24.patch queued for re-testing.

Thanks for the explanations. I'm comfortable with this patch being committed so I'm un-assigning it from myself. The patch does not appear to apply anymore so I'm asking for a retest.

Indeed. This is a easy patch, so it wouldn't hurt to do it all in one patch.

Thanks I'm new to Drupal

Committed 235142a and pushed to 8.x. Thanks!

Just realised that I accidentally committed this from "needs review"... but in my defence... #36 was a re-roll and it was rtbc'd in #26 and signed off by Dries... sorry everyone.

I'm not offense, but check #29.

http://bugs.jquery.com/ticket/12282#comment:15
https://github.com/ded/domready/issues

Untagging. Please remove the "Needs change notification" tag when the change notice task is complete.

update issue summary