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.
Medium and long term risks for ActionScript/Flex applications
Most people agree the decline started with the hatred from Apple and Steve Jobs and the popularity of iPhones, probably accelerated by the wretched announcements made by Adobe in November 2011.
Adobe is not providing statistics for the market penetration of its Flash Player runtime anymore; those pages have been replaced by a generic announcement that generically talks about 1 billion of desktops: http://www.adobe.com/uk/products/flashruntimes/statistics.html?PID=7909158. Considering that the plugin comes bundled with Google Chrome, the penetration might as well be still high, but we know for sure that websites are slowly abandoning the technology:
The Flash player is essentially in maintenance mode, no new features have been pushed for a while. This lethargy should ring an alarm or two, as security holes continue to appear incessantly. The “Hacking Team” scandal uncovered a zero-day vulnerability used to execute arbitrary code on vulnerable machines: http://www.securityweek.com/adobe-patches-hacking-teams-flash-player-zero-day. The track record of the Flash Player is not flattering, this is not the first one and, most probably, not the last. This sparked discussions and controversies on how fast Flash should be killed, even leading Alex Stamos, Facebook’s CSO, to call for an end of life date: http://www.theverge.com/2015/7/13/8948459/adobe-flash-insecure-says-facebook-cso
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.
