Harbs, I believe the perfect summary of what you have wrote would be your presentation from ApacheCon [1] :)
[1] https://www.youtube.com/watch?v=-FcLs0O-BWQ Piotr wt., 19 cze 2018 o 18:23 Harbs <harbs.li...@gmail.com> napisał(a): > Yes. You can see a demo of our app here: > https://marketinginflection.com/printui-demo.php < > https://marketinginflection.com/printui-demo.php> > > The business logic ported like a dream. We had to rewrite large portions > of the view, but it was due to a modernization anyway. > > We started our migration close to 2 years ago. It took about 17 months > from when we started the migration until we had clients able to use the > HTML version of the app. > > If we were to do the migration today, it would take a fraction of the > time. A lot of the time went to filling in missing pieces of Royale (i.e. > E4X, Graphics and drawing APIs, porting TLF, filling in and adding > components, etc.) > > I find that we’re about as productive in Royale as we were working in Flex > — possibly more so. > > Prior to doing the Flex migration, we developed an Angular version of our > app which was seriously dumbed down. It took nearly as long to develop as > the Royale application and is nowhere near as capable. The Angular app is > unwieldy to develop and performance is slow. > > We’ve found the following advantages in regard to Flash: > > 1. The compiled minified HTML application is about half the size of the > Flash application. > 2. The app loads between 5 and 10 *times* faster than the Flash > application did. > 3. Debugging in the browser is IMO easier than Flash. > 4. The browser profiling tools are great. > 5. The application is general is much more performant than the Flash one > thanks (I believe) to the improved Royale architecture. > > Some more observations: > 1. The performance of the native Royale components is amazing. Very fast! > 2. It’s very helpful to see where XML performance takes a hit. We were > able to use the profiler to discover where we had unnecessary E4X filtering > and expressions when results could easily be cached. > 3. I was pleased with E4X results in general, but I added a JXON class for > lighter-weight XML processing. > 4. We used a couple of third party components namely > http://rangeslider.js.org/ <http://rangeslider.js.org/> and > http://bgrins.github.io/spectrum/ <http://bgrins.github.io/spectrum/> I > was surprised to discover that these components were by an order of a > magnitude slower than any of the Royale components. They added so much > overhead that the delay was noticeable and I had to implement some > customizations to mitigate the effects of these. > > Issues: > 1. Debugging minified issues is difficult. > 2. I’ve found some difficulty with layout situations that was easier in > Flex. Of course, these problems are no better using other JS frameworks — > probably worse. > > I have other smaller applications developed with Royale as well. I don’t > regret going this path at all! > > HTH, > Harbs > > > On Jun 19, 2018, at 6:57 PM, Alex Harui <aha...@adobe.com.INVALID> > wrote: > > > > Yes. PrintUI is our biggest example. Harbs can share more details. > > > > -Alex > > > > On 6/19/18, 3:24 AM, "chembali" <chemb...@hotmail.com> wrote: > > > > Has anyone ( big scale ) successfully migrated to Apache Royale from > Flex? I > > want to make sure that this migration path is a viable option for me? > Please > > share your thoughts. > > > > Thank you > > Sajith > > > > > > > > -- > > Sent from: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C722806578bc447770e8a08d5d5cecfe0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636650006607089540&sdata=qfDnc3ElRa9Nhwi%2FKAoJdNC67JYFp8UP49hA5Zdjq14%3D&reserved=0 > > > > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
