I've been using a component-first approach when working with these libraries, and found Storybook to be an invaluable tool for react development. Before giving Vue a try, I looked for a Storybook-like alternative and was pleased to find vue-play.

While not as sophisticated as Storybook, vue-play does meet the basic need: show a list of components and their configurations.

@egoist has put a lot of work into making the package as easy to install as possible. In this post, I'll describe how I added vue-play to my existing vue-cli webpack project.

I created a more detailed (and updated) set of instructions here. I will leave the following in place for older versions of vue-play.

The first step is to get the pacakges:

npm install -D vue-play vue-play-cli

Note that we'll be using vue-play-cli to make the webpack magic happen. I've tried manually configuring webpack for vue-play, and found it to be a huge pain.

Next, add a play script to your package.json. Your scripts section should look like this:

"scripts": {
  "dev": "node build/dev-server.js",
  "play": "vue-play start ./src/play --webpack-config ./build/webpack.dev.conf.js",
  ...
},

Now add src/play/index.js. I recommend using a script to load all of your scenarios (stories) for you. Mine looks like this:

import { configure } from 'vue-play';

// import any global css for your application
import '../css';

const load = requireContext => requireContext.keys().map(requireContext);
const scenarios = load(require.context('./scenarios', true, /.js$/));
configure(scenarios, module);

In other words, it looks through the src/play/scenarios directory and automatically loads all the js files. This ends up being a lot easier than manually importing them each time one is added.

Finally, we'll add a scenario - this example will be src/play/scenarios/FancyButton.js:

import { play } from 'vue-play';
import FancyButton from 'components/FancyButton';

play('FancyButton', module)
  .add('default', h => h(FancyButton));

When you're ready, you can npm run play and browse your components. Enjoy!

In JavaScript, it feels like nails on a chalkboard whenever I see a conditional which redundantly evaluates to true or false. Take this example:

var isEmpty = function (array) {
  if (array.length === 0) {
    return true;
  } else {
    return false;
  }
};

Because isEmpty should return true or false, the developer did exactly that. However, he failed to realize that the condition itself is already a boolean. The same function could be rewritten as:

var isEmpty = function (array) {
  return array.length === 0;
};

Here's an example where the condition is not already a boolean:

var docExists = function (id) {
  if (Collection.findOne(id)) {
    return true;
  } else {
    return false;
  }
};

In this situation we should use a !! to coerce the result of findOne:

var docExists = function (id) {
  return !!Collection.findOne(id);
};

And that's it! Now go write fewer lines of code.

With the rising popularity of ES6, I decided to read Axel Rauschmayer's excellent book and take it for a spin with some of our new projects. Listed below are my initial impressions after having written a couple of thousand lines with it.

Variable Declarations

ES6 comes with a ton of features which are not supported in CoffeeScript, such as maps, sets, symbols, generators, and promises. However, I've found that let and const are profoundly important. Having block-scoped variables removes a significant number of potential gotchas in JavaScript. const, in particular, provides both a write lock and a visual cue that's compelling. I use it everywhere I can in our code.

Modules

I haven't yet experimented with modules, as they aren't available in meteor 1.2. However, with 1.3 and beyond, the module syntax will enable the build system to make substantial optimizations including dead code elimination and lazy loading. In other words, once meteor understands how your modules are connected, it can do things like ship smaller binaries and load your code only as needed.

None of these optimizations exist at the time of this writing, but their potential is game changing. Although CS doesn't have ES6-style imports and exports, meteor will be supporting the feature via CommonJS-style require statements. [1]

Punctuation

CoffeeScript is concise and JavaScript is, comparatively, verbose. My biggest concern about this switch was that I'd end up writing many more parens and curly braces. While this is true, I'll say there is something liberating about knowing exactly what my code is doing without having to periodically paste snippets into a transpiler. For example, does subtractNumbers 12, addNumbers 5,7 actually do what I think it does?

Surprises

Even though ES6 was heavily influenced by CoffeeScript, some syntax features didn't make the cut. Here are the two most glaring omissions:

Existential Operator
In CS, we have the existential operator ?, which lets us write x? instead of
typeof x !== "undefined" && x !== null. It's 2016, and we still don't have a suitable shortcut for testing existence in JavaScript, which is just absurd.

Arrow Functions
ES6 gave us "fat arrow" functions, but deliberately left out "thin arrow"functions (those which don't give you a lexical this). While this solves some annoying issues in JS, it introduces the opposite problem where programmers blindly replace function with => and end up binding the wrong context. When the ecmascript package became available in meteor 1.2 there was a continual stream of questions on StackOverflow related to this misunderstanding.

You may be asking, "but don't you want a lexical this the majority of the time?" As it turns out, a linted CoffeeScript codebase provides the perfect answer to this question: no. At Edthena, 98% of the time we use ->.

Linters

In the past year, we've made heavy use of CoffeeLint, which has been an adequate way to enforce style throughout our codebase. Using a linter with CoffeeScript is nice, whereas with JavaScript it's a necessity because of the potential for leaking global variables (among other things).

The good news is that some combination of jscs and eslint can provide you with solid protection against yourself. The bad news is that you need to have a Ph.D. in eslint in order to configure it. Have a look at the one from mantra's example app here. Yikes.

Final Thoughts

Overall I enjoy writing in ES6 more than I thought I would, and it's nice to use the same language as everyone else when posting publicly.

My initial concerns over having a punctuation explosion in our code have been somewhat alleviated by using a decent editor. For those using atom, I'd recommend the jscs linter which can auto-correct your style blunders when saving.

Best of luck to anyone making the switch. Feel free to post a comment and tell us how it's going.

[1] Thanks to Loren Sands-Ramshaw for pointing this out.