Friday, August 30, 2013

Obfuscation for its own sake

Wow... I just discovered Twitter Widgets (I needed them for a project I'm working on). When you create them, you get a code fragment to paste into your site to include the widget. Here's mine:

<a class="twitter-timeline" href="https://twitter.com/mdpopescu" data-widget-id="...">Tweets by @mdpopescu</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+"://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

Look at that piece of Javascript. Marvel at its obscurity. Find out it can be replaced by:

<script id="twitter-wjs" src="//platform.twitter.com/widgets.js"></script>

I mean, seriously?

Minor nitpick: yes, that javascript code will not re-create the script tag if the id has already been defined. However, I think the proper place for that is inside the widgets.js file... which they already do. Yay.

2 comments:

Bertrand said...

I would agree that the http/https stuff is just silly, but one thing that your version does is block the page until the script loaded, whereas theirs doesn't.

Marcel said...

Point. Though, since it's not in the onLoad event, or whatever it's called it might still block - I have almost no experience with the DOM loading mechanism so I could be wrong.

Thanks for the comment!