Why your jsFiddle no longer works (and how to fix it)

 
If you’re unfamiliar with jsFiddle I recommend you check it out – it’s a great, free playground and an essential tool for web developers. So essential that, over the last few years, it has become almost mandatory for Javascript developers to create a jsFiddle to collaborate on problems with remote colleagues, to offer a library with working, interactive examples, to test proof-of-concepts or to troubleshoot errant code. I’ve lost count of the number of requests for help on Stack Overflow whose first reply is “jsFiddle or it didn’t happen”.

Combining jsFiddle’s interactivity with GitHub’s hosting and version control can greatly increase uptake of your public project. By linking your jsFiddle to GitHub’s raw output you can offer a no cost, no download, no fuss intro to your code.  Instead of asking fellow developers to download and set up your GitHub hosted library you can provide working code examples that instantly show how your code should be used and if it does what they expect it to in they way they expect it to do it. Or rather, that used to be the case. Recent browser changes, particularly to Google Chrome, mean than many existing jsFiddles no longer work. There’s no obvious error but no output appears in the Result.

Click to embiggen

The problem

The problem is simple enough – the external Javascript libraries we are loading from GitHub are no longer being executed. To see why, we need to take a step back. Let’s assume we have a library in GitHub that we want to use in jsFiddle.  To do so, we add the URL of the raw GitHub source in the External Resources section of jsFiddle. This has been common practice for years and used by pretty much everyone because it was easy, convenient and, best of all, it worked.

Adding an external resource to a jsFiddle
Adding an external resource to a jsFiddle. Here, the jlist-min.js library is being loaded directly from raw.github.com.

 

Unfortunately, it worked despite the fact that it shouldn’t have. Files served from raw.github.com are served with a content-type of text/plain. This didn’t used to matter but browsers such as Google Chrome have tightened up security and will now only execute Javascript code that has a content-type of application/javascript . If we look at the console in Chrome Dev Tools while in a jsFiddle that links to raw.github.com we can see the problem:

The error that appears in the Google Chrome console when we link to raw.github.com.
The error that appears in the Google Chrome console when we link to raw.github.com.

What was once acceptable (and very common) practice no longer works.

The solution

Luckily the solution is both simple and less wordy than the problem.
There is a 3rd-party service which will proxy the file you need from raw.github.com and change the content-type before your browser receives it.
To make use of this service, all you need do is remove the full stop (period) from between raw and github in the offending url.
That is

http://raw.github.com/rest_of_the_path

becomes

http://rawgithub.com/rest_of_the_path

 

and your jsFiddle is working again.

 

More:

One thought on “Why your jsFiddle no longer works (and how to fix it)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s