Battle Royale, September Update!

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 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, 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.

Automated deployment with git is awesome like a hotdog AND like the universe…

Incorporating version control into your deployment process (assuming you have one…), like regular exercise, balancing your checking account, and eating more green vegetables, is something you know you really ought to do but never quite get around to doing. In part because we’re going through a minor overhaul of our processes at work and in part because I’m interested in working with git and automation, I’ve started banging around with GitHub, webhooks, and various third-party deployment services.

I’ll say that I’ve learned more about Linux file permissions than I’ve ever wanted to know, and I’m growing disturbingly comfortable with vi. That’s not a bad thing, per se, but I’d like whatever process I finally land on to be as simple as possible, and, most importantly, to be portable. I’ve been doing some interesting things with server-side scripts, and while I’m fairly pleased with the outcome so far I’m not very confident that what I’ve come up with would translate to, for instance, a brand spankin’ new server without a fair bit of configuration. It’s definitely nowhere near a plug-and-play setup.

I’ve seen some success with third-party alternatives. FTPloy in particular has been relatively simple to set up and works pretty well. The big downside, such as it is, is that you’re basically just asking another website to grab the files from GitHub and FTP them to your site. The initial deployment is, as you’d imagine, fairly lengthy, but subsequent updates are fast. You gain the benefits of version control and it’s very portable, but you lose the speed of a git pull/checkout.

Spending so much time screwing around with logistics instead of working on the site itself is frustrating, but I’m banking on this paying off in the long run.

New Sites!

Finally deployed the site I’ve been working on since May: 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.