Sunday, 11 March 2012

Choosing a library / framework

As I may have mentioned, I'm working on a javascript web app at the moment and it's been pretty interesting. We're taking a restful approach to the system and maintaining as much separation between front and backend as possible. One of the first decisions I had to make was whether or not to use a framework to take care of that side of things for me. I really like backbone.js and was struggling to think of a reason not to use it and build something myself. Obviously building something from scratch would help me develop my skills and be a great learning experience, but would it suit the project? Here's my initial thoughts on the subject.

Pros of using backbone.js

It's well written, proven and much better tested than anything I could build in a reasonable space of time. It follows a tried and tested route for developing the type of web apps I was looking for. Working within the clear confines of the library would help to speed up the development of the app. It would also speed up on-boarding of new members of staff faster than having them learn a custom framework first.

Cons of using backbone.js

The framework won't be mine, I won't know it as well as something I'd written myself. I will have to work around the differences between a generic framework and my specific needs. As we are developing the application in an agile manner, it's impossible to know if the framework meets our, as yet, undefined future needs.

Initial Conclusions

Yea, this all pretty much adds up in backbones favour, doesn't it? Using a generic framework would be faster and would help keep my code from becoming a sprawling mass. The smart thing to do would be to immerse oneself in backbone and really get to know it. My only remaining doubt was about the actual needs of the system we were building.

Further thoughts

There was still that nagging doubt in my mind though. How could I learn a new framework and expect it to keep my code neatly organised, when what I needed my code to do kept changing and morphing as we worked on the user journey? I was busy thinking about how I couldn't build something as polished as backbone in a short space of time, when it occurred to me that perhaps I didn't need to. Building a framework that was specific to the apps needs as they grew and developed might actually be faster, as changing my own code is easier than changing directions within a new framework. It also occurred to me that my framework wouldn't need to be as good as backbone - like everything in commercial software, it needed to be adequately good. Especially as I expect the code written in this early "let's get something online as quickly as possible and refine it as we see how people use it" stage to be re-done at some point when the system requirements are more fully understood.

This new idea had other benefits too. By building and developing the framework to the applications growing needs I would have a much better understanding of the system. Later on, when the app was more mature, it would be much easier to put it into a generic framework like backbone.

So far, it's been an amazing experience. I've learnt a truckload and really enjoyed it, the app works well and seems pretty solid. I also feel like closer to the system, it's my code, I know which bits are optimised and which bits aren't. I also know exactly how long it will take to change the areas that need to adapt to user requirements.

I am happy with the decision I made and the results we've had. I know so much more about how the app should work that I would do a much better job of putting it into a framework. I still have plans to do that, but I have more to learn about the system first.

No comments:

Post a Comment