Categories

Meta

work

Ok. So, new plan. Eliza happened, and work happened, and as it turns out the app I had planned doesn’t really cut it for the comparison. However, I’ve got something even better: real-world comparisons.

See, I made Chesapeake Bay Field Guide using AngularJS, and I’m working on the upcoming ChesapeakeProgress.net site using Backbone and ReactJS. The latter is taking up quite a bit of my time. However, I’m learning some interesting things about working with Backbone vs working with Angular that tell me what I need to know about Backbone and Angular. I’m using ReactJS (Facebook’s javascript library centered around UI) for a dynamic navigation menu, and I’m using Backbone along with the incredible ChartJS to create dynamic charts from an ExpressionEngine endpoint that serves JSON. So far, I’ve been able to draw some conclusions.

tl;dr: Backbone is awesome.

The nice thing about working with Backbone is that it does so much data organization automatically. Without forcing you to into a particular design paradigm, Backbone makes it very easy to set up a data model and wire up views in a pub-sub structure. It lacks Angular’s boilerplate, but I’m finding that I don’t really miss that too much. I suspect that if I were working on a true RESTful app I would be even more impressed. It makes coding to the data architecture you’ve got so, so easy, and in an environment where I have limited control over what users on the back end are doing, that’s invaluable. I love that Backbone offers me tools to use without getting in my way.

Now, where Angular has Backbone beat cold is in UI development. Angular’s native UI stuff is fantastic, and in a more comprehensive app I might be inclined to lean towards Angular. But for building an app (or a widget maybe?) to fit into an existing site, Backbone is working out perfectly. I wouldn’t go so far as to say that Angular would be unsuitable, but I would definitely start any similar projects using Backbone in the future.

Having said that, I came across Backand.com, a service that essentially creates a back end for your web app (intended for Angular, but probably useable for anything) using a simple web-based UI coupled with stellar support, and I’m going to be building an Angular app to track my homebrewing using that service. While I love Backbone, Angular offers so much native functionality and good, solid software design guide rails that I really believe it’s the best option for a new single-page app.

Ember’s gonna have to wait.

So, I think that means that the Battle Royale is over, with no clear winner. And it’s the ref’s fault.

Two postscripts.

First, I will never not use RequireJS in a project ever, ever again. It’s just so damn useful. Once you get the hang of it–and there is a little bit of a curve if you haven’t used it–you’ll never want to not use it. It makes modular development so easy.

Second, ReactJS. I was dead set against it when I first started reading about it, because I just didn’t see a need for it. To some extent, I still don’t. What I will say about React is that it makes organizing your view code much easier. It’s somewhere between Angular and Backbone as to constraining your design, but I’ve found that it’s forced me to write much cleaner code. I’m not 100% sold, but I’d probably use it again, especially in conjunction with Backbone.

Finally deployed the site I’ve been working on since May: http://www.baybackpack.com. Not gonna lie, it wasn’t a completely smooth process, but it’s done and I’m pretty proud of it. Zach Friedman is responsible for the design, I’m responsible for the code, and Guy Stephens led the project and kept us out of meetings.

We’re using ExpressionEngine for the CMS, and I’ve got to say I prefer it to WordPress for everything but blogging. Lots of support on the back end for setting up a good, robust data architecture, fairly user-friendly, and uses a very flexible templating engine that fits right into standard HTML. It actually looks a little like EJS or Handlebars. Much nicer to work with than some other CMS’s (cough cough WP cough cough) when you want to have full control over the front end.

Ironically, I also just rebooted this site as a WordPress site. This was largely a result of my wiping out my existing site while working with some automated GitHub deployment strategies. At this point I’m content to just have the site up and presentable while I rebuild the content, but eventually I’d like to use this as an opportunity to do some work with WordPress theme creation.

In the course of the reboot I upgraded from a hosted site to a VPS, and have been fiddling with things like private nameservers and local mail, which has been instructive. Also, nice to have an email address at my own domain for stuff like using Outlook (don’t judge), PGP, and just general nerd cred.