JRB - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Pitfalls of HTML5 clients

Using an HTML5 client to access a virtual desktop isn't for everyone. Workers who need high-resolution graphics or use Web apps that require local access could experience decreased performance.

Accessing a virtual desktop via an HTML5 client works, but it's not necessarily a technique all employees should use.

The user experience of an HTML5 client is acceptable in many cases, but it isn't a replacement for a client. And despite improvements to the way HTML5 can remote desktops, even newer protocols, such as VMware's Blast, for example, aren't better than PC over IP.

Although most users won't notice a big difference in performance between HTML5 access and a regular client connection, any worker with graphics or video requirements will. The ability to deliver high-quality graphics via HTML5 exists in GPU-accelerated browsers, but not all browsers have that capability.

Clients that don't use GPU acceleration run the Remote Desktop Protocol through WebSockets, which means that the image comes to the user as RLE. That's an old compression format that browsers can't decode. Instead, the browser uses JavaScript to render the image, which is an inefficient process that hurts performance.

Port, plug-in and app problems

Actually accessing an HTML5 client isn't always easy, either. For example, setting up VMware Blast is straightforward for an administrator, but port connections can gum up the works. The initial connection comes through port 443. If that port is blocked, HTML access won't work. Users will be able to log in, but the connection to the desktop won't establish and it will eventually time out. That means you have to do some configuration on the back end ahead of time. If you're using VMware View and Blast, you'll also have to make sure that the HTML Access component is set up on the View Security Server.

When you add browser applications and plug-ins to the equation, things can get even more hairy. True HTML5 clients don't use or need browser plug-ins, but all browsers have them, and they vary from one device to another.

GPU acceleration to come

VMware, Nvidia and Google have teamed up and created a Chromebook that runs Nvidia's Tegra K1 chip as well as an upgraded version of the Blast protocol that makes delivering high-quality graphics on a low-cost device possible.

For example, a Google Chrome application that uses Chrome Remote Desktop needs access to local resources. That access comes from Native Client (NaCL), an isolated application environment. Developers like to use NaCL to build applications because it gives the app access to local features. Therefore, it behaves like a native app, which users also tend to prefer.

But remote desktop clients accessed from a browser and running in NaCL have so much access that they can use whichever protocol they want to connect. Each protocol provides a different user experience, some of which are better than others. This creates a challenge for plug-ins too because NaCL applications work differently on different devices. Overall, it makes for an unpredictable connection and user experience, both of which can affect workers' ability to get work done, and their willingness to use virtualized desktops.

Next Steps

Advantages of HTML5 clients

This was last published in December 2014

Dig Deeper on Application virtualization and streaming

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

"most users won't notice a big difference in performance between HTML5 access and a regular client connection, any worker with graphics or video requirements will" - as was show as BriForum 2014, HTML5 access can play video just fine in most cases. Yes, native clients can do better, but the difference only shows up in really poor network conditions.

"Clients that don't use GPU acceleration run the Remote Desktop Protocol through WebSockets" - WebSockets and GPU have nothing to do with each other. All HTML5 clients use WebSockets, and all modern browsers have GPU acceleration built-in.

"which means that the image comes to the user as RLE. That's an old compression format that browsers can't decode" - none of the leading HTML5 clients use RLE. All of them use high compression image or video formats.

"The initial connection comes through port 443. If that port is blocked, HTML access won't work" - secure WebSocket connection over 443 is much, much more likely to succeed than UDP connection (e.g. PCoIP) over any port. Also much more likely than TCP (ICA/HDX and RDP). But yes, if all ports are closed then users won't be able to connect ...

The real problem with NaCL is that it only works on Chrome, and only on some devices - currently not on mobile. OTOH the only remote access solution actually using NaCL is Google's own remote access client.

The real limitations of HTML5 clients are:
1. No access to local devices, e.g. USB
2. File transfer instead of drive mapping, and some products don't support even that
3. Limited local printing, and some products don't support even that
4. Limitations on local clipboard access
5. Not all clients properly support diverse input locales
6. Significant variations between HTML5 clients in quality of support for mobile devices
Cancel

-ADS BY GOOGLE

SearchEnterpriseDesktop

SearchServerVirtualization

SearchCloudComputing

SearchVMware

Close