The ins and outs of a good HTML5 client

HTML5 clients can vary significantly from one to another based on how they deliver graphics as well as browser performance and plug-ins.

HTML5 clients have been part of the remote desktop conversation for a few years now, but not all clients are the

same.

Early on, there were third-party vendors such as Spark View and Ericom AccessNow. Over time, the bigger vendors like VMware and Citrix have gotten on board with their own HTML5 clients. Each client is quite different, and their performance can vary because of how they deliver graphics, as well as browser performance and plug-ins.

How clients deliver graphics

Getting remote desktop information to the browser is much different than accessing a remote desktop in the traditional way. In the past, companies such as Citrix and Microsoft have had JavaScript clients that can run in the browser, but the actual network protocol in use was still ICA or Remote Desktop Protocol (RDP). To be a true HTML5 client, even the transmission must be something that browsers understand. Enter WebSockets.

WebSockets is a protocol that runs on top of TCP and enables bidirectional communication between the browser and the remote server. This is critical for remote desktops because they need to send keystrokes and mouse clicks and simultaneously receive the actual desktop video. Early iterations of WebSockets only used text, which made HTML5 remote desktop clients convert traditional remote desktop protocols to text before sending them to the client. As you can imagine, this reduced the fidelity and feature set of the experience.

Later versions of WebSockets support binary data, which is the format that data really wants to be in. Some HTML5 clients simply wrap RDP in WebSockets and render the desktop inside the browser using a JavaScript client. This is effective, but not very efficient, so some clients add optimizations into the mix. For example, HTML5 clients such as Ericom's AccessNow get remote desktop data via a gateway that "reads" the RDP information before optimizing it and passing it along. Other clients, such as VMware's Blast actually pull the HTML5 remote desktop protocol information directly out of the video card driver itself.

Browser performance

One of the major influences on what HTML5 can do has been browser capabilities. Browsers are more OS-like today, with features that resemble iOS and Android or even Windows and OS X. There are also actual browser OSes, such as ChromeOS and its open-source counterpart Chromium. As is the case with any other operating system, the software and tools that run on it can take advantage of new and added features.

Aside from the addition of WebSockets, there have been other improvements to browsers. The biggest enhancement from an end-user perspective -- that is, a change that would be most noticeable to the users rather than the coders -- is probably GPU acceleration.

GPU-accelerated browsers have created a noticeably better user experience for some HTML5 clients to take advantage of. Depending on the protocol and how it sends desktop images to the client, GPU-accelerated browsers can drastically speed up video performance. For instance, if the images being sent to the client are encoded as JPEG, browsers can accelerate image processing in the GPU. This is markedly faster than using the CPU. After all, the CPU is busy doing other things, such as decoding the rest of the desktop experience.

That creates an interesting challenge for those clients that don't use a GPU-accelerated format. For example, running plain-old RDP through WebSockets could mean the image format coming across the wire is RLE, an antiquated image compression format that browsers don't support. That means the client JavaScript has to render it, rather than the GPU-accelerated browser.

Additionally, browsers have made it easier to enable printing (built-in PDF viewers), file transfers (drag and drop into the browser window) and even clipboard mapping. None of these is better than a native client experience, but in the early days of HTML5 clients, these features simply didn't exist. In fact, with Ericom AccessNow, you can even use voice commands in Chrome to control the desktop.

Browser plug-ins

A true HTML5 client requires no additional plug-ins on the client side, which means that users can access their desktop from any device with an HTML5-compliant browser. When you start to add in plug-ins or browser applications, things start to get a little dicey.

For instance, a Chrome App that uses Chromoting, or Chrome Remote Desktop, requires specific access to the local resources Chrome gives to Chrome app store apps. In this case, that access comes through NaCL, an isolated application environment for Chrome apps. Running an app in NaCL gives the developer more access to local device features but makes the app more like a native application and less agnostic. In fact, browser-based remote desktop clients that run in NaCL have so much access that they can use whatever protocol they want to remote the desktops -- from traditional protocols to text-based to motion JPEGs -- each with a different user experience.

The biggest challenge with browser plug-ins -- and all browsers have them -- is that they can depend on the device. Some apps in NaCL work on laptops or desktops but not on iOS. Basically, if the HTML5 client you're looking at requires a browser plug-in, you're probably not getting a true HTML5 client.

The key takeaway is that no two Web browser remote desktop clients are the same, and accessing a desktop through a browser doesn't equate to using HTML5. If there is a plug-in involved, odds are it's not HTML5, or it has added features above and beyond HTML5.

With so many clients, possible experiences and time since the "early days" of HTML5, it's highly likely that you could try just one client and get a bad taste in your mouth despite the availability of other excellent tools. If you have unmanaged endpoints or mobile devices with no client software, it's worth taking a look at all the HTML5 clients available. Even if you've done it before, so much has changed in the last few years that you just might get the experience you're looking for today.

This was first published in March 2014

Dig deeper on Virtual desktop infrastructure and architecture

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchEnterpriseDesktop

SearchServerVirtualization

SearchCloudComputing

SearchConsumerization

SearchVMware

Close