Challenges of staying with Flex
The cost will always be a major concern if you plan to upgrade your software to conform to up-to-date technologies to keep pace with progress. However, staying with a proprietary platform may cost your business far more than the decision to migrate. If you plan to stick with Flex your software will require a Flash browser plug-in to render and display your application. You should also remember that this decision would leave you unable to provide a responsive UI, which means that tablets or mobile devices are out of the game. Moreover, 90% of businesses now support iOS devices such as iPhones or iPads and no longer support Flash.
Our suggestion
A few options exist for Flex migrations. One of these includes using HTML5 along with AngularJS support. Of course, you may have already considered other frameworks or languages along with their particular pros and cons and decided to proceed using one of them. But a comparison of potential competitors is not the goal of this article. The aim here is to share some real-world experiences with successful Flash-based software migrations to HTML/AngularJS that we’ve observed since 2012 and to provide you with some key points to consider.
Why HTML5 is a potential option?
As the online world becomes more and more targeted toward mobile devices, you may find there’s more information to support HTML5’s ability to smoothly integrate into different mobile browsers. In addition, a few billion mobile devices now have full HTML5 support. This is enough of an incentive to consider HTML5 as a target, but also consider the following advantages:
- Freedom from vendor lock-in. Whilst Flash tends to lose support and leaves business soon.
- A number of tests measuring HTML5 under Linux and Mac OS X have confirmed that it runs at least 55% faster.
- HTML5 allows you to easily add video, audio, and canvas elements, as well as enabling you to integrate SVG content. And you no longer need to add multimedia content using plug-ins and APIs.
- Responsive UI. HTML5 was built to support responsiveness across different devices, which considerably decreases the cost of development and the need to maintain desktop and mobile versions of the software separately.
Where is AngularJS in this migration journey?
HTML5 is just a first player in the migration journey, while there should be the second, which supports all UI/UX (HTML) with internal client-side logic. A few years ago, when we were thinking about how to approach the problem, AngularJS rose as a star. A few intensive attempts and tests to validate whether AngularJS was fully capable of providing what we needed showed us that we were on the right track. Of course, now there are other worthy competitors such as Knockout.js, and React.js, and the decision about which platform to choose mostly comes down to working or development preferences. But back in 2012 and even now, we’ve mostly tended to use AngularJS when we’ve considered what to use in addition to HTML5 in large enterprise applications (let us remind you that AngularJS 2x is way different than 1x).
Without delving too deeply into the details of our own preferences, AngularJS brings the following key features to development:
- Focus on mobile apps
- Modularity
- Performance
- MV*-like pattern
As AngularJS has successfully matured, a large community has grown around it, and as a result, it is easier and faster to fix code problems and there have been numerous improvements. All of these factors affect our decisions when we consider client-side platforms.
Apparently, having super modern and effective client-side solutions or frameworks on the market is not enough to easily transform Flex-based software. If the application is small and relatively uncomplicated, it might seem reasonable to simply rewrite it page by page, thus transferring all of the client-side logic from ActionScript into HTML5/AngularJS. This type of migration could occur in a separate development branch for a few weeks or months, releasing the completed solution by the end of the cycle and thereafter quickly transferring users to the new platform.
But what do you do with a relatively large enterprise Flex-based software application that consists of tens and hundreds of separate pages and has complex business logic — especially one that is spread across multiple clients and is used extensively?
Approach for Flex to HTML5/AngularJS Migration
Imagine a large enterprise application that was built in ActionScript many years ago and sold to a variety of valuable clients and customers, one that was in constant development and one for which investments passed the million dollar mark a long time ago. Following the latest trend to leave Flash, that irresistible moment when product owners decide to migrate their product to something supportable and more vital has apparently already come. Let’s now consider at least two directions you could take in this type of scenario:
A. Keeping the Flex-based application live in its final months and years, and dedicating a separate new team to build new HTML-based software from the ground up. The advantage of this approach is that the two development flows don’t cross over too much and each team is working independently. But the thing that diminishes the value of this approach is that all (new) features developed in ActionScript should be replicated in HTML5/AngularJS code in some way, or vice versa. At the end of the day this doubles the efforts, and there’s no escaping it.
B. Develop a hybrid application as a literate mix of old ActionScript-based code together with a new HTML5/AngularJS component. In general, strict rules should be followed during such a development:
- Any new feature (unless there’s a vital necessity of hot fixes in the old code) should be developed in a new framework, but not in the ActionScript;
- Migration to a new code base should not break existing application business flows;
- By the end of the day (release) it should be relatively easy to switch off the old ActionScript code, clean the solution and use only new code base.
From our perspective, the only disadvantage of direction B is that, in order to be able to understand one type of business logic and transform it into another language following the rules listed above, developers who attempt this should be experienced both in ActionScript and HTML5/AngularJS. And there is a clear advantage in maintaining the same team during the straightforward page-by-page or component-by-component migration from Flex to another code base: there is almost no duplication of the development resources.
Another bonus is that this approach allows for continuous deployment of the application via CI (Continuous Integration) to DEV/QA environments, allowing you to test and verify the migration’s intermediate results over the entire development cycle, from day one to release. We believe that this is an extremely valuable benefit that any product customer can obtain. First, it usually allows to prove the concept of this type of migration during the POC (Proof-of-Concept) period limited by several weeks and ensures that small, generalized results can in some manner guarantee the success of the global product migration. Secondly, for really large products and well-planned schedules, it may allow the client to produce several intermediate product releases and deploy them to customers, thus avoiding damage to their businesses.
As a final word on the subject, we should add that Diatom Enterprises had an exceptionally successful experience migrating a large enterprise Flex-based web application to HTML5/AngularJS using the hybrid approach, which allowed a North American client to smoothly and painlessly transition their customers to a new, highly productive modern platform. We have also supported a European client in building the POC for the same type of migration. If you have any questions regarding technical aspects of platform migration, or ideas of potential collaboration, please contact us.