I’m knee-deep in Selworthy at the moment, and that’s a good thing.

Much of Selworthy is simple transactional web stuff: users, content objects, and permissions thereon. I spent most of Week 127 focusing on that – writing lots of tests, getting the foundations in place.

But its core is a rich interactive web tool, which manipulating a list of data both through a traditional table and a visual timeline of events. Selworthy’s the sort of project that four or five years ago would have been far beyond me, and pretty beyond the web. In 2015, it’s all achievable in modern browsers with relatively few esoteric libraries. It’s been an exciting learning project, but also eye-opening. (I’m using the Canvas and HTML5 video APIs extensively, for instance).

I’ve also been using a lot of Backbone. I’ve come to Javascript frameworks relatively late, but also relatively carefully; I’ve never really had the need to use one until the past couple of years. I’m keen on making things as simple as possible to begin with, so always start with transactional POST/GET: plain old websites, like you might have made with Perl CGI. And then we layer on the more dynamic layers, usually delivered through Javascript elaboration.

Recently, though, I’ve found myself repeating particular patterns of usage when it comes to binding back-end data to front-end code, and it was on Swarmize that I realized this was exactly what Backbone was for, and perhaps I ought to investigate it. That turned out well, and I found a way of implementing Backbone-based rendering without compromising the proper-pages-with-proper-URLs approach to web design.

So Selworthy isn’t a ‘single-page app’ by any means: it’s lots of pages and lots of HTTP. But there is one page – probably the most important page, the page you spend longest at in the app – which is where all this rich interaction lies, and where Backbone comes into its own. The page is largely rendered server-side in Rails initially, and then Backbone models are populated from inline JSON (rather than HTTP GET) – before the whole Backbone rendering pipeline takes over.

I’m enjoying working with Backbone, mainly because it does almost nothing. The number of places where it has no real opinion about how you proceed is refreshing; as such, I’m free to keep things as simple as I like. Its lack of opinions does have the unfortunate side-effect of making nobody’s Backbone code look the same, but at least you’re not bound to one developer’s understanding of what a rich webapp looks like. (If you ever wonder how little it does, Backbone has some of the best annotated source code of any project I’ve used; you always learn something looking at it).

I’d laid some foundations last week of how Backbone would render the page, and that set the stage for Week 128, in which I build a lot of the rich interactions that bridge Backbone’s data model, with multiple related Backbone views, and also the Rails backend. There was also the first push on look and feel, not just looking at design and layout, but also clarity of communication with the end-user.

That wrapped Milestone 1 and took us well into Milestone 2, which we might well finish before Easter, and a good demo on Friday with the client in their offices helped clarify what the next steps would be. By the end of Milestone 2, we’ll have a really solid demo and be at the point where we need to understand the complex workflows ahead.