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
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.
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.
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.
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.