HTML and OTT. Can Browsers Handle the Demands of Streaming?
In our conversations with customers, especially those who are working with existing set-top boxes, we often encounter HTML as a possible single codebase alternative when building OTT apps. Web-based apps run on free, open-source technology. They run on languages understood by every developer. As long as a device supports a browser, content can be surfaced.
Standardizing a suite of apps on a browser engine makes sense to a degree. The complications begin to mount once we apply it to a use case, like TV and Media. The demands of modern streaming applications are unique to the industry. What may work elsewhere is not a guarantee when dealing with the sheer software, hardware, and custom feature requirements of TV and Media. A few things to consider:
Reach is by far one of the most important aspects of a direct-to-consumer (D2C) app strategy. Being able to reach more platforms gives access to an entire slate of new subscribers. A healthy base of active subscribers is the lifeblood of any good OTT service. HTML is table stakes for desktop and mobile, but what of the rest of the device ecosystem? Specifically TV-connected devices. Two of the largest streaming device providers, Apple TV and Roku are not compatible with web technologies. Roku in particular runs on a niche language (BrightScript) that will require specialized developers. If these target platforms are required for your cross-platform strategy, then immediately the promise of a single codebase is moot.
Combine that with unique APIs such as specialty remotes, playback formats, DRM, and more, it becomes harder to maintain the ubiquity of web. Platform inconsistencies are expected in any cross-platform project but the degree to which differs depending on the technology approach. With HTML, developers will have to implement many manual abstractions or supplement native code where necessary.
A good user experience goes a long way. Investing in ways to improve navigation, discovery, and playback will keep your subscribers coming back, ensuring long-term success. HTML can create great experiences on mobile and desktop. The outlier, once again, are the TV platforms. Working within this form factor requires a shift in thinking as what works on a desktop does not translate well onto TV. TV screens require distance from the user and device. Having a front-end web developer work within the UX parameters for a phone or laptop will create problems when applied to a screen with specific display densities, safe zones, and unique information architecture. There is a steep learning curve that cannot be understated.
It’s important to note that TV devices vary in performance capabilities. Building for TV platforms requires the ability to degrade and enhance UI performance as needed.
Dealing with all these disparate platforms puts a strain on your production teams. Front-end web developers will be out of their depth when dealing with specific platform nuances. Abstraction can only go so far. They’re also not dealing with a standard server approach to deployment. Device builds require specific packages and testing on the actual hardware. Even working with a web emulator will require knowledge of different platform SDKs. UX designers won’t be too thrilled by the design constraints brought on by web. Unless your HTML build can render directly against the device GPUs, you’re banking on the CPU to do most of the work which tends to benefit basic app structures. This impacts the overall brand experience users will have with the product.
This is not to say web isn’t an option. There are benefits. It all depends on the size and complexity of the app strategy. Smaller, niche services would have better luck with an HTML-based approach, as the scale of the project is smaller than that of the large media enterprises. Your aspirations for platform reach, brand exposure, and unique app features (ads, commerce, etc.) will determine how viable browser technology is to sustain a full suite of apps.
My colleague, Erik has put together a substantive list of considerations as it relates to web technologies and OTT. His technical breakdown explores much of what I haven’t covered in this piece, including performance, NPM ecosystems, APIs, and plenty more. Please find the link, here or below.