Category Archives: Web Development

3 Browser Based Editors to Watch

In the last couple of weeks, there has been a fair amount of talk about three web based editors. Google has started embeding CodeMirror into Google Project Hosting, IBM is developing Orion, and Mozilla is merging Bespin/SkyWriter into Ace, Cloud9’s editor. Everything from office suites to music players have been migrating online, it seems likely that these editors will be the next category of apps to live in your browser. Will they replace vi, emacs, or TextMate? Probably not any time soon, but they do offer some interesting opportunities, let’s take a look at each of them.


CodeMirror seems to the be one of the oldest browser based editors. If you’re interested in how it’s implemented, there is a great article covering CodeMirror’s creation. The focus so far seems to be around making a decent editor you can embed in existing projects. Of the three editors, it seemed to be the slowest, but also the most versatile, well documented, and mature editor. It is also worth noting that google has been using it for a while in their KML playground, patch submission for Google Project, and the Google API Playground.


Little has been said so far about Orion, and it’s obviously in an early stage, but it sounds like some of the Eclipse team is working on it, which is interesting news. I couldn’t find an online demo, however it’s quite easy to download and run the Orion server. The editor itself is pretty snappy, and already has some unique features such as code annotation. Where as CodeMirror is aimed at embedding in existing pages, Orion is setting out to be a full IDE which handles loading and saving files as well as managing user accounts. The general interface surrounding the editor is quite rudimentary at this point, but what is working so far looks good.

Ace / Cloud9

As I mentioned above, Mozilla’s Bespin/SkyWriter is being merged into Ace, the editor for the Cloud9 IDE . Bespin was a very interesting project, and I think Ace shows some great potential. The editor itself is quite fast, and seems natural to use. There isn’t much information out there concerning the full IDE, so I tried signing up for the hosted beta, but found that you can already download and install Cloud9 the IDE yourself. The Cloud9 IDE let’s you easily serve up any directory and edit it through your browser.  The interface is surprisingly polished, and seems like it could really offer up a good experience in the future.

So where does all this leave us? None of these editors have the additional functionality that we expect in our day to day editors, but the promise of being able to edit files quickly within your browser is interesting.  These editors could decrease some of the barriers to web applications, perhaps becoming as useful as tools like Firebug.  I’m not about to throw out TextMate, but as a web developer, I think these editors will fill a useful niche in the future.


Filed under development, Web Development

The New Client Side

What happens when you separate your client from your business logic?

I was thinking about Martin Fowler’s recent post about the Database Thaw, and was reminded of an article published by by Dave Thomas. He pointed out that we could build our clients independently from our web frameworks if we use RESTful back ends.  Such an approach gives us a number of advantages in scalability, integration, and code separation.

Quite simply, when we work in terms of resources manipulated via HTTP, we introduce a new place where we can cache data easily.  HTTP GETs are (or should be) side effect free, and can be cached, or run through a web proxy.  Frameworks are also including increasing support for caching at the HTTP level, Rails for instance is introducing more support for ETags in its next release.

RESTFul back ends also create an excellent integration point for your applications.  As Martin Fowler pointed out, they are quickly becoming a viable alternative to Integration Databases.  They also make exposing functionality much simpler, and easier to pick up, for example the Twitter REST API follows similar conventions as Harvest’s REST API, and as a result, both are fairly easy to understand.

These are great reasons to look into a RESTful back end, and have been covered a lot.  What I think has been largely ignored is the possibility of increasing code separation between the layers of your application.  Right now, a common stack looks something like this:

  Database Business Logic Front End
Product MySQL, Postgres, SQL Server, etc. Rails, Django, CakePHP, ASP.NET MVC, etc HTML
Language SQL Ruby, Python, C#, etc. Framework’s Custom View Language + HTML + Javascript

Ignoring the fact that I probably left out your favorite language or framework, there’s something weird about this picture.  While we typically have a clean distinction between our database layer and our business logic, the front end typically gets injected with a lot of support code from our framework.  There is usually a template language, and often helpers which generate support JavaScript.

Over the next few posts I am going to explore building completely separated interfaces which are backed by a simple RESTful server.  My premise is that we should be able to build simpler, cleaner interfaces, that play nicely with the web.  I’m planning on creating a backend that is as bare bones as possible, and interfaces with examples using ExtJS, jQuery, SproutCore, and possibly Cappuccino.  If everything goes well, we might just be able to add a Flex and Java client as well, who knows. Let me know if you’d like to see any other frameworks used, or if you would like to contribute one once things get going.


Filed under HTTP, REST, Web Development