Today's HTML5 desktop remoting clients. A look at how far Ericom's AccessNow has come!

Back in 2011, I had a great call with Dan Shappir from Ericom as he outlined the details of just what exactly goes into an HTML5 client. At the time, they were working on the first version of AccessNow, which was used to extend their own Blaze protocol as well as PCoIP and EOP to HTML5 clients.

Back in 2011, I had a great call with Dan Shappir from Ericom as he outlined the details of just what exactly goes into an HTML5 client. At the time, they were working on the first version of AccessNow, which was used to extend their own Blaze protocol as well as PCoIP and EOP to HTML5 clients. Back then it was all about transcoding the native protocol into text, sending it via WebSockets to the client, and converting that text data to information that could be displayed by JavaScript and Canvas. Since then, the world has changed, and I caught up with Dan again to hear about what’s been going on.

That first version of AccessNow was basically about demonstrating that it was possible to deliver remote desktops via native browser components. Of course, each browser was different, supporting different features (which persists to this day), and in general, everything was much slower. Add to the list of issues the fact that enterprise features like drive mapping, clipboard mapping, printing, and audio were either lacking or not present, and it’s easy to see why HTML5 clients in general had a hard time catching on.

Ericom’s goal with v2 was to add in those enterprise features, but that’s challenging. Brian wrote an overview of this technology back in early 2012 if you want to get deeper, but for the most part Ericom added the enterprise features that people were looking for. The biggest issue, though, was that since everything was being accessed through the browser, they had to find new ways to implement things that seem relatively commonplace when using native clients.

I should mention, too, that everyone making HTML5 clients was in the same boat.

For instance, sharing items between clipboards is a two-step process, much like what you would see from a cloud clipboard solution (paste something local into an intermediary, then pull it out of that intermediary into the remote desktop). Printing involves using a local PDF printer to print to a PDF file, which opens in another tab. Incidentally, this works well in normal paper size scenarios, but not so well in custom printer situations where a third party printer solution would be required. 

Even file sharing is different, since there’s no capability to map local drives from a browser (well, you could if you could enable JavaScript to access all your files, but who would want to do that?!). Their solution: simply drag a file on to the desktop in the browser Window to upload, or right click on a file and select download to go the other way. Of course this also doesn’t work with remote applications that need access to the local file system, but there are other solutions for that if you really want to use HTML5 clients. Frankly, if you’re in this situation, though, you’re probably better off with something native.

I saw a demo of this solution, and though it was markedly better than v1, it was still plagued by the fact that it was very slow. So for v3, Ericom decided that speed was going to be the core focus. Using their demo site at, it’s pretty clear that they’ve succeeded in making it much faster. What’s changed since v2? There’s a few things:


In the intervening years, WebSockets has evolved to support binary data, which has eliminated the need to encode the HTML5 remote desktop information as text. This has a positive effect on every client, not just Ericom’s, because it allows the fronted to talk to the backend with re-encoding and then decoding it, losing features and functionality in the process. Yes, you still lose some features, but those aren’t as much related to WebSockets as they are the browser and JavaScript.

In the past, AccessNow was used more or less to transcode the RDP information to text, but because WebSockets supports binary data, they (and any other solution) can do a lot more. AccessNow works by effectively playing the RDP remote desktop data on a virtual screen, looking at the actual RDP instructions and optimizing it where necessary. For instance, RDP sends multiple small images to the client (which we’ve all seen on slow connections), but Ericom discovered that browsers are better at handling fewer large images than they are at many small images. They use this to their advantage, grouping the images together into large JPEG images and sending those down to the browser directly. This increases speed because browsers are natively awesome at dealing with JPEGS. For things that don’t need optimized they can simply pass that along to the client without all the crazy transcoding of the past.

Without going through a complete rundown (though I can’t wait to see Shawn Bass & Benny Tritsch’s session at BriForum), other solutions work differently. VMware Blast, for instance, basically swaps out the PCoIP encoder that pulls information off the video driver for a Blast driver that directly encodes the video to something that can be decoded by the HTML5 client. Other clients send the remote protocol data across the wire directly, rendering the desktop or applications via a JavaScript client. As you can imagine, this way isn’t so great.

Browser Advances

Coding can only get you so far, and it doesn’t matter what kind of code you write if the environment in which you run the code is slow, old, or incompatible. One of the other things that has helped with HTML5 client advancements is the simple fact that browsers are more capable than ever, even going so far as the leverage the local GPU of endpoints. Check out It looks awesome (even on an iPad), and those silky-smooth animations are coming to you courtesy of your browser and it’s support for GPU acceleration. 

