Too Early

A story (from ~2009-2011)...

In early 2009 I wanted to be able to run my JS code -- things like data formatting/validation, templating, etc -- on both the browser and the server.

There was no Node.js yet. But I knew about v8, and I had some rusty C++ skills from a decade earlier. So I set about to build...

I built BikechainJS, a synchronous server-side JS environment which used v8 to run JS in a CGI per-request context (somewhat like PHP, etc).

BikechainJS supported stdio, fs, process execution, sandboxing, cross-request storage (ie localStorage), chainable promises, etc.

I wrote all of this mostly alone (+ some help from friends like Kris Kowal ), as a side project, because I wanted this server-side capability to use for work projects, and had it working in mid-to-late 2009.

I deployed it at my job at the time, which was a PHP + Grails shop.

Around this time, there were very early ideas for what would eventually be Promises in JS. I was on various standards lists and participating (and lurking) around that early work.

And I designed a Promise capability for Bikechain.

My Promise was a chainable API, with .then() calls. What was special about it was, it detected internally if it was running in a sync env (Bikechain) or async (browser), and normalized the task execution accordingly.

So I could write the hybrid style code (later annoyingly called "isomorphic" by the in-crowd) that ran correctly either in Bikechain synchronously, or asynchronously in the browser, with no changes.

I also continued working on my templating library, even as I changed through a few brief jobs.

My templating engine used partials (like mustache), but it had some dedicated (non-turing-complete) JS-like logic syntax.

It was called HandlebarJS. Shortly after I launched it, I heard about another templating by someone more famous than me, called Handlebars.js -- no relation. Rather than fight over the colliding names, I renamed mine to Grips.

The main design constraint of Grips was, DON'T provide a full turing-complete logic syntax, because that would invite devs putting business logic into their templates (bad!).

I asserted: if you couldn't do some logic in your templates, it's because you SHOULDN'T.

In late 2009, I was at JSConfEU when Ryan introduced the world to Node.js, a v8 server-side JS env that's asynchronous.

It obviously was exciting, and way more mature than my Bikechain, but I couldn't figure out how to make it work in sync per-request CGI envs like PHP/etc.

So I kept developing Bikechain well into 2010, as everyone else was excited by the early steps of Node.js. I felt like there needed to be an easy way to adapt server-side JS into existing non-JS server apps that ran synchronously per-request. Bikechain was intended for them.

At a new job (a JS consultancy) in late 2010, I convinced them to let me work on Grips + Bikechain more. I decided to add features to grips, and try it out on various apps for their clients (purely experimental R&D).

The first thing I added to grips was that the templating compilier/runtime tracked the partials boundaries and what state values were passed through.

When a state value was updated, Grips knew the smallest partial that needed to be re-rendered to update the page's DOM.

That was sort of an early idea somewhat like virtual DOM diffing, but against the template tree, not the DOM.

The granularity you could get from DOM updates was only limited by how granular you separated templates into partials. you could choose, down to individual DOM elements.

The next thing I added was, since grips worked on server and client, template partials could be rendered initially on server, as a placeholder, then be re-rendered client side once the data was finished loading and dynamically loaded into the client.

Or the server could re-render that partial itself, and just push up the new HTML, and that new HTML was directly patched into the DOM.

Remember, all of this was working in late 2010. I was giving various conf talks that year about this "hybrid" and "middle end" JS architecture.

Then in early 2011, I worked on pushing the "hybrid" idea even further, with the ability for the templating engine (and data transfer layer) to monitor how quickly re-renderings performed, and it could transparently shift the load between server and client depending on perf.

I had built several PoC apps of this stuff for that employer, and they seemed to be impressed. But none of their clients seemed ready to take the leap into such unproven territory. And by then, Node.js seemed clearly to be "winning".

Eventually, that employer basically stopped paying me to work on these ideas, since they couldn't justify it with any paying clients. My boss (one of the founders of the consultancy) told me that they believed these ideas were just too early, perhaps 18-36 months too early.

Soon after, I left that company, and moved to Mozilla. That job had no need for anything server-side JS, or templating, or any of that. So I shelved all that work by Q2 of 2011.

I would come back and toy with some of it a bit in my side time, over the next year or two.

But eventually, it was clear that other approaches by bigger names were clearly winning. Angular.js, then React (and virtual DOMs), etc... and all the wave of client-side SPAs since. They all took off over that next 2-4 years.

Look, I'm glad that Node won, and I'm glad that many great JS frameworks were invented, and won the mindshare at their various times. All that has been great for the industry.

TBH, none of what I did with Grips and Bikechain probably had any impact on any of that stuff. It was all just me doing it.

As my employer said, I was "too early". Certainly not the first time, nor the last time, I've been told that. I have a knack for it I think.

Anyway, just wanted to tell this story because... it's not told anywhere else as far as I know. None of it will ever show up in wikipedia pages or fancy documentary videos for any of these big projects.

I bet there's countless other stories like mine... unknown, lost to time.