Why we’re not using Knockoutjs

12. September 2013 Uncategorized 0

This past week I’ve been working on a semi-new project. It’s something I’ve worked on before. In fact, the project itself is the first thing I ever did in MVC. I never completed that version, and instead, a few years later started used it to learn Bootstrap and MongoDB. But I didn’t finish that version either. It’s a bit of a large project and I didn’t have the time to do it in my spare time.  So I pitched it as a company project a month or two ago and we decided to take it on.

It’s nothing super spectacular, but it will involve entering some data in one of several possible categories.Think of an inventory system, you might have trucks, cars, motorcycles, buses, etc. They’re all automobiles,  but each have different sets of specs, even if they do have some commonality.

Last week I started working on the main page and I saw the chance to use a client side library. I’d played with Backbone before and Angular, and thought I might use this opportunity to work on some Knockout. I got the first page up and running relatively quick. As you stepped through various customers, their inventory updated on the screen near instantaneously. It was a bit more work that just creating a Razor view, but I felt like it worked nicer and it was faster,so I ran with it.

Today I got most of what I wanted wrapped up, and so I moved on from the overall summary page to a detail page. And that seemed to work easily enough, and then I clicked the back button to get back to the summary page and try a different item, and that’s when it dawned on me. All of the work I had been doing was on a single page and view model. I didn’t track state at all, so clicking back just took me to an empty page. I realized that wasn’t going to work for our case.

I went over to the knockout page and started going through their Single Page Application (SPA) tutorial and it all made sense. I downloaded sammy.js to handle my page hashes and I started looking at getting all that wired up.

At that time I took a step back and realized that this might not be the best technology for us to use. I had a quick talk with another of our developers and we agreed that we should probably switch back to using normal server-rendered pages.

To make a long story short, the reasons actually had nothing to do with Knockout. There was not a technological reason to abandon it, by that I mean we didn’t find something that Knockout couldn’t handle. Instead, what we realized was that to do an SPA correctly, there is a fair amount of architecture involved. Planning out your templates and views. That’s true on server side as well, but we’re already used to doing it on the server side, it’s a bit more “second nature for us.”

The next reason was that we need to get this up and running somewhat quickly. It’s not super time sensitive, but the quicker we can get a working version up, the quicker we can get it before potential users to get their feedback. It’s quicker for us to do that with server side rendering.

The third reason for abandoning it, is that while Knockout isn’t really complex, it is complex enough for us as a team (since I’m the only one to use it at all, and even then was a super simple proof of concept.) So while I’m the only working on this right now, it very well could be that next week or in 2 months one of the other developers would come over to help out. If that happens it would probably take some time to get other people up to speed. We plan on doing this through code reviews over the next couple weeks, but this didn’t seem like the project for people to learn on.

Again, there’s not really anything wrong with Knockout, and this project doesn’t seem too complex that Knockout (or Angular or anything else) couldn’t work. But it doesn’t seem like the best project to initiate our quest into client side libraries.

I’m a bit disappointed, I really wanted to explore this technology. But sometimes being a professional developer means recognizing that you’ve started down the wrong path, and backing out before you’re in too deep.

So tomorrow & Friday I’ll be ripping out the code I spent the last 2+ days doing. It might seem like a waste of 3-4 days, but there are lessons that have been learned, and I think it will save us time in the long run.