The Fight has been revived!

So I’m just going to pretend I was on a “sabbatical” for about a year.

I found blogging difficult because with only so much time in the day, I wanted to spend it actually working on something instead of just writing about it. My other big problem was that I actually wanted to supply blog posts with substance, and not just regurgitate other crap. I did that for a couple posts and it just felt dirty. Then I had some posts about the whole Spindle language thing, which honestly was not quite on topic either.

Eventually I just gave up and stopped caring. When it came time to renew the domain and hosting service, I felt stupid paying the money. Looking back, I only actually wrote 10 posts!


Basically, two things happened. The first was that I had done enough thinking and learning and soul searching with Spindle that I needed an outlet and feedback, and that of course means the internet.

The other thing that happened was that I saw this posting by Dion Almaer of ajaxian fame. I wanted that job. Like, I realy wanted that job. But I would never leave the job I have now. However, it did get me thinking about my hireability. Sure I’m doing something right now that shows off some pretty good programming chops, but what do I have to show for it. The framework I built isn’t open source, and the project I’m developing isn’t finished. The fact is, I have never really worked on a project that I would really consider finished or successful. Sure a couple minor projects here and there, but I mean, there’s nothing I could point Dion to and say, look at that! I did that!

I started making a list of things I thought would help me feel confident in applying for this job. (Again, not actually doing it, but what would make me confident if I were going to.) Among that list of things was some kind of a web presence. I realized that now that I took down, I didn’t even have a site to point to. Being a web developer, that seemed really bad.

Once more, with feeling

So for take two, I’m trying to learn from my mistakes.

  1. Don’t spend money – Until I can be sure I’m on a roll with this, I don’t want to spend any money, that way I won’t end it for fiscal reasons.
  2. Keep it focused – I have a lot to say, but I felt that RE:The Fight was not the right place for most of those thoughts. So I started another blog to keep each one focused on its specific purpose. That one is Spindle Journal as seen on the left.
  3. Just write – I don’t want to just dump crap here, but I’d like to think that if I lower my standards a little, I’ll write more, and then I’ll naturally get better at writing more quality posts faster.

Stay tuned for more on the fight. There has been a lot brewing, and I’ve got a lot to say!


So I looked at Mashups, and I looked at my own personal gripes about application development on the web, and I started trying to find a solution. I began at the language level, because that is the level at which I work (as a programmer), and also the level at which I think.

The problem space of creating a nice application development platform is one with a lot of answers. The problem of securely distributed computing with untrusted sources less so. So that’s the part I’m approaching first.

Erlang, Gears, Isolation

Mashups are happening on the web now (not securely) and Gears is an attempt to fix, but let’s be realistic. We cannot keep putting band-aids on this. (Well. We can. I just hope we don’t.) Without straying too far from what has made it successful on the web, what else is out there to see what works?

Erlang comes to mind. (I know I’ve said this stuff before in previous posts, but I thought it would be good to refresh). The message passing model works well for concurrency, but also for security. Both are going to be important for us. There is no way to avoid concurrency in a system built for network communications. The internet is one fat concurrency issue. The single threaded JavaScript model doesn’t work, and asynchronous callbacks are clumsy. Additionally, isolating processes with no shared state and a message passing model is a great way to keep untrusted sources from wreaking havoc.  The smart people at Google recognized this and created Gears workers. The question you may be asking is, “Well if Gears does this, why do we need a whole new language?” I’ll tell you. JavaScript was never built to use a message passing model. Using strings to pass messages around sucks. The lack of message pattern matching is a pain. It still doesn’t solve the major problem of accessing the dom. And asynchronous callbacks are still clumsy.

So let’s say we put Erlang in the browser. Would that actually work? Doubtful. Erlang unmodified has plenty of it’s own problems, or rather, it has some design choices that would not work well for the browser. For one thing, it’s strict immutability and almost purely functional syntax would not fly in the general public. For another, it just has no concept of a sandbox. It’s all or nothing.

The Sandbox

Many languages have implementations that operate in a sandbox. Java prides itself on sandboxing. It has those marvelous confirmation dialogs. JavaScript is also sandboxed. In both of these cases the sandboxing is really only protecting the user and the system from the program. What both of them lack is a way of protecting one part of the program from another part of the program.

The first concept when conceiving of Spindle was that it must have the fundamental concept of a sandbox. A barrier protecting one part of an application from another. A sandbox is more than a process. A sandbox is basically defined as the place where code lives. No code is shared between sandboxes. A function in one sandbox is not available in the other unless it is explicitly loaded in that one as well. It goes without saying that they do not share state. A sandbox can spawn one or more lightweight processes to actually execute code. These processes share a code base. This way code does not have to be loaded in duplicate into each process. The only communication between sandboxes is through messaging. In this way, it is the same as between processes.

Breaking up data from behavior

So I was thinking about this message thing. I thought about my own experience passing json between client and server. Luckily for my team, we built a system from automatically marshalling and unmarshalling so we never dealt with the raw json. It seemed to me that if messages were basically json objects, that should be built in for free.

So I thought that it might be a good idea to clearly divide the data from the behavior. An object has certain “properties”. When turned into message format, these properties become the data structure a la json. When accepting a message object, it should be just as easy to flip it back.

Imagine you send a Person object from one sandbox to another.  Or even from server to client. Using json notation, lets say it just looks like:

 {"firstName":"Russell", "lastName":"Leggett"}

But you actually have a Person class (or prototype) with some functions. Instead of having to create a new Person object and transfer the data, it would be nice to be able to ‘imbue’ the object with Person functionality. Like so:
personVar <- Person

Now this might seem like something as simple as copying functions over like many utilities do, but there’s more to it. It would be more like swapping out the prototype on the fly.

This thought process brought me around to the idea that the specification for functions should stay away from properties. This breaks the fundamental concept of prototypes, but hey, I’m not trying to build JS2.

Those were my main initial thoughts going into Spindle. There are a lot more ideas I’ve come up with since that starting point, and I’ll get to those next.