document ready event?

8746 views
Skip to first unread message

TonyWang

unread,
Nov 6, 2009, 2:06:43 AM11/6/09
to Closure Library Discuss
I just can find LOAD event in goog.events.EventType.LOAD

is there any event listener like jquery's $().ready() ?

thanks for all

Erik Arvidsson

unread,
Nov 6, 2009, 1:31:20 PM11/6/09
to closure-lib...@googlegroups.com
This is intentional. We should post an article about it.

The short story is that we don't want to wait for DOMContentReady (or worse the load event) since it leads to bad user experience. The UI is not responsive until all the DOM has been loaded from the network. So the preferred way is to use inline scripts as soon as possible. 

<div id="my-widget"></div>
<script>
initWidget(document.getElementById('my-widget'));
</script>

Yes, it not as easy to maintain but it leads to a better user experience.

By intentionally leaving out DOMContentReady wrappers we have been able to prevent Google Apps to use on this anti pattern.
--
erik

George Moschovitis

unread,
Nov 6, 2009, 1:47:46 PM11/6/09
to Closure Library Discuss
> By intentionally leaving out DOMContentReady wrappers we have been able to
> prevent Google Apps to use on this anti pattern.

Interesting, I thought this was actually a pattern.
Can you please provide a link to an article elaborating on why .ready
() is a bad design choice?

thanks in advance,
-g.

Josh Powell

unread,
Nov 12, 2009, 12:10:13 PM11/12/09
to Closure Library Discuss
Can you please write this article, or some tutorials around how to use
closure? Some best practices or something to get started? The Hello
World and Tutorials on Google Code don't really give enough
information to get started. Not putting the code in a document or
window load event is a pretty dramatic departure from the other js
libraries and I would like to know what other differences are.

Thanks!
Josh Powell

On Nov 6, 10:47 am, George Moschovitis <george.moschovi...@gmail.com>
wrote:

Jonathan Gold

unread,
Feb 11, 2010, 2:37:50 PM2/11/10
to closure-lib...@googlegroups.com
Also Erik --

I'm a bit confused about your recommendation about using the inline script. I
actually would have preferred to do it that way (inline), but a more experienced
frontend dev told me that there is no guarantee that the browser will have
rendered the element ('my-widget' in your example) before executing the script,
even though the script follows the 'my-widget' element in DOM order.

Can you clarify on this point?

jon

Erik Arvidsson

unread,
Feb 11, 2010, 2:46:05 PM2/11/10
to closure-lib...@googlegroups.com
On Thu, Feb 11, 2010 at 11:37, Jonathan Gold <jgol...@gmail.com> wrote:
> Also Erik --
>
> I'm a bit confused about your recommendation about using the inline script. I
> actually would have preferred to do it that way (inline), but a more experienced
> frontend dev told me that there is no guarantee that the browser will have
> rendered the element ('my-widget' in your example) before executing the script,
> even though the script follows the 'my-widget' element in DOM order.
>
> Can you clarify on this point?

The DOM node is there and if you query for its size or something else
that requires a reflow a reflow will happen so that the layout data is
up to date.

The only argument against doing the inline code is that it makes it
harder to maintain because you have all these inline scripts
intermixed with your content.

--
erik

Jonathan Gold

unread,
Feb 11, 2010, 2:53:59 PM2/11/10
to closure-lib...@googlegroups.com
Thanks for the response. I'd still love to see an article if you guys write one
about it, but this is helpful nonetheless.

jon

ri...@google.com

unread,
May 2, 2014, 11:18:24 AM5/2/14
to closure-lib...@googlegroups.com

The only argument against doing the inline code is that it makes it
harder to maintain because you have all these inline scripts
intermixed with your content.

I remember having read somewhere that inline scripts are not recommended, because the browser may be blocked from doing a bunch of stuff in parallel, on the off chance that your script might be calling document.write().

Not sure how much truth there is to that.

thanpolas

unread,
May 25, 2014, 3:59:48 AM5/25/14
to closure-lib...@googlegroups.com, ri...@google.com
I remember having read somewhere that inline scripts are not recommended, because the browser may be blocked from doing a bunch of stuff in parallel, on the off chance that your script might be calling document.write().

That's both true and false, the browser is indeed "blocked" by any <script> tag that it parses, but that's just how browsers work, here's an article that i wrote inspired by this very thread that better explains why you don't need the DOM Ready event.

Paul Draper

unread,
Jul 5, 2014, 11:56:05 PM7/5/14
to closure-lib...@googlegroups.com, ri...@google.com
I'm not sure I follow the logic here. It sounds like

"You don't need the DOM ready event so we won't include it."

You don't need anything in the Google Closure Library, but it helps you write more maintainable code.

It seems that goog.events.EventType.LOAD is even worse than goog.events.EventType.READY.

When a programmer can't use goog.events.EventType.READY what is he most likey to say:
  1. I better add a whole lot of inline scripts to my HTML from the server.
  2. I can just use goog.events.EventType.LOAD. Yep, that works.
  3. I'll use 'DOMContentLoaded'. (Who cares about IE6/7?)
If it is #2 or #3, we can make things better by adding goog.events.EventType.READY.

Paweł Gołąbek

unread,
Nov 10, 2017, 1:11:31 PM11/10/17
to Closure Library Discuss
here is the link to thanpolas article: http://thanpol.as/javascript/you-dont-need-dom-ready
there was a type in the one he posted
Reply all
Reply to author
Forward
0 new messages