Containers: Building HTML5 Desktop Applications

With the advent of HTML5, it is now possible to build uncompromising business applications in the browser. The introduction of the HTML5 API narrowed the functionality and performance gap between browser and desktop applications by providing: a high speed canvas for data visualization, WebSockets for streaming network communications, a filesystem API, and more. The list of advantages continues to grow: (

Given these advances, the “last mile” for HTML5 is an ability to act as a true desktop application that is indistinguishable from native applications. Chromium Embedded Framework or Chromium is the technology which makes this possible. Chromium makes the inner workings of the Chrome browser available as open source and establishes the basis for a number of projects that allow native applications to embed HTML5 into their UI in a seamless way. Thanks to innovations from a few brilliant companies, this technology has been abstracted so that it can now be easily leveraged, both to build new desktop applications and to extend existing applications with HTML5 functionality.

Why HTML5?

This all sounds great – but only if you’re first convinced that HTML5 offers a unique advantage over traditional programming methods. Native coding (Java, .NET, Objective-C) is alive and well but it is now generally understood that the HTML/CSS paradigm is usually simpler, quicker and more flexible than traditional native approaches. HTML’s heritage as a tool for informational content HTML’s evolution was primarily driven by graphics designers who required flexible layout and complete control over aesthetics in order to build beautiful, mostly print inspired, web pages. The Document Object Model (DOM) and Cascading Style Sheets (CSS) evolved to meet these needs. These technologies were well established by the time browsers gained the ability to present dynamic content. The application of graphic design discipline to dynamic content and interactivity resulted in the web we know today, lush with interfaces that can simultaneously offer power and simplicity.

Aside from the UI design and layout advantages offered by HTML5, JavaScript itself has become today’s dominant programming language. A vast ecosystem of tools, frameworks, cloud services, and sample source code has emerged, putting JavaScript programmers in an enviable position, and one that couldn’t even have been imagined just a few years ago. Development speed has accelerated. Plug-and-play interoperability has transitioned from dream to reality.

The benefits of adopting HTML5 for new functionality, particularly UI, are compelling. The question of how to apply an HTML5 strategy to the desktop, and how to leverage these benefits in the context of legacy desktop applications, has been answered by what’s now known as the “container”.

All In: The HTML5 Desktop

Builders of new applications can consider going “all in” by starting their projects with an HTML5 “container”. A container is a platform that embeds Chromium into a native shell, so that a developer doesn’t need to actually write any C++ to build their native app. The two dominant containers are Electron and NW.js. NW.js has been around a bit longer and has a slightly deeper API but Electron (which was created by GitHub) is quickly becoming the container of choice, spurred on by a large community of contributors and evangelists.

For financial applications, the company OpenFin offers a particularly robust solution. OpenFin provides a container environment that is based on Electron but further abstracted to solve problems specific to the financial industry such as deployment, security and interoperability with legacy applications – the “last mile” is a bit longer for financial desktop applications.

Once inside an HTML5 container, developers can essentially write applications the same way as they do for browsers. They gain access to an additional API that allows window manipulation. Applications built in containers look and feel like native desktop apps. They can interact with the taskbar. They can run across multiple monitors. They can have floating windows and “launch pads”.

Container applications built with OpenFin arrive as an exe installer. Simply double click to install. However, application logic (the HTML5) can still be hosted on the web, so that users gain access to updates without ever needing to re-install or press an “update” button – the same benefits as browser delivered applications.

Here at ChartIQ, we’ve built a desktop application using OpenFin. The display is beautiful and performance is fast. Along the way we’ve developed architecture that addresses some of the common issues related to building desktop based HTML5 applications.  Workspace capability and bus communications (to coordinate and pass information between windows) are being assembled in a library we have dubbed FinSemble. We plan to make this library available in the coming months for use by others who are building complex financial applications in HTML5.

Best Of Both Worlds: Java and .NET

Not every firm has the option, or the desire, to build applications from scratch in HTML5. A legacy application written in Java or .NET might contain millions of lines of trusted, tested code and a significant deploy base that expects a steady, stable upgrade path. Even if the desire does exist to move to HTML5, reality and prudence may stand in the way of embarking on a massive rebuild.

Luckily a middle-ground exists. Today, all native UI frameworks provide what is called a WebView. A WebView is essentially a native UI control that embeds a browser into an application (Swing, .NET, etc). The native code can then interact bi-directionally with the WebView, allowing developers to build new functionality in HTML5 within the context of a legacy application. In the mobile world this is called a “hybrid app” and has become quite common but it is only now starting to catch on in the desktop world.

OpenFin and TeamDev both provide commercially supported libraries to embed Chromium into native applications. OpenFin for Java & .NET, JXBrowser for Java developers, and DotNetBrowser for .NET developers provide the same advantages as Electron or NW.js. They are based off of Chromium which provides a consistent, reliable and high performance HTML5 container. We generally recommend using a commercial product even when a native WebView is available because pure Chromium has a better performance profile and because commercial libraries provide a simple, easy interface. In short, they take all the guesswork out of including HTML5 in desktop applications.

With this hybrid approach, firms can establish a bridge from legacy applications to pure HTML5 container based applications. They gain access to the wide array of JavaScript based software and services that are available. Product managers can *evolve* their solutions towards HTML5 without the risk of undertaking a major replacement project. This is also a great news for Java and .NET development teams as it allows them to dig in and learn HTML5 in a safe, limited context without having to completely re-invent themselves or the way they code overnight.

A unique example of leveraging containers to extend an application can be found in Thomson Reuter’s Eikon product. Eikon is a powerful market data terminal that can be found on thousands of professional desktops. The core application is written in C++ but most UI components are written in HTML5 using the very container strategy we’ve described.

Thomson Reuters has taken things one step further by opening up their container to third parties and providing an API for accessing the application’s internal data. This strategic decision delivers on the promise of HTML5, that applications from disparate sources can be easily combined into a comprehensive and congruous user experience. Without HTML5 containers, such integration would require a degree of coordination and exposure than is almost unthinkable in a financial application.

For firms that use Eikon, it is now possible to write custom applications driven by the market data that they already rely on. Development and deployment in such an environment can be an order of magnitude quicker than a custom build, since problems of authentication, infrastructure, data management, entitlements and deployment have already been solved by the container!


Containers of course are not all wine and roses. Work inside a container exposes new considerations for HTML5 developers and requires some rethinking about design and technique. It is critical to put the extra work in, otherwise your desktop based application will be no more than a browser window that is launched with a double click.

First and foremost, one must consider the user interface. Traditional desktop applications rely on cascading menu systems. Not only are such menus are out of vogue in modern web development but in a multi-windowing application they can be cumbersome (even in a native app). We are seeing many container based applications move to “launcher” or “docked toolbar” paradigms and replacing cascading menus with dialog based navigation.

A second consideration is that “responsive design” takes on more nuance in a multi-window environment. User interfaces that switch to mobile mode when the screen size shrinks look pretty weird on a multi-window screen! Making a distinction between responsiveness for screen resolution vs. responsiveness for mobile devices is critical (not just touch – keep in mind that more and more desktop monitors are touch screens!). Menu bars also need to make space for navigational icons such as maximizer and close.

Working inside a container system also reveals technical complications. Modern JavaScript frameworks such as Angular and React are not designed to operate across process spaces. In an HTML5 container, each window behaves like an iframe or a browser tab, with dedicated DOM and subject to CORS restrictions. In a Java or .NET container, each window is a truly discrete process, separated by a virtual vacuum that is the container process. In both cases, communication between windows must be coordinated and transmitted through the container’s process space. This essentially reveals itself to be a distributed systems problem and we can find solutions to these problems in algorithms from that discipline and by leveraging interoperability buses.

ChartIQ has encountered and worked through many of these issues for our own deployments. We are launching our Technician market data product based on OpenFin. We have integrated our charts into Thomson Reuters’ Eikon terminal. Several of our customers have successfully embedded our charting library into Java and .NET platforms using Teamdev’s solutions. Along the way we’ve built up experience and capabilities that we are compiling into our FinSemble library for HTML5 desktop developers. The combination of a container solution with FinSemble and ChartIQ’s W3C Web Component based Charting Library equips financial firms with the ultimate solution for building desktop applications that their users will love and use for years to come.

Leave a Reply

Your email address will not be published. Required fields are marked *