Posts

Migrating from ActionScript/Flex to HTML5/JavaScript

In the past few years we have been working on different rich internet applications, ranging from simple CMS to fully fledged Single Dealer platforms; the one thing most of them had in common was that they were written in ActionScript 3, with the help of Flex. These applications were avid consumers of data services like BlazeDS and GraniteDS, or, in case there was some serious money invested, Live Cycle DS. We have seen the improvements and evolutions from Flex 2 all the way to Flex 4.6, from the golden age of Caingorm 2 to the rise of Parsley. All these libraries and frameworks, together with Adobe Flash Builder ®, made up an unbeatable ecosystem to build rich, powerful and complex internet applications.

If this is not enough to at least make think about a migration, then you should consider another aspect. Who will maintain your application? Who will add that feature your major client is pushing for? Unless your application is stable and working with a shelf life of 1 or 2 years, you are bound to ask yourself those questions. Keeping them in mind, now look at this chart:

Interest in ActionScript and Flex is not going to grow back anytime soon, open sourcing a product doesn’t always help. After a slight interest during the incubating phase of Apache Flex, people started focusing their attention to other technologies; contributions to the now open sourced Flex code base were of questionable quality and traction faded away. Developers and companies are not going to invest their time in dying technologies, resulting in a drain of developers and a shrinking community. The few developers and experts left that are still willing to work with ActionScript and Flex will be more and more expensive. Sooner or later, the maintenance cost will be bigger than the migration one.

Short term risks for a migration to HTML5/JavaScript

Building a skilled team to develop a fully fledged rich internet application using JavaScript and HTML5 is not a task as easy as it might look. It’s true that this HTML5 frenzy brought a lot of developers on the bandwagon, but a lot of them come from a simple scripting background. A lot of Flex developers, on the other hand, were Java or some other OO language developers, that were lured into this front end technology by its robustness, easy of use, and the typed language that ActionScript 3 is.

Once the skill-set is in place, the next hurdle is to pick the best stack of technologies. In the last few years, someone who approached the JavaScript world for the first time would have found a myriad of tools, libraries and frameworks, with no clue about what to pick. On top of that HTML5 was just picking up as a buzzword with few people really understanding its meaning and only few browsers supporting (some of) it. Luckily we are moving from an uncontrollable fragmentation towards a healthy competition between the different tools and frameworks contending the market.

The chart above illustrates the trends of the HTML5 buzzword, which has already peaked and is now stabilising, and the trend of AngularJS (version 2.0 here), which is one of the major frameworks used to build rich and complex web applications with JavaScript (and also other typed languages, but this is not the space to talk about it). As you can see the interest is ramping up, together with an army of skilled developers and a huge collaborating community.

The only downside is that the wind can change and the community around framework A might switch to framework B because is much cooler. While this can still be a risk, frameworks like AngularJS, backed by Google and ReactJS, backed by Facebook, are now widely used, so you will not be left holding the bag.

Shall I migrate?

The answer is depends, but most probably yes. If your application is small and simple, then you should have done this already. The bigger and more complex your product is, the more doubts you understandably have. As I said before though, if you plan to have your product on the market in the next 5 years, you should have already started.

If you have a in house development team, this is a good excuse to start training them; if they already know both technologies that’s even better. You should also consider that such a migration will leave most of the backend logic unchanged. If your product was out sourced or you don’t want to repurpose your team , you can contact us to evaluate the possible alternatives.