LinkedIn dynamic button rendering

It has become standard to offer sharing functionality via major platforms such as Facebook, Twitter and LinkedIn on websites. Most of the platform providers have multiple options for inserting their sharing features often including the use of an iFrame.
LinkedIn is slightly different however choosing only to offer a javascript based solution similar to the following:

<script src=”//platform.linkedin.com/in.js” type=”text/javascript”></script>

Above the inclusion of the required javascript function, and below the addition of sharing functionality where required.

<script type=”IN/Share”></script>

When asynchronous pagination gets involved however this lack of an iFrame causes an issue: the javascript is not called as the asynchronous load takes place. This issue stumped me for for a while until I found the simple solution to call:

IN.init();

Eugene O’Neill (Web Developer for LinkedIn) has stated:

1) IN.Parse() and IN.Init() are here to stay. While we do employ the policy that any undocumented methods may or may not be supported indefinitely, these two are uniquely crucial to the functionality of the framework. The amount of work it would require to remove IN.Parse()… I don’t even want to think about it. IN.Init() is our preferred method for loading the framework asynchronously and won’t be going anywhere. Feel free to use either method.

Using Google to host jQuery

Using Google to host your jQuery (or other applicable content) has several advantages over hosting a version on your own server including better caching, decreased latency, and increased parallelism. There are plenty of other articles to discuss the merits of decreased latency benefits of a CDN or the effects of parallelism on browsers so it wont be covered here.

Caching
Perhaps the most compelling reason to use Google to host your jQuery is that your users actually may not need to download it at all. If you’re hosting jQuery locally then your users must download a copy at least once. Your users probably already have multiple identical copies of jQuery in their browsers cache from other sites, but those copies are ignored when they visit your site.
When a browser sees references to a CDN-hosted copy of jQuery it understands they all refer to exactly same file. The browser trusts that those files are identical and wont re-request the file if it’s already cached.

Execution
So, now that we know that Google is a good place to serve up our jQuery from how are we going to do it? I believe the best way is also the simplest:

<script src=”//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js”></script>
<script>window.jQuery || document.write(‘<script src=”js/libs/jquery-1.7.1.min.js”><\/script>’)</script>

This will point to Google to host the jQuery library, but fall back to local hosting in the event of connectivity issues.

Reading GET variables with JavaScript

Recently I needed a JavaScript implementation of PHP’s $_GET functionality. There are a lot of quite bulky solutions out there, but my favourite was by Josh Fraser here

<script type=”text/javascript”>
function $_GET(q,s) {
s = (s) ? s : window.location.search;
var re = new RegExp(‘&’+q+’=([^&]*)’,’i’);
return (s=s.replace(/^\?/,’&’).match(re)) ? s=s[1] : s=”;
}
</script>

Short, simple, effective. Enjoy.