Last spring, we published an interview with our CTO, Pavel Borel. There, we discussed the upcoming cessation of Flex support and the forced migration of projects to other technologies.
The thing is that at the end of July 2017, Adobe representatives in the company’s official blog announced that by 2020 Flex support will be stopped completely, as many browsers have begun to abandon it due to security issues. 2020 is just around the corner, so we decided to meet with Pavel again and talk in more detail about the migration process itself, and, in particular, how the IntexSoft team handles such projects.
The number of requests has increased significantly, by around 4 times. Clients are now more aware of the inevitability of switching to HTML5 or JS. And even those who had some doubts last year, understand that the Flash direction is a deadlock and that migration to other technologies is in store – for the majority that means HTML5.
During migration from Flex to Angular, we usually try to keep the backend and develop a new frontend only, which allows us to optimize costs and save precious time.
We begin with the definition of requirements for a new UI. There may be some options: the new UI should be almost the same as the old one, perhaps with minimal changes in design, but the functionality is usually 90% preserved. Another option is also possible – when new technologies appear, the client may want to make significant changes to the UI and UX up to the point that some of the functions should work differently, and new ones need to be added. This is a more complex option, in such cases, changes to the server will need to be made.
The idea is that migrating from Flash to Angular, in any case, involves rewriting the UI. The reuse of old code or automatic generation does not occur. Some aspects of the logic sometimes can be adopted: design, assets, graphics, but in general, the application is developed from scratch.
We have used anything out of the ordinary. Based on personal experience, I can say that it is better to develop it from scratch so that later you get a solid application that can be supported and improved.
In the case of migration from Flex to Angular, after its second version, Angular started using Typescript. This language itself is very similar to ActionScript (EcmaScript), which is used in Flash/Flex, so the code has to be adapted rather than completely rewritten – the syntax is very similar. There is a slight difference as ActionScript works in its plugin, and TypeScript is translated into JS. But this is just a little difference.
.
.
Automation is difficult to apply, in applications written in ActionScript there are libraries that have no analogs for TypeScript. And also, we should consider that some features of the Angular framework – the visualization is similar, for example, when compared with ActionScript, MXML markups are also used. The structure itself is similar, but there are differences.
If we consider a rich frontend application, then the business logic can be automated partially. It may be possible to find some tools for utility classes. However, we shouldn’t leave these classes without review, in an attempt to save time. Often, core classes at the frontend of business logic require dependency injection. Very often in ActionScript, the Parsley library is used, which allows you to dispatch events and inject some classes. Angular has its own injection, but it does not work like Parsley. It does not allow you to do a cyclic injection. So we had to write our dependency injection and message dispatcher.
In general, it all depends on which application you are migrating and which libraries are used in it.
I’d also say that TypeScript is the most suitable option to use for the convenience of further support and migration speed. If you migrate to another framework that uses JS, not Angular, then this will take a little longer. TypeScript is very important, and therefore Angular is the best suited for language structure and similarity. We didn’t even need to look for any automation tools.
In any case, everything will have to be reviewed, even if the code is reviewed with a tool, you’ll have to look through each line and the difference in speed will be insignificant. Because when you rewrite, you also copy the ActionScript class with TypeScript and then check through the lines and change them a bit, and look for pieces of the code that require intervention and will have to be rewritten due to the difference in languages. Meaning to review is needed to ensure everything is correct.
Our team successfully copes with current tasks: we have a lot of specialists who are experienced in both Flash / Flex development and HTML5. So, our specialists can not only develop a new UI but also analyze the UI written in Flash and, using reverse engineering, figure out how it worked before. This saves the client’s time because they don’t need to describe how it used to work. Our business analysts and developers can uncover it for themselves.
Products that are not worth migrating include, perhaps, some complex products that won’t be updated anymore and are used by a limited number of users. Then at the appropriate workplaces, you’ll have to use outdated versions of browsers that support Flash.
In my opinion, it’s only possible in case of internal use, where the consumers of the product are employees of a company. If the product is focused on public use, then migration from flex to Angular or HTML5 is absolutely necessary and has to be done as soon as possible.
If software, designed on Flash, is installed somewhere at the enterprise and its further updating is not planned, then, of course, you can leave it as it is: it will still work for some time. Now in governmental institutions, you can find software written in Delphi, and it works, yet the problem is that now no one can develop and update such software. So, eventually, it will simply “die”, and needed to be replaced with something else.
If you want to know more information on the topic of migration from Flex, check the first part of this article. Also, if you need any assistance with project migration don’t hesitate to contact us.
It is not a secret that a good e-commerce platform should be convenient for all users. It should be convenient for buyers for them to want to buy and for sellers so that they could work efficiently.
Some people believe investment of money, effort and time in CMS solutions means their website will be eternal and perfect. All they need is to fill in content and download updates.
If you work in a medium or a big company with a long history, there is a high probability that now you are dealing with some outdated legacy system. Many business owners suppose that it is okay to work with such systems as they still do their job.