Reflections on NationJS 2013, part 1, the Morning Sessions

My morning began pleasantly with an easy drive from Columbia to Silver Spring. Kudos to the House Republicans who shut down the federal government just so I could have a faster commute to NationJS! I can’t say how much I appreciate having congressman who know how much I hate sitting in traffic and are willing to go to such great lengths to convenience me. As I write this now, it’s been nearly two weeks of the shutdown. I guess I forgot to tell my Tea Party friends that NationJS was only one day.

This very first NationJS was being held at the Silver Spring Civic Center, right next to the Silver Spring Metro Station. I parked right across the street for $1 an hour. Probably not the cheapest spot, but it won’t break the bank.

Breakfast was provided — muffins, bagels, coffee, juice. Quite a few people were there early, which surprised me. There were also plenty of extension cords, but I’m glad I brought my Haskell laptop, so I didn’t have to constantly worry about trying to find an outlet.

The following are my impressions of the four morning sessions I attended. They are in no way meant to be anything near a complete transcript.

New Rules for JavaScript by Kyle Simpson

Kyle started off the keynote with the statement “I’m known for strong opinions” which was a good sign. He introduced some of the projects he was working on such as

I’m glad he gave out the slide deck so I could review the talk later, as it was fast and dense.

Stop hating on == and implicit coercion

He stressed that the fundamental difference between == and === is coercion.

Coerced comparison (==) can be useful. To prove his point, Kyle showed a long list of coerced comparisons, of which only 4 gave an unexpected result. These results involved nulls, empty strings, 0, undefined, true and false.

Never treat null and undefined differently


Stop using anonymous functions

… to give better stack traces during debugging.

I’d considered naming all handler function call backs in the code base I’m working on, but decided against it because of complications with IE 8.

Kyle recommended using named function expressions even for IIFEs, something I’d never thought of. I was worried about the IIFE’s name escaping to global scope, but he answered that the IIFE name stays in function scope. A quick jsfiddle check proved him right.

(function myFunc() {
  console.log("inside ", typeof myFunc); // inside function
console.log(typeof myFunc); // undefined

Pay attention to bloated closure by watching where you define your functions

This was another interesting point I’d never even considered, but I’d have liked an example of a real world consequence of what happens when you don’t pay attention to where functions are defined.

Stop using this until you know how it gets assigned

Kyle made a succinct summarization of the rules of JavaScript’s this. Check out slide 52 “4 steps to this” of his slides.

Don’t mix this-style code with closure-style code

This is a rule I still didn’t understand even after carefully going over the slides. The end result seemed to be a recommendation to use function.bind() over the common var self=this technique to solve the problem that event handler functions have their “this” bound to the DOM node.

OO vs. OOLA (Class-oriented vs. Objects Linked to Other Objects

The last idea in the talk was the most profound, I think. Kyle made a distinction between the classical idea of OO inheritance vs. JavaScript’s prototypal inheritance and argued that we should stop making JavaScript work like Java and other OO languages.

Strong Type System Withdrawal? Methadone for JavaScript Confidence by John K. Paul

The driving idea in John’s talk was that for anyone coming over to JavaScript from a strongly-typed language such as Java or C# and misses the safety provided the compiler, the JavaScript ecosystem has developed a large number of tools to fill that safety gap.

In addition, there’s a large choice of JavaScript code beautifier/formatters out there:2

  • editor config — a plugin to popular editors to enable a moderate amount of format rules portability across IDEs. Plugins available for Sublime, Textmate, Vim, Emacs, and others., 
  • codepainter, based on the esprima parser, can infer your rules from sample JavaScript file without having to explicitly configure it.
  • js-beautify — available as either a github project or a website.
  • esformatter — A formatter whose objective is to supply many more options than js-beautify, still in beta

John Paul advocated hooking these tools into your build process, or even better, as a git pre-commit hook.

Afterwards, I asked him whether there was a way to get feedback even sooner than a git pre-commit hook, say on file save. We currently use an Eclipse ant builder save hook to run an ant task, but this means that we’re bound to Eclipse. He recommended grunt-contrib-watch to watch for file system changes, which I’ll have to look into later.

Prototyping a la Node with Express by Pam Selle

From the title of the talk, I expected more about Node and Express, but almost all of the talk was about user experience and testing, and I kept waiting for the talk to turn back to the technical stuff.

The talk began with a quick survey of some of the prototyping tools out there:

She chose Express because it’s fast and easy and showed a code snippet to set up express with less than 10 lines of code. The express.js tutorial from Evan Hahn was recommended.

The rest of the talk was all on user testing and went pretty fast, probably because I kept thinking about Express. All I remember are:

  • Liz Sanders “useful, usable, desirable”
  • nngroup’s ten usability heuristics
  • “Don’t offer feedback because people will try to please you.”

Fantasy Land WItchery by Brian McKenna

If I hadn’t read the talk abstract the night before and done some research, I would have been totally lost in this talk. Fantasy Land is a specification for using algebraic structure programming techniques in algebra, inspired by a blog post and discussions in the promises specification.

His main point was that a lot of what passes as innovation is really just accidental reinvention, and that by recognizing the algebraic/categorical structure underneath the programming implementation, we can achieve greater code reuse. The blog post cited above was a critique that the JavaScript promise was really just a special application of the monad pattern, familiar to Haskell devotees. Most JavaScript coders have never heard of monads, unless they’ve seen Douglas Crockford’s talk on Monads and Gonads. This talk was that and more, as Brian talked about semigroups, monads, comonads, and a bunch of other algebraic structures. It was too much for me to digest, but I was glad to at least have seen it.

He talked a bit about the Design Patterns approach to programming vs. the algebraic structures approach Brian was advocating. I wasn’t paying too close attention but I think that the main idea was that the Gang of Four’s Design Patterns are useful when you approach the programming from an OO point of view, but that algebraic structures are the more appropriate kind of Design Pattern when you approach the programming from a functional or algorithmic point of view.

Finally, he gave an example where the game of life was implemented in 150 lines with a monad and comonad in JS.3

UX Eye for the JavaScript Guy/Gal by John Athayde of Living Social

The talk started with an amusing example of ATM usability fail, and then a more somber historical example of the Iroquois Theater fire, in which 605 people died because the theater doors opened in and could not break away.

My notes for this session were rather bad, so all I have are a list of resources and miscellaneous advice

The most interesting part for me came at the end, when someone in the audience asked how the Agile process worked with UX design, and John replied that in his experience, that combination had been an utter failure. Afterwards, I followed up on this question asked John whether his Agile iterations were time-boxed or feature-boxed, and whether there was any difference between the two. As I suspected, he answered that the time-boxed failures of Agile with UX were worse and more frequent.

Next: Reflections on NationJS, Part 2, the Afternoon Sessions.


2 This lead me to Addy Osmani’s post.

3 Haskellers seem to like to do this exercise. I found an implementation of the game of life in Haskell using monads and comonads that I’ll have to look into later.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s