Plunk, Pen or Fiddle?

I’ve experienced some frustration recently with all of the big three code sandboxes: JSFiddle, Plunker, and CodePen. I’d originally picked Plunker because it provides the ability to create separate datasource files that can be used in my Plunks. This is extremely useful, especially when demonstrating how to load an external data source.

About a week ago while viewing my own post in Appliness digital magazine (shameless plug) I noticed that I couldn’t access the source code in the embedded iFrame. I wasn’t sure if this was an oddity with Appliness so I made a mental note to check it out.

The very next day I received a comment from a visitor stating that they were having the same problem when viewing the site on their phone. Obviously, I had a problem. I want my code to be viewable on as many devices as possible so I started looking into alternatives.



For looks, you can’t beat CodePen. It’s definitely the Ferrari of the bunch. Its sleek black skin and optional upgrades made me want to take it for a spin. The CodePen window is made up of four frames, HTML, CSS, JS, and the Output. Each code frame has its own set of additional features/libraries accessible via a small gear icon in the upper right corner.

CodePen’s additional features are very slick and useful. The HTML frame allows you to utilize three useful templating tools, Haml, Markdown and Slim, at the click of a button. CSS provides easy access to Less and Sass as well as some other oft-used CSS functionality, like reset. And JS frame applies clickable access to Coffeescript and Modernize, as well as allowing you to add any external library of your choosing. It also provides a useful link to where you can find a CDN reference to just about any library yo can think of.


CodePen felt great, looked great, and provided optional upgrades. Unfortunately, once you take it out of the garage and park it in your driveway, i.e., embed it on your site, it doesn’t necessarily run great.


As a matter of fact, my Angular code which works when viewed on CodePen, did not work at all on my site. The Ferrari of sandboxes actually seems more like a Fiero with a Ferrari kit.



JSFiddle seems to be the most widely-used sandbox. It’s the most utilitarian of the three…the minivan, if you will. Its looks are very basic, and while it claims the ability to apply different skins when embedded, the only skins available are “light” (light gray and white) and “presentation” (light gray and white with a gigantic font). You would think if there was a “light” there would also be a “dark”, right? Nope. This minivan only comes in gray.

Like CodePen, JSFiddle displays HTML, JS, CSS, and output frames. It provides access to a slew of libraries via a too-huge dropdown list. It also provides a second dropdown with esoteric options like “no wrap – in head”, which actually turns out to be quite important. The rest of the options are hidden in a vertical accordion.


The most important difference between CodePen and JSFiddle, however, is only apparent when it’s embedded. JSFiddle works and CodePen doesn’t.



Plunkr is a little different than the others. It’s no Ferrari, but it’s no minivan either. I guess it’s a Buick. It’s looks are more modern than JSFiddles, but its options are almost non-existent. The window only has two frames: code and output. You create your own files rather than using dedicated HTML, JS, and CSS frames. While this means that you can’t look at all of your code at once, it actually lends to its flexibility.

With Plunkr you can create multiple files in the same project. This means you can test more abstractly, and easily swap functionality in and out. Your HTML head is in your code window making it easy to see what’s getting loaded. Being able to create your own files also means being able to create external datasources, which is fantastic for playing with dataloading functionality.


The biggest problem with Plunker is the one I mentioned earlier. When it’s embedded, you can’t view the source files on mobile devices.

So, what do you drive, a Fiero/Ferrari, a minivan, or a Buick? Or something entirely different?

Super-Easy Angular Image Gallery

Check it out!

Learning Angular has been a fantastic experience so far. I’ve been consistently surprised at the results I can get from a screenful of code. This week’s Image Gallery experiment was no different. Before I get into the particulars, let’s take a look at the finished product:

[iframe src=”″ height=”565″ width=”675″]

If you check out the source app.js on that example you’ll notice that the JavaScript adds up to about 25 lines of code, half of which are dedicated to loading and setting the data source. Yes, there’s some CSS3 transition coolness thrown in, but even that is minimal.

So How Does It Work?

The gallery is made up of three sections: the main image, the caption, and the thumbnails. If you compare the main image section and the thumbnail section you’ll see that they’re very similar. The main difference being the size of the image how many of the image you can see:

<div class="mainimageshell">
    <div class="viewwindow">
        <ul id="fullscroller" class="fullsizelist" ng-style="listposition" >
            <li ng-repeat="image in galleryData">
                <img id="fullsize" class="large" ng-src="{{image.image}}" />

<div class="captionshell">
    <p class="caption">{{selected.desc}}</p>

<div class="thumbsshell">
    <div class="thumbswrapper">
            <li ng-repeat="image in galleryData">
                <div class="thumbwrapper">
                    <a ng-href="" ng-click="scrollTo(image,$index)">
                        <img class="thumbnail" ng-src="{{image.image}}" />

If you were to comment out the overflow line of the viewwindow class you would see all of the images lined up side by side, just like the thumbnails.

When iterating over the data using ng-repeat, $index will reflect the zero-based index of each item. Since we’re looping over the same data, the index for both the large image and the thumbnail will be the same. This allows me to multiply the index by the width of the images to arrive at the new positioning for the large image list. Once I specify the new positioning, my CSS handles the transition, something like this:

    transition:  left .8s ease;

Thanks to Angular, notifying the DOM element of its new position is ultra-simple. If you take a look at the fullscroller UL inside the template you’ll see that it contains the Angular ng-style directive and that it’s bound to the listposition property. Listposition is updated in the scrollTo function every time a thumbnail is clicked and any change is immediately reflected in the view:

// Scroll to appropriate position based on image index and width
$scope.scrollTo = function(image,ind) {
    $scope.listposition = {left:(IMAGE_WIDTH * ind * -1) + "px"};
    $scope.selected = image;

In addition to modifying the viewwindow position, the scrollTo function also assigns the currently selected item to $scope.selected. If you look at the template you’ll see that caption is rendering “{{selected.desc}}”. When $scope.selected is changed, the caption will automatically change with it.

Full Disclosure

My original idea was to fade out the old image and fade in the new image when a thumbnail was clicked. This worked great on Chrome, but Firefox would flash the image on screen once loaded and wouldn’t transition in properly. It also required transition end listeners, which at the moment are not standard across browsers. That meant separate listeners for each browser engine.

The whole thing was becoming a hassle and the code was getting unruly. That’s when I made the decision to switch to a slider and it worked out great. Point being, don’t be afraid to experiment or refactor. Oftentimes the best coding decisions are born out of a change in approach.