Radio Javan’s Technology
Every so often I get an email asking what CMS we use at Radio Javan. Or if we can give them the “scripts” that we use on our site. Well, it shouldn’t be a big secret that RJ is written fully from scratch. There is no magic template that you can simply buy and use to copy our site..!
However, I’m quite happy with the choices we’ve made in the frameworks that RJ is built upon. The entire service backend is, of course, in Ruby/Rails. First time I used it was over a year go when I rebuilt our site, and I haven’t looked back since then. I would ignore most who say Ruby is too slow, and point to sites like Hulu and YellowPages which have built scalable apps using Rails. It’s all about how you architecture and engineer your code.
Up until September, I was using Appcelerator for all the UI front end work. I used to handle all the dynamic parts of the site as well as the service layer for doing Ajax requests. But for many reasons, RJ is now ported to jQuery, a much more stable and lightweight framework.
Appcelerator Stuff
For full disclosure, I used to work at Appcelerator (actually one of the first employees), and these are merely my opinions. In fact, the main reason I decided to use Appcelerator on RJ was to help test and prove the production-readiness of both the client and server framework. RJ was the first (and until recently in September the only) site using Appcelerator on a wide-scale basis. It definitely helped because we have a general population audience with many environments.
But over time, it became apparent that the Appcelerator framework needed a lot of work for production use. It was slow, too intruisive, and it changed quite often. I wanted to use a framework that allows me a good chance of upgrading to the latest version without breaking everything. I want to be somewhat sure that the framework had gone through diligent testing across all browsers (for the basic stuff at least) before pushing out a new release.
One thing about the latest version of Appcelerator that struck me in a negative way was an undocumented feature that includes a tracker that pings a server with the browser’s stat information. Let’s just say I wasn’t too comfortable with that, and unless I didn’t work on the client code, I wouldn’t how to disable it.
The Appcelerator framework started out great. The web expressions are very nice. The biggest challenge though is by having a limited expression language, it becomes difficult when trying to build a complex application. This became evident in many client projects where the use of the web expressions and widgets were promoted over using simple Javascript. But to be honest, I see the limitation of the framework’s language and feature set as a good and natural problem to solve. Unfortunately, soon marketing, name-dropping, and being in the cool crowd started to drive some technology and framework decisions instead of trying to focus on some real nice engineering work. Which to some extent is useful, but in this space where there are literally hundreds of different frameworks out there, you really need a solid product that stands out.
And that brings me to the main point of why I chose to port everything away and use jQuery — because it was easy to do so. There might have been a time where I dreaded writing a lot of Javascript, but I actually enjoy it now. There was nothing real complex about anything I was doing in UI code for RJ anyways, and yet I was able to improve the load times up to 5 times without any intruisive code.
I do see the value in Appcelerator to show that anyone can write a nice, dynamic site, and competition in this emerging space is good. But I know that switching away was a very reasonable and inexpensive decision.
