Choosing an HTML5 Web Toolkit for Flex5

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.

For us, we’ve known for quite some time we wanted to leverage HTML5 web technologies for our new platform, so we can write UI’s that can be used across any browser or operating system. HTML5 is just a new HTML standard with some new features in it…. It’s not really a complete toolkit in and of itself, but rather just something toolkits can utilize. HTML5 is just low level DOM elements, but you have to combine it with CSS and JavaScript for it it be an immersive interactive application. So next, let’s try to understand what a HTML5 toolkit is.

What is an HTML5 Web Toolkit?

Good question. There are probably hundreds out there—literally. Some of the more common ones thrown around are Angular, React, Ember, Knockout, Backbone, etc. All of them in some form or the other attempt to help you build a web app. They often take very different approaches, some trying to be JavaScript centric and others HTML centric. Some are opinionated and give you a defined way of development. Others are very minimalistic and leave it up to you to make most of the decisions. All of them in some form or another give you a framework or scaffolding to help you build a web application. Plain vanilla web technologies are very unstructured, so web toolkits/frameworks in one way or another try to give you some structure to make building a web app easier. However, what most of them are NOT is an all-in-one solution. When we started to look for an HTML5 UI toolkit, we wanted something that could come close to matching what we had with Adobe Flex. There are more or less two general categories of toolkits: open source and vendor-based. Let’s look at each of these next.

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.

Vendor-based toolkits

The other option is to use a vendor based HTML5 toolkit. There are several out there, but by far the one with the most traction would be Sencha ExtJS. While it’s not necessarily the cool, hip kid on the block, it’s super functional and powerful. It’s a comprehensive all-in-one toolkit with rich UI components, build system, plumbing, architecture, etc. Very little, if any, outside dependencies need to be brought in. This means everything is designed to work together and everything upgrades on the same path. Sencha provides an excellent IntelliJ plugin (IntelliJ was already our preferred code editor at Flex), so developing in a pure JavaScript ExtJS application is really rich, giving us a lot of the code tooling that we love on the server side with Java & Groovy. When we compared Adobe Flex & Sencha ExtJS, the match was close to 1-1 in terms of UI components and what they were targeted to do. We’ve been using Sencha ExtJS to build out our Flex 5 tablet app, and so far we love it.

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.

The other ExtJS upside (vs Adobe Flex) is that the delivery mechanism is not proprietary like Adobe Flex. ExtJS is written in pure JavaScript, and delivered via a browser like any other web application. In essence, our bet isn’t so much on Sencha, but rather web technologies. Our primary risk is that the web will go out of style. While that could happen, it doesn’t appear like it will anytime soon!

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.

Mobile first

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

As said above, phone & tablet UI’s are being built. However, we still intend to deploy the phone & tablet apps through the app stores. They will still be web apps under the cover, but they will be packaged with a native wrapper. The reason for this is that all the application resources are stored locally on the device creating much less demand on wireless data. It will essentially just be Flex data going back and forth across the web. It will make the app load quicker and perform faster in general. The second big reason is native integration. We are planning to wrap the mobile apps with Cordova which is a cross platform application wrapper that will give us a consistent JavaScript Api to access native device functionality. A relevant example would be camera barcode scanning, but we could also grab geo coordinates for scan records, pop up native dialogs, etc.

In Summary

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!

Leave a Comment