Hello, everyone! This is Roger Diller, Technical Lead here at Flex. I’ve been leading the Flex 5 project from a technical perspective. The purpose of this blog post is to provide some insight into how we chose a HTML5 toolkit and some of the philosophy behind the approach we are taking.
The driving force behind all of our plans for quite a while now has been the migration from our Flash-based UI. While there have been quite a few other important problems we’ve been wanting to solve, for the last few years, getting off of Flash has been the driver. However, just knowing we want to move away from Flash doesn’t mean charting a path forward was going to be easy. Once you know you want to move away from Flash, the very next question is “move to what?”. Well, “HTML5”. Yes, but that is a loaded answer, which I will try to explain in this post.
A tribute to Adobe Flex
Adobe Flex has actually solved our UI needs very well. For us, we’ve loved the Adobe Flex UI platform from a functional/practical standpoint. It actually works very well for our UI purposes. It has a browser runtime (the Flash plugin), and you can build rich applications that are CONSISTENT across any browser and any operating system. I can’t over-emphasize the consistency aspect of Adobe Flex. We’ve had almost zero issues where rendering is incorrect due to some browser idiosyncrasy. It has a very rich UI component set built in, along with a build system that gives excellent code validation at compile time. We’ve also sourced a few awesome 3rd party components (e.g. the advanced data grid that filters & exports to various formats on the element list page, inventory manager, and other places). In the end, it is flawed as a long term solution. Flash has fallen out of favor, and will be phased out from all browsers eventually.
What is an HTML5 Web Toolkit?
Open source UI toolkits
There are a multitude of open source toolkits. The most common ones thrown around these days are Angular and React. These two toolkits and similar ones out there do not have an advanced UI widget toolkit built in. They typically do not have a build system or all the front end “plumbing” pieces. Essentially, almost of all of them provide some form of skeletal framework. You have to source all of your UI components [and the advanced ones aren’t free], build system, plumbing, etc. You end up with a matrix of dependencies which all have separate upgrade paths and the pieces aren’t guaranteed to play nice together and can conflict. Even if they don’t conflict, the components may be designed by many different designers and so there can be cohesion gap between components. If you don’t want to source UI components, you have the option to build your own, but that can quickly get expensive when you factor in developer time. For us, open source toolkits just fell short of our needs. We wanted a stable toolkit that could serve us for a long time (without having to rewrite) and we didn’t want to spend time sourcing UI components or building them.
In the end, our bet is on the web
Granted the one downside of Sencha ExtJS is that it’s from a vendor and not free. Since Sencha’s business model is directly tied to the successful forward movement of the toolkit, we feel they are incentivized to keep moving it forward while not dramatically breaking compatibility. While it sounds a little crazy for the internet world, we think of this Flex 5 UI rewrite effort in terms of setting ourselves up for the next 10 years. We don’t want to get through this whole rewrite effort and turn around and do it again right away.
A dramatic compability example in the open source toolkit world would be the Angular 1 and 2 disparity. Angular 2 changed so much from Angular 1 that in a lot of ways you have to rewrite most of it. We’d like to avoid these kinds of compatibility gaps at all costs if we can.
Targeting multiple platforms is at the core of Flex 5
The other big question for a front end rewrite was how to tackle the mobile issue. As most of you probably know, we did write a small native iOS application awhile back. It was written in Apple’s Objective C language and Xcode tooling, and turned out the skillset was super hard. It was kinda a “bubble” application, and nobody on the team had the skills to move it forward. And probably the worse thing is that it that it was iOS only, so our Android users naturally felt left out. With Flex 5, we wanted to make mobile a first class citizen. A LOT has changed since 2009, and mobile has become wildly popular. In a lot of ways, it may supersede the desktop in importance these days. Desktop of course still has huge value for the power users, but on the go access from mobile devices is more important than ever now.
While we want to move off Flash, we still realized it was a very stable platform and was working well. After discussing at length, we decided we would start the Flex 5 effort with a mobile first approach. This is a common practice in the software industry these days when you are starting a new front end or application. The logic is that it’s easier to start with small & simple UI’s and scale that up to full featured desktop applications. It’s much harder to take a desktop application and work that down to smaller screens. It’s also based on the philosophy that users often want mobile often before desktop access for new apps.
We decided to start with a tablet design while keeping in mind how it would translate to phone. We’ve been keeping the desktop design in mind as well. The idea is we want all 3 UI platforms to have continuity yet significant differences to embrace the unique context of each platform.
In the end we are calling our design approach a form of “adaptive” design. That would be in contrast to “responsive” design. After discussing our application needs, it was very apparent a responsive design style where you have a single UI and it just retrofits itself for various screen sizes would not be a good fit for our needs. That approach works great for websites, but for all intents and purposes we are not a website! We are a robust business application that happened to choose web technologies for our UI. We decided to embrace phone, tablet, & desktop as unique design paradigms, but be a single “universal” project that can share all the behind the scenes front end code. This allows for minimal duplication of code and a single skillset across all platforms.
Native app wrappers for mobile
Our plan is to continue to build out our foundations and work on our Flex 5 tablet app. We intend to roll that out in the second half of 2017. We are also making big changes on the back end that will set us up for a much faster and scalable platform for the years to come. I will blog on the back end work in the coming months, but the changes there are as or more important than the UI rewrite! We have just hired two new full stack developers who be joining the team in March. We see our whole Flex 5 development process picking up momentum all through 2017 as we get more foundational code in place and ramp up our new developers! Stay tuned!