TL;DR: Prototypical/concatenative inheritance is much nicer than classical inheritance.

That said, first-class support for TypeScript in Visual Studio Code is quite awesome. While implementing the data structures, I came up with a TypeScript/prototypical hybrid style for writing object factories. In this hybrid style, the only place I’m writing any TypeScript is using interfaces for prototypes. Let’s take a number class for example:

I return a object whose prototype is prototype using Object.create, and its initial state using Object.assign.

This style allows VSC to shout at me if the prototype doesn’t implement the interface correctly. It’s nice to have, but not worth switching over to a TypeScript workflow from the Babel workflow that I’m already used to.

Migrating to Visual Studio Code

Last updated on
26th
of March,
2016.

I’ve been testing out Visual Studio Code for writing Node stuff, and I really like what I’m seeing so far. I’d like to confess that 99.9% of the reason why I even considered trying it out in the first place was its ability to debug Node apps. I tried Intellij IDEA previously and was so put off by the IDE-like interface (my Eclipse days are still not quite past me) that I couldn’t bring myself to migrate over.

On first boot I immediately taken aback by how familiar to Sublime Text the interface was. I might even add that it feels somewhat snappier, although I can’t pin it down to a specific thing.

A comparison of VSC vs ST, listing only the features that I’ve used and enjoyed and the features I’m missing:

What VSC has

Drag and dropping in the sidebar

Node debugging that actually works consistently and without fuss

If this was the only thing going for it I would still have used it

IntelliSense features

First class support for TypeScript

Nifty npm features

What VSC doesn’t have

Tabs

Sublime Text has the same intuitive tab handling as Chrome, and I was very surprised to see VSC depart from this pervasive pattern, instead opting for a strange “Working Files” way of handling, well, working files. It’s not completely bad, just strange. I’d love to see the usual tab handling functionality introduced into VSC as an option in the future.

Find in Files

I use “Find in Files” very regularly, and Sublime Text’s way of presenting the search results is still more familiar for me. VSC’s search results is tucked into the criminally narrow sidebar, which makes it very difficult to inspect the results.

No Emmet/Zen Coding package

Not that applicable to Node development, but I still use it occasionally for writing JSX

Babel/ES6 Support

Of course, debugging my apps in VSC would mean that it has to be set up to run ES6 code, and I’m happy to report that this is very possible and very easy. In launch.json, simply set the runtimeExecutable to the babel-node binary in your project’s node_modules:

Theming

I use Afterglow in ST, and I’m happy to report that there is also Afterglow for VSC (just search for “Afterglow” in Extensions).

Packages

I’ve also found the following packages to be useful so far:

ES6 Snippets

Not just ES6 - many handy JavaScript snippets waiting to expanded at the press of a ↹

Align

I use the Alignment package in ST a lot, and this one works just as well

Git History

For viewing Git history on a per-file basis or even per-line basis

Git Support

I prefer to manage my Git stuff in the command line or in Tower, so I don’t really care for VSC’s built-in Git support, although from cursory inspection it seems quite similar to SublimeGit (which I use only for git blame and git checkout).

Exposing React Performance Tools in the Browser Console

Last updated on
25th
of March,
2016.

The React docs on Performance Tools is quite lacking as to how it should be used, so I had to do some digging around to figure out how it worked.

It turns out Perf.start() doesn’t work in component lifecycles1, raising an ugly internal error that hasn’t been properly dealt with yet (see this issue for more details).

This prevents us from doing some things like:

Calling Perf and measuring performance repeatedly.

Using Perf to measure between arbitrary points in deeper parts of your component hierarchy.

I solved these problems by exposing React’s performance tools in the browser. There are a few ways to do this. If you’re using webpack, you can use expose-loader, which allows us to attach modules to the global object:

To fix this, the reference JavaScript implementation allows us to indicate the fields using a function that returns an object, instead of a plain object. This function is lazily evaluated during runtime, so we will not run into problems with the interpreter.

Exporting ES6 Library Modules as Global Scripts with Webpack

Last updated on
16th
of March,
2016.

After authoring a library (Remerge) using ES6 style modules, aside from consumption with npm, I also wanted to release it as a standalone script so that users could use it by simply including it with a simple script tag - well, if they wanted to, at least (appealing to the lowest common denominator here heh).