The ability for AccessNow to deconstruct RDP means that it has the ability to carve out the things that can be done better by the browser alone, like JPEGS or motion. And, as the browsers become more functional, they can leverage that power to do more optimizations. 


Admittedly, v3 has a few shortcomings. Mobile device support is very basic, limited to just a few gestures. While pinch zooming works, I’m still left wishing there was an offset mouse like just about every other solution. I was assured that it was high on their list of priorities, though :)

Plus, there’s the general usability compared to a native client. Even in my quick test, I wanted to cut & paste the “normal” way but wasn’t able to. This is a small issue that won’t take much effort to overcome, but combine that with the file transfers and there could be cause for hesitation. Unfortunately, these are limitations of the browser-based approach, so if you’re going to HTML5 clients, it’s just something you’ll have to deal with.


Of course, we can’t talk about limitations without talking about the benefits. There are the more obvious ones, like being able to access your desktops from unmanaged devices where you simply don’t care about what’s running on the endpoint, where the endpoint is located, or what the endpoint even is. Some browser remote desktop solutions rely more on the Google Chrome Apps and Chrome Remote Desktop, which is limited to certain platforms. With a pure HTML5 solution, it’s truly device agnostic. 

Using HTML5 clients to access published applications (which you can do with AccessNow), at least to me, is more desirable than entire desktops. I have issues with seeing my desktop in a browser window, but mentally I’m more comfortable with single applications in single tabs. Other people think differently, I’m sure, but I think selling people on the one-application-per-tab mentality is much easier than saying “you have to pull up your desktop tab to get to apps X, Y, and Z.”

The other thing Dan mentioned was that since this is coming via the browser and not some other protocol is that many SSL VPNs work without having to establish a true network connection. While not all of them support WebSockets yet, many do, and with that functionality your users can simply sign into the SSL VPN’s native web interface and click on a link without actually having to connect to the corporate network.


What’s obvious is that all of this has come a long way from the early days of HTML5 clients. There are many approaches, and nobody appears to have the perfect solution for all use cases, but there are certainly use cases within most companies that can benefit from it. Every time one of these solutions is revved, the list of potential use cases expands. At the rate the capabilities are growing, HTML5 clients like this might be the best solution in the not-to-distant future.

Join the conversation


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.


It was great talk to you and thank you for this excellent overview. I do have a few comments that I'd like to make:

First, as to your statement "I have issues with seeing my desktop in a browser window" - all modern browsers support a "full screen" mode, in which the browser covers the entire local display (some call this Kiosk mode.) If you enter this mode, AccessNow will cover the entire local display, just like a "full screen" native client, and you won't see the browser bar, etc.

Second, it's important to emphasize that not all browser-based remote access clients work with all SSL VPNs. When evaluating HTML5 remote access solutions, you should explicitly verify that they work with the SSL VPN you have. This is, in fact, indicative of the whole field of HTML5 remote access: we are seeing significant differences between the capabilities of the various products, including performance, supported platforms, features, etc.

We are working hard to make Ericom AccessNow the fastest, most capable HTML5 remote access solution. AccessNow is currently available as a standalone solution for any RDP host, as a Citrix client, as a VMware View client, as a client for DELL vWorkspace, and as a client for our own Connection Broker: PowerTerm WebConnect.

Oh, and I'm also very much looking forward to Shawn Bass & Benny Tritsch’s session at BriForum Boston 2014. I intend to be there and to answer any questions that come up about this technology.



That's a good point about the full screen, but in my case it still is a browser window with a desktop in it. Yeah, it's full screen, but it's more about separation of applications than anything else. And, it's my own personal mental block, not an issue with AccessNow. I suspect others will have the same idea, though.

Thanks for the additional points,



I've tried a very alpha-stage HTML5 client for the SPICE protocol.  It worked but was very slow... and it too used websockets.  Speaking of SPICE, Xen added it (along with ARM support) in Xen 4.4.  I continue use SPICE on a daily basis over a LAN.

Now that I've gone completely off topic, let me get back on topic.  So, Gabe... you don't like it when you have a desktop window inside of your browser.  No problem, just open up a browser window inside your desktop inside of your browser.  Now you can guess the second step.  Open up a desktop in that browser.



We've seen very significant performance differences between various HTML5 remote access clients, even though all of them now use WebSockets. I guess we'll see more detailed info about this at Shawn Bass & Benny Tritsch’s session at BriForum. In the interim, you can contact me if you feel like test-driving AccessNow - all you need are an RDP host and 5 minutes to install.