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.
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 an.ericom.com, 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 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.
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 http://famo.us. 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.