Run Javascript after DOM is ready

  • Context: Java 
  • Thread starter Thread starter Jamin2112
  • Start date Start date
  • Tags Tags
    javascript
Click For Summary

Discussion Overview

The discussion revolves around the timing of JavaScript function execution in relation to the Document Object Model (DOM) readiness. Participants explore methods to define functions that should not execute immediately when the DOM is ready, but rather be prepared for later invocation. The conversation includes technical explanations, code snippets, and considerations of browser behavior.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • Some participants inquire about the necessity of defining a function without invoking it immediately upon DOM readiness.
  • One participant suggests using a callback function to manage when a function is executed after the DOM is ready.
  • Another participant provides a code snippet demonstrating how to define a function within a jQuery document ready handler.
  • Concerns are raised about the reliability of event handling across different browsers, with one participant noting that timing issues are common in JavaScript.
  • Some participants mention fallback strategies, such as using timers, to ensure functions execute correctly across various browser environments.
  • A later reply emphasizes the importance of understanding asynchronous and event-driven programming in JavaScript.
  • There is a suggestion that developers should consider using polyfill libraries for better compatibility with older browsers.

Areas of Agreement / Disagreement

Participants express differing views on the best approach to handle function definitions and execution timing in JavaScript. While some agree on the utility of jQuery's document ready functionality, others raise concerns about its reliability and the need for fallback mechanisms. The discussion remains unresolved regarding the optimal strategies for managing JavaScript load timing.

Contextual Notes

Participants note that timing issues can vary significantly between browsers, and that solutions may not be straightforward. There is mention of the HTML5 DOMContentLoaded event and its role in the jQuery.ready() implementation, but no consensus on the best practices for ensuring consistent behavior across all scenarios.

Jamin2112
Messages
973
Reaction score
12
... the situation where you want a function to be defined after the DOM is ready, but don't want it to execute right when the DOM is ready (as happens if you simply put it in a document.ready(...) function)?
 
Technology news on Phys.org
It is a bit unclear to me why you would want to define but not invoke a function when the document is ready. Perhaps you can elaborate on what your problem is?

If you really want to, you can just add a document ready handler that defines the function by simple assignment. Using the jQuery [1] document ready event [2] that could look like the following:
JavaScript:
var myFunction = function() {}; // define the symbol in current scope
$(function() {
  var someValueFromDOM = ...;
  myFunction = function() {
    // use someValueFromDOM
  };
});

However, if you are using jQuery you can usually just define your function as normal and just use jQuery selectors [3] directly, like
JavaScript:
function myFunction() {
  var value = $('#my-text-element').text();
  // use value
}

But perhaps you are having a different problem?[1] http://jquery.com/
[2] http://learn.jquery.com/using-jquery-core/document-ready/
[3] http://learn.jquery.com/using-jquery-core/selecting-elements/
 
Filip Larsen said:
It is a bit unclear to me why you would want to define but not invoke a function when the document is ready. Perhaps you can elaborate on what your problem is?

Suppose I want to attach an event listener to an element:

Code:
$('#my-element').hover(function(){ alert("Yo hovered over my element!") });

If I also that function declaration in a JS file in the head, what happens is either:

(1) I put it in a document.ready(...), in which case the alert will be invoked when the page is loaded.
(2) I don't put it in a document.ready(...), in which case there's an error because #my-element isn't in the document tree at the time when the function is read.
 
Is this what you meant by (1):
Code:
$(document).ready (function() {
    $('#my-element').hover(function(){ alert("Yo hovered over my element!") }); 
});
It appeared to work for me.
 
Welcome to the arcane world of Javascript load timing, and browser differences. Which is why I do as little Javascript as I can get by with. Sorry I can't really help you. I'd probably end up doing something crass with a timer.
 
harborsparrow said:
Sorry I can't really help you.

I'm a little puzzled why you then choose to make a post, especially since the post just before yours provided an excellent code snippet showing the idiomatic way to do this in javascript with jQuery.

harborsparrow said:
I'd probably end up doing something crass with a timer.

Then you would most likely be doing it wrong. Javascript programming on the client (and server too for that matter) is highly asynchronous and event-driven, and understanding how this works is critical for making workable code.
 
Just pointing out that timing is the hardest and probably most common Javascript problem, and not always straightforward to solve. I would want to test each solution mentioned here in all the browsers that need to be supported. In my experience, events often don't work alike in different browsers.
 
  • #11
Silicon Waffle said:
http://javascriptkit.com/dhtmltutors/domready.shtml
Something similar can be achieved.

I notice that the fallback strategy in this article is--a timer! Because IMO there is always the odd browser that just doesn't fire events in a sane order. Sigh. It's a good strategy, trying to account for everything and having a fallback plan for when it all fails. Better yet, would be to change to page design not to have to detect page loading--but I know it isn't always possible.
 
  • Like
Likes   Reactions: Silicon Waffle
  • #12
harborsparrow said:
I notice that the fallback strategy in this article is--a timer!

My point in post #8 was that a web page developer should never have to implement this themselves. A quick look at the domready code already mentioned, or the extensive code in jquery.documentReady [3], only confirms that this not something you can just throw together and expect to work in all cases. If backwards compatibility really is needed the developer should instead use one of the many polyfill libraries that have been extensively tested. And it is perfectly fine for such a library to use a recurrent timer as a fall-back strategy to detect when the document is ready.

Regarding the current jQuery.ready() implementation [4] it should be safe to use in the sense that it will eventually fire, but maybe not as fast as one would like for some heavily framed pages on some old browsers. Note that it does not use timers, but relies solely on the HTML5 DOMContentLoaded [1] event with fall-back to the window.load event [2].

[1] https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded
[2] https://developer.mozilla.org/en-US/docs/Web/Events/load
[3] https://github.com/addyosmani/jquery.parts/blob/master/jquery.documentReady.js
[4] https://github.com/jquery/jquery/blob/master/src/core/ready.js
 
Last edited by a moderator:
  • Like
Likes   Reactions: Silicon Waffle and harborsparrow

Similar threads

  • · Replies 9 ·
Replies
9
Views
2K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 12 ·
Replies
12
Views
2K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 8 ·
Replies
8
Views
3K
  • · Replies 4 ·
Replies
4
Views
1K
  • · Replies 9 ·
Replies
9
Views
2K
  • · Replies 9 ·
Replies
9
Views
4K
  • · Replies 6 ·
Replies
6
Views
3K
  • · Replies 15 ·
Replies
15
Views
3K