Using Containers for your HTML5 Build
Developers 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.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 task bar. They can run across multiple monitors. They can have floating windows and “launch pads”.
Container applications 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.
Our latest application integration product for the desktop, Finsemble, is built on top of a container for this reason. 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) among many other advanced HTML5 features and functionality are being assembled into a library for users.
Best of Both Worlds: Java and .NET
Not every financial 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.
Finsemble on top of a container allows supported libraries to embed Chromium into native applications. Chromium provides a consistent, reliable, and high performance HTML5 container. In short, this takes all the guesswork out of including HTML5 in desktop applications.
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.
Read the next post "The Extra Mile." It is 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 the previous post "Why HTML5?" if you missed it.
See how we are using HTML5 containers to build a new trading terminal called the Open Terminal.