Monthly Archives: March 2016

I am looking for work.

I got laid off, and I’m looking for work. I’m not in a rush, financially-wise, but working is a ¬†good thing that I want to do.

Basically, if you know about any developer job openings in Portland OR, please let me know! Feel free to share this post with people who might know of one ūüėÄ

In the simplest of terms, I am looking for a midlevel web developer position working full-stack, or front or backend.

Here are some key words: I am a midlevel web developer with over a year’s professional experience working in many technologies across the stack: Ruby on Rails, myriad JavaScript frameworks (Angular, Ember, React, Polymer), and Postgres, MySQL, and Mongo. git AND Mercurial. Also, plenty of devopsy-type nuggets, e.g. deploying, using Travis CI and Errbit.

I’ve got positive references from my former employers and coworkers at Notch8. I place a high value on the happiness of¬†the team I work with, and I’m fun + cool.

I am going to stay in Portland. Because of my transportation situation, I’d prefer a job that is within ten miles of where I live in SE.

The best way to contact me is by email: vcolavin at gmail dot com. I’m @vincentcolavin on twitter.


Leave a comment

Filed under Uncategorized

DOM Glossary

Look at you. Learning React. Learning Polymer. Angular. Ember. Holy cow, that’s a lot of JavaScript things. Good on you. You know so much JavaScript, and so many words *about* JavaScript, so many verbs and nouns and gerunds and part pasticiples and innerjections. But now all those words are starting to get all wacked out in your head pudding. Your brain hole.

That’s confusing as heck. Let’s talk about words that have the word “DOM” in them, because, it turns out there are a lot when you’re learning JS frameworks, especially Polymer.

Warning: I’m writing this article mostly to suss things out for myself. If there’s an error please let me know!

Here are the ones I’ve run across so far, and where they live:

  1. The DOM (everywhere)
  2. Local DOM (mostly Polymer)
  3. Light DOM (mostly Polymer)
  4. Shady DOM (Polymer)
  5. Shadow DOM (mostly Polymer (for now))
  6. Dominic “Dom” Toretto (The Fast and the Furious)
  7. Virtual DOM (React)
  8. Sub DOM (HTML5 canvas elements)

First of all, let’s acknowledge the fact that some of these names are just really poorly chosen. Don’t Light DOMs and Shady DOMs sound related? Well they’re not.

Alright let’s get into it.


This is the Document Object Model that, if you’re a web developer, you probably know about. The general DOM. The “cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents.” It’s an API. It’s a tree. It’s what you interact with when you’re on the elements tab of Chrome’s developer tools.

Here’s my attempt at a simple, functional definition: HTML elements and the way they are arranged; the understanding that elements can be children, siblings, or parents and accessed through each other. An element can only have one parent but unlimited children and siblings.

Local DOM

The elements of the DOM created and managed by a particular component.

Light DOM

The children of a particular component. The distinction between the Light and Local DOMs is a little subtle, but basically the Light DOM includes all of the element’s children, where the Local DOM is restricted to those which it manages directly.

That is to say, if Component A contains Component B, Component B’s children (its Light DOM) is part of Component A’s Local DOM, but not its Light DOM.

The Light DOM doesn’t have much to do with the…

Shady DOM

A polyfill Polymer uses when the Shadow DOM isn’t available.

Shadow DOM

This one’s more complicated! Although I’ve mostly seen it discussed in the context of Polymer, it’s actually a W3C working draft / HTML5 thingie which will be implemented in future browsers and allow web components to be written without any fancy third party libraries.¬†Read the specification here¬†if you need help falling asleep.

The intention of Polymer is to act as a polyfill for web components. Hence the name. The Polymer developers just don’t want to wait around for the Shadow DOM and native web components to become a widespread reality.

So. The Shadow DOM is a web component’s Local DOM with a bonus stipulation: it cannot be directly accessed. Traditionally, a developer can reach into any part of the DOM. The Shadow DOM will allow a component to have complex internal structures but enforce it being treated as an atomic element.

The inner workings of Shadow DOMs can be styled using the `::` selector, but you won’t interact with them otherwise.

Dominic “Dom” Toretto

The main protagonist of The Fast and the Furious franchise, played by Vin Diesel. He is an ex-convict with a heart of gold, but not currently under consideration by the W3C. Like the Shadow DOM, his inner workings are mysterious.

Virtual DOM

This glossary¬†has mostly dealt with Polymer things, but my intention is to untangle my personal internal mess of DOMs. This is a React thing. The Virtual DOM is a copy of the regular ol’ DOM that React keeps on hand to diff from the real DOM in order to trigger more efficient renders. It also means that React can be run server-side and generate HTML, which is pretty sick.

Canvas Sub DOM

The HTML5 canvas element’s accessible fallback content, which exposes information to assistive technologies like screen readers. When used correctly, it allows a one-to-one mapping between interactive canvas elements and keyboard commands. (I copied some wording for this definition from¬†this article by Steve Faulkner.)

There you go! Again, please let me know if I’ve made mistakes so that I may correct them. I think this is *generally* accurate, though, and should serve as a good point from which to start untangling these almost-homonyms.

Update on 3/4/2015: Added the Sub DOM. Thanks to Ted O’Connor¬†for the tip.


Leave a comment

Filed under Uncategorized

JavaScript function naming

For the record, other people have written about this specific thing. But now I am writing about it.

What’s the difference between the following ways of writing functions in JavaScript?

  1. var hello = function() {};
  2. function goodbye() {};
  3. var somethingElse = function whatever() {};

ES6’s arrow syntax (e.g. myFunction¬†=>¬†1 + 1;¬†) is roughly equivalent to the first snippet, at least for our current purposes.

If you answered “basically nothing” or “isn’t it just a preference thing”, then, yeah, that’s how I think about it in practical terms too. I mean, you shouldn’t be jumping around between these conventions within the same app. Best to just pick one. Not the third one. You might pick the first version because it lets you assign functions to variables just like you’d assign other values to variables, and that just looks neat and appeals to your aesthetic.

But you’ve probably heard of JavaScript’s anonymous functions (like the function you pass as a callback, right?) and maybe weird scope things like hoisting. Hoisting is one of the weirder parts of JavaScript, but it’s got some cool implications when you’re doing OO things like IIFEs. I also find it comes in handy when writing Angular.

Just to get my initial question out of the way,

  1. Assigns an anonymous function to the variable “hello”. This is called function expression, which is to say that “function() {}” is an expression which is evaluated and assigned.
  2. Declares a function named “goodbye”. This is function declaration. It will be hoisted to the top of the current scope.
  3. Assigns a function named “whatever” to the variable “somethingElse”. This is a “named function expression”. It’s messy enough that I’d suggest avoiding it generally, though it’s useful when you need assign a recursive function to an object property.

Functions in JavaScript are a special kind of object, so they have attributes accessed through dot syntax. They have a built-in attribute called “name”. Check it out: ==========> undefined ========>¬†“goodbye” ====> “whatever”

Cool, right? But also not very useful. All the functions are called just the same, with parenthesis. The practical difference is hoisting. A hoisted function will be available for use at the top of the scope in which it is declared, even if it hasn’t been “declared yet”. Consider the following code snippet:


function firstFunction() {console.log(“this is the first function”)};


var secondFunction = function() {console.log(“this is the second function”)};

Go ahead and paste the above (in one chunk) into your JS console. It should successfully log “this is the first function”, but throw a TypeError¬†on when it hits the¬†third line. This is because firstFunction’s declaration was hoisted up, allowing us to call firstFunction() *before* its declaration.

This is pretty nifty, but it doesn’t it smell a little? As a rule, I usually prefer the flow of my program to be explicit and as well-ordered possible. In functional (ie not OO) vanilla JS, I use the first syntax.

The best use case I’ve found for it is in Angular, thanks mostly to John Papa’s Angular Styleguide. When writing a directive or factory or whatever, you show what functions are available in that segment, but stuff the nitty gritty implementation details down at the bottom of the file. It’s pretty nifty.

That’s the gist of it! JavaScript scoping is a deep subject (read: it’s a mess), but hoisting is an important piece of it. Please let me know if you’ve got any questions or corrections!

Leave a comment

Filed under Uncategorized