JS Bin is a great tool for doing simple JavaScript and front-end code experiments. When you come across something in your Ember app that leaves you scratching your head, distilling your problem case into a JS Bin is a good way to think through what’s going on.

Transferring a pathological code case from your app to a JS Bin forces you to cut extraneous code and focus in on the source of the problem. This is a useful exercise in itself because it helps you to ascertain that you have truly found a bug in framework code and not your own app code, but it also helps you to understand the bug so that you can work around or fix it.

In addition, and perhaps most importantly, having a code sample in a JS Bin makes it easier for you to share the live bug with others. Step one in fixing a bug is to be able to repeat it, so having a live JS Bin that you can include in a github issue makes it much easier for other contributors to confirm and fix the bug.

Crafting an Ember JS Bin can be something of a dark art, though. Ember-cli provides a lot of excellent tooling that isn’t available in a JS Bin, so writing an Ember JS Bin has become a different skill set than the ES6 module-importing style that is the officially sanctioned way to write a new Ember app, and is increasingly not part of the official Ember documentation.

This post describes a few of the differences between making an Ember JS Bin and the current state-of-the-art in Ember coding that you’ll find in the Ember-cli-focused guides. Hopefully the next time you discover a mysterious bug in your app you’ll be able to use the notes here to craft an example JS Bin and help get the bug fixed.

This post goes into a fair amount of detail in order to describe not just how to make an Ember JS Bin but why it works as it does. If you are more interested in learning only the nuts-and-bolts, start with this annotated Ember JS Bin and fork it for your own purposes. More JS Bin examples are included at the end of this post.

Dependencies

Ember-cli manages including your Ember dependencies for you, but in a JS Bin you’ll need to include them yourself with script tags.

To run Ember in a JS Bin you need at a minimum the following 3 libraries:

jQuery — Ember depends on jQuery

ember-template-compiler.js — Because you will embed templates in your HTML and they will be compiled at run-time. More on this below

ember.js — For obvious reasons

To include these dependencies, use the time-honored tradition of simply dumping them as <script> tags into the <head> of your HTML.

You can serve jQuery from Google’s CDN. Here’s the script tag for version 2.1.4:

<script src=“https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js”></script>

The two ember-related scripts are hosted at builds.emberjs.com. You can choose a tagged build or a named channel build (release, beta or canary). If you suspect your bug is with a specific version of Ember, you should use a tagged release with that specific version, otherwise your Ember version will “float” and change with the release cycle. Today’s canary is next cycle’s beta, for instance. At current time of writing the release channel build is Ember 2.0.1, but it will be 2.1.0 before too long — if you are demonstrating a bug in 2.0.1 but use the release channel build of Ember in your JS Bin, in a few weeks your JS Bin may also be using 2.1.0, which may no longer include the bug your JS Bin was supposed to demonstrate!

Use the same ember-template-compiler version as your Ember version.

The Ember official site includes a list of the version-tagged builds as well as the current release, beta, and canary channel builds. Use the “Script Tag” button to copy the appropriate script tag for inclusion in your JS Bin. Unless you have a specific reason not to, use the ember.debug.js version because it includes helpful debugging information.

“Globals Mode” Ember

In a JS Bin, the ember.js script tag that you’ve included will add a top-level global, `Ember` to the window. All of the Ember primitives you’ll need are available as properties on the `Ember` global. You can use `Ember.Application`, `Ember.Route`, `Ember.Component`, and so on. In Ember-cli you `import` your Ember global, but you otherwise access the Ember primitives in the same way, so this should be familiar.

The biggest difference between an app running via Ember-cli and a JS Bin is in how you structure your code to inform Ember where to find your Routes, Components, etc. In Ember-cli, the file structure is used to determine those pieces, but in a JS Bin you don’t have separate files that can `export`, so there needs to be another way for Ember to find and use your code.