Earlier this year I blogged a lot about a web app project I was working on that used mostly Ruby stack: Padrino (sinatra + stuff) on top of Riak + Redis for persistence + ElasticSearch for search + Davis.js + my own Backbone-ish model with ajax persistence. I reached a point where I had just implemented some markdown extensions in my javascript preview library & realized that I’d have to re-implement them in Ruby. At that moment I stopped and pondered the virtues of the single-language stack.

And then I got a job in San Francisco. That plus commuting has been hell on personal projects. I resurrected it recently, though, because I discovered a massive itch that needed scratching that was similar to (but not identical to!) the previous project. Thus Project Two, Electric Boogaloo was born.

The stack isn’t quite the same:

javascript + node.js
couchdb for document persistence via cradle (this project is much more document-centric than the other one; this could easily be swapped out for riak if necessary)
redis for fast indexes (am using couch views as little as possible, since all the operational stories discuss their suckage)
redback for some higher-level data structures built on redis
my own model schema + persistence layer (actually separate!)
express.js for serving web pages
blade for templating
ElasticSearch for full-text search via my own very thin wrapper
and a few smaller packages, like my fork of marked for github-flavored markdown, prettydate so javascript can have strftime() like a civilized language, and so on.

I also finally broke down and started using the async flow control library. If there’s anything I hate, it’s boilerplate. And node.js callback error-handling is boilerplate at its repetitive code-cluttering worst.

I haven’t done anything on the client-side that needs a single-page app just yet. But if I do, I’ll use davis.js again, again with my own non-backbone model library. Backbone made me write reams of boilerplate. You know what I think about that.

Javascript is such a dangerous and loose language that I’ve been trying to maintain some strict discipline with myself about the code. Not just formatting (which I’ve always had strong opinions about) and not just running linters. I’m trying to stay modular with small files and small pieces that work together and aren’t interdependent. Any single piece should be something I could swap out.

This week I’ve been wiring up ElasticSearch. My next programming session should have documents being indexed on their way into the system. The one after that will start implementing a search API that is intended to be consumed by two kinds of web pages (a general “search stuff” text box that tries to guess what you mean, and a tweaky search form, the kind with a zillion checkboxes) plus the externally-focused json api I’m planning. I’ve been trying to write design documents for myself as I go on this project. Not just for myself! My plan is to open it up as soon as I have a site running with alpha-level features.

As always, it was raving frustration with a really-badly-written and -performing existing site that motivated me to start this one. Niche audience, though. No idea how I’m going to make it self-sustaining given the user base. Yes, I haven’t told you what it is yet.

6javascript, programming, project, medium,

Yesterday I migrated my project from jquery to Ender. Ender isn’t a library itself, but instead a tool for building javascript libraries from components. It offers something close to the jquery feature set at a much smaller size. If you don’t need everything that jquery does, or if you don’t need the massive backwards compatibility with broken browsers it gives you, ender might be a win.

I had the problem of making my client-side router (davis.js), my client-side templating, and some jquery plugins work.

First, davis.js. The minimal ender build for this needs events, selectors, a dom manipulator, and a dom ready check, aka their “jeesh” package:

ender build bonzo bean qwery domready

I encountered two minor problems. First, davis.js explicitly looks for jquery, not for anything pretending to be jquery in the infamous $. So before you construct your app, tell Davis to use the Ender $:

Davis.$ = $;
var myapp = new Davis.App();
// etc

Second, Bean, the ender events library, doesn’t appear to stop the propagation of delegated events the way jquery does. So Davis needs to do so explicitly in its delegates:

var handler = function (targetExtractor) {
    return function (event) {
      if (differentOrigin(this)) return true
      var request = new Davis.Request (targetExtractor.call(Davis.$(this)));
      Davis.location.assign(request)
      event.stopPropagation();
      event.preventDefault();
      return false;
    };
  };

Davis should now work.

That was the easy part of the migration. Far more annoying was migrating from jquery’s ajax api to reqwest’s.

Next, jquery plugins. Rewrite them. They were not invented by you, so they’re probably awful. Okay, that’s a little unrealistic for some things. If you’re using Bootstrap and its plugins, the ender rewrite will be handy. Note that I couldn’t make its meta-package work. I had to build a library with individual plugins one at a time using ender add.

The other thing I did was rewrite ICanHaz to use the faster mote.js instead of the default mustache javascript implementation, as well as to be agnostic about jquery, zepto, and ender. This isn’t enough code to deserve a github repo, so have it in a gist.

6javascript, programming, project,

I released a simple node.js tool on npm earlier today. I was surprisingly nervous about it. I’ve been shipping software for a long time now, but always in the context of organizations that agree yes, it’s done, yes, it’s tested, yes, it’s worth using by other people. In this case I knew it was working well enough (it’s been quietly chugging inside my big project for a while now), but I wasn’t sure it was significant enough. Who the heck cares? Then I asked myself why I’d written it. Answer: because I went on npm looking for something suitable and found either things that were too complicated (solving a different problem) or simple enough but with notable bugs. Or even worse: with zero documentation. So what the hell. If one person can run off with my code and find it useful, that’s enough.

My beanstalkd client is probably more notable & useful for more people, but I’m not sure I’m happy with the job worker design yet. Must fiddle some more.

Actually, no. I’m going to go finish this user-facing feature instead. FOCUS.

6programming,

Scratch that previous stack. Ember.js turned out to be heavyweight and confusing. At the moment I’m doing a spike implementation with spine.js and it’s looking far more like a winner despite the CoffeeScript.

In my free time I’m hunting around for deployment tools. Don’t have to solve that problem just yet, however.

6programming,