ChartIQ Blog

Posted on by Terry Thorsen

The Bridge to HTML5: Going "All In" with Containers

Using Containers for your HTML5 Build.

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.



Subscribe to future blog notifications

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.




Stay tuned for our next blog post "The Extra Mile." Here I will end The Bridge to HTML5 blog series by talking about polishing up applications before launch. HTML5 containers make work easier, but they do not make things better automatically. Developers will need to rethink design and technique so they don't end up creating a browser window with little to no functionality. 

Read next post "The Extra Mile."

Read previous post "Why HTML5?"

Subscribe to future blog notifications