Building Resilient Systems on AWS: Learn how to design and implement a resilient, highly available, fault-tolerant infrastructure on AWS.

afterscriptexecute Event

By David Walsh on January 2, 2013

Fellow Mozillian Daniel Buchner, curator of the X-Tag project and clever developer who showed us how to detect dom node insertions using CSS animations, recently showed me a new JavaScript feature I'd never heard of: the SCRIPT element's afterscriptexecute event. This event, when detected within the document, provides developers insight as to when specific SCRIPT elements are executed.

View Demo

The following snippet listens for script executions on the page and logs the specific SCRIPT element to the console after executed:

<script id="my_script" type="text/javascript">
document.addEventListener('afterscriptexecute', function(e){
  console.log('Script executed: ', e.target);
}, false);
</script>

<script type="text/javascript">console.log('foo')</script>

<script type="text/javascript">console.log('bar')</script>

This technique will be incredibly useful for debugging complex JavaScript applications, allowing developers to know exactly which script had just been injected and executed.

View Demo

Daniel has a knack for finding useful new techniques and this tip will be helpful down the road. Unfortunately only Firefox has implemented this event but I look forward to WebKit support soonish. Can you think of how you'd use this event?

Recent Features

By Eduardo BouçasJanuary 5, 2015
Write Simple, Elegant and Maintainable Media Queries with Sass
I spent a few months experimenting with different approaches for writing simple, elegant and maintainable media queries with Sass. Each solution had something that I really liked, but I couldn't find one that covered everything I needed to do, so I ventured into creating my...
By David WalshSeptember 3, 2014
Create a CSS Flipping Animation
CSS animations are a lot of fun; the beauty of them is that through many simple properties, you can create anything from an elegant fade in to a WTF-Pixar-would-be-proud effect. One CSS effect somewhere in between is the CSS flip effect, whereby there's...

Incredible Demos

By David WalshJanuary 29, 2010
Drag and Drop Z-Index Stacking
In an example for a previous post, I showed you how to use opacity during a drag'n'drop transaction. One bit I didn't account for was element stacking and bringing the most recent element to the top of the stack. To do...
By David WalshOctober 7, 2009
Do / Undo Functionality with MooTools
We all know that do/undo functionality is a God send for word processing apps. I've used those terms so often that I think of JavaScript actions in terms of "do" an "undo." I've put together a proof of concept Do/Undo class with MooTools. The MooTools...

Discussion

Kyle Simpson
It would appear from reading the spec (step 9 of http://www.w3.org/html/wg/drafts/html/master/scripting-1.html#the-script-element) that the only difference between this event and the load event (aka “onload”) is that load only fires for externally loaded script files, whereas this event fires for both external and inline script elements.

So, one could conclude that this event is only useful if you care to track the execution of inline script elements, otherwise you’d just use the much more ubiquitous and well known load event. I’m not really able to think of a great use case for tracking inline script elements finishing executing. Almost all such tracking of an inline script element would be from a script loader or dependency manager or other such code generator which created a new inline script element and did script injection to execute it. But in those cases, since JS is single threaded, and since such inline injection executions happen synchronously, you already “know” when that inline snippet finishes running because that’s the next line of your code after you injected it. :)

I suppose some niche uses might involve passively observing all script element behavior on the page, or developer tools, or things like that. But I think from what I understand, this event probably won’t have much added value for general developers over load, and could quite possibly confuse things if someone listened to both events.

Brandon
Just wanted to add some details to what Kyle said, the fact that this event allows users to know when inline scripts ran is already a use that no other method could provide, especially important for software development (add-ons).

Furthermore, unlike the load event, afterscriptexecute will only trigger when scripts executes, while the load event will also trigger for every single image that loads, or other element that triggers the same event. As such, afterscriptexecute is focused just on what the user wants and is less resource intensive than load on a page that has more than script elements triggering the same events.

This event, along with beforescriptexecute, are not just for some niche uses, they are in fact very useful for developers and its value is everything but irrelevant, especially since there isn’t any other way of listening to inline scripts unless the developer wrote it himself.

Mike Wilcox

beforescriptexecute works too! So you can get when the script loaded and how long it took to execute. Pretty cool.

var time = new Date().getTime();
var start;
document.addEventListener('beforescriptexecute', function(e){
	start = (new Date().getTime() - time);
}, false);
document.addEventListener('afterscriptexecute', function(e){
	var end = new Date().getTime() - time;
	var total = end - start;
	console.log('Script executed: ', e.target.src, start, end, '( '+total+' )');
}, false);

joe
Hi Mike,
beforescriptexecute ??
Do not work for me.
(Firefox 17.0.1 and win7)
qgustavor
There are security issues related to this?

afterscriptexecute Event

Recent Features

Write Simple, Elegant and Maintainable Media Queries with Sass

Create a CSS Flipping Animation

Incredible Demos

Drag and Drop Z-Index Stacking

Do / Undo Functionality with MooTools

Discussion