FacebookTwitterGoogle+

I started working with JavascriptMVC about 7 months ago. I have to admit, at first I was a little skeptical about using a completely front-end system to run the user experience. I was concerned about possible security issues or just general functionality problems that would rear their ugly, yet very familiar, faces. However, I was pleasantly surprised to find out how extremely flexible and accommodating a front-end MVC can be. There have been many growing pains, namely because the framework is still in its formative years. To go along with that, the creators of the JavascriptMVC decided to rename their creation to a more “buzz-wordy” sounds: CanJS.

I started writing that about 11 months ago. I have to say that my attitude hasn’t changed a lot towards front-end MVCs but it has grown and matured. I’ve been using a front-end MVC for a little 1.5 years now and I’ve found a lot of good and a lot of bad that goes with it. When I first started working with CanJS, I dove headfirst. Sad thing is, I didn’t listen to what my dad taught me about that when I was a kid: don’t do it.

Don’t get me wrong, CanJS is a phenomenal setup, bad thing is it tries to be every and anything all at once. Now, my experience is a little dated, mind you. The version of CanJS Β that the system I’ve been working with was from a few months after I started working with CanJS. So, my take on it is a little behind the current version.

At the time that I started writing the above, CanJS was going through some major growing pains. The developer, Bitovi1, was in the middle of remaking the whole shebang. They were remodeling the way that the framework was put together, the way that the supporting inclusion library: steal, and just rethinking the way the whole system should even work. Now, time for a shameless plug here and a little candid disclosure, I had a small hand in some of the rethinking. Very small, mind you. I was a part of the CanJS community for about 6 months and was even approached by the good fellas at Bitovi to join their development team. Sadly, that didn’t work out for either of us. Ok, end shameless ego boost.

I do still believe that front-end MVCs and full-fledged applications are the way of the future, it’s the major trend and has been for the past couple years. You have major applications like Twitter, Facebook, any Google tool/app, you name it, someone’s doing it. The plain truth of it is that everything is becoming decentralized and more spread-out into the … shiver … “cloud”. Yes, I said it. I used a “buzzword”. In all honesty, I hate using buzzwords, they send a cold chill down my spine. Listen to any recruiter, manager or product owner for an hour or two pitching you their idea or product and you’ll understand why.

Sadly, my torch for CanJS has dwindled so a smoldering heap of ash. Again, I’m not saying that it’s a bad product, far from it, I still a lot of promise there for the framework and give the guys at Bitovi and in the CanJS community my support and hopes for the future. For me however, less is more.

When front-end MVCs were really first coming onto the market and gaining attention, there was one that stood out: Backbone.js2. At first, it was clunky and didn’t work well, but that’s to be expected. Now, it’s a completely different story. The simplicity and lack of over-architecture makes it a much easier framework to develop with and build complex applications. When I first came back to Backbone, it took a little getting used to, admittedly. I had become accustomed to the bells and whistles that CanJS had given me. “Where’s the routing?!”, I angrily asked, at first. “Where the hell is the view compiler?!”, I complained. Well, took me a little bit (very little, mind you). “RTFM!”, I replied to myself after a little thinking. So I did. And, lo and behold, I saw the light.

I was really amazed at how quickly I was able to put together a fairly complex system without any real loss of performance from what I had seen with a more encumbered setup with CanJS. I was able to setup my routing, controllers, views, event listeners, et al, without much fuss. What seemed even more amazing was the seamless integration with my new favorite back-end MVC, Symfony2, but we’ll that to another post.

I will admit that there are a lot of nice things that come with CanJS that make some parts of the process a whole lot simpler and easier to manage. Sadly, a lot of those same nice things make a large portion of the rest of the process much more cumbersome and difficult. One main issue that I’ve run into with CanJS is the teardown of controllers. This was an issue that I had to come to grips with, and write workarounds for, a long time ago. Now, that’s not to say that the issues that I’ve come across haven’t been addressed or even fixed in the more recent releases. Sadly, I can’t really use them as, with anyone that has built a complex enterprise system knows, once you choose your tech, you’re stuck with it until there is enough time to plan for a major upgrade and/or overhaul.

So, in the end it all comes down to personal taste, honestly. Some developers will like the cool additions and sleek trickery of CanJS. While others, like myself, will gravitate more towards something that allows them to determine how and when things are processed. So I say to those that are about to dabble in the new age of front-end applications or to those that have been at the bold new frontier, choose carefully, you never know what’s gonna come back to bite you.

 

[1] Bitovi, http://www.bitovi.com/
[2] Backbonejs, http://backbonejs.org/