draft.js: Map changes in the filesystem to events on the client

draft.js: Map changes in the filesystem to events on the client – I studied architecture at a school that really emphasized hand drawing.

I spent a lot of time at a drafting table with a set of old Dietzgen drafting tools.

One thing I came to really like about drafting tools is that they’re atomic.

Finding your preferred workflow with drawing tools takes time, and everyone has their own way of working.

Developing a good relationship with your tools both by using them, and by finding the ones you prefer noticeably improves your work.

It seems like Bret Victor understands this. Light Table looks like a good start.

What I want are discrete tools for making the process of building software faster and more fluid, and I want them to work with the stack I’m already chest-deep in: Node on the server, Backbone on the client.

So I built the simplest shim I could think of that cuts down time between writing code and seeing it work. It’s called Draft, and you can find it on GitHub here.

Draft maps changes in the file system on the server to an array of methods on the client.

See a change in your compiled CoffeeScript? Reload the page. Change in the CSS?

Add a method to refresh it. See a new image file appear? Recreate that element.

Draft comes with the reload method built in, and can be extended however you like.

I wish coding was more like drawing, and I wish drawing was more like coding.

Coding separates thinking about how something will work and seeing it work completely.

This means that I have to wait some amount of time between making a change and seeing it in action.

Drawing is the opposite. I see the changes as I make them, and they become a part of my thought process as I’m drawing.

Drawing is kind of extension of thought. It’s natural and fluid — completely non-segmented, completely smooth.

We use drawing to refine our thinking about something we’re going to make.

Aside from fine art, drawings are rarely the end result.

They sit next to the final product in deep stacks of sketches, schematics, plans, and so on.

This is one of the greatest things about writing code.

The code you write is exactly what performs out in the world.

A sketch in code can become a complete piece of software and still retain the ten lines written as a proof of concept.

I find this really satisfying.

Draft is a tiny start at eroding the gap between drawing and coding, and I find it a lot cleaner than Cmd + Tab, Cmd + R.

It’s also atomic and extensible.

I doubt any piece of software will dominate our entire experience of writing code, just as no piece of machinery dominated the experience of drafting plans.…