Spring is in the air, and HTML5 VDI clients are popping up like daisies. Actually, they’ve been popping up for a while, now. Over recent years, many of the players in the virtual desktop infrastructure (VDI) space have built customized HTML5 clients for accessing remote desktops in their stacks, and the number of independent HTML5 RDP gateways on the market is pretty remarkable (ask Google!)
Why the move to HTML5? What do you gain (or lose?) in a VDI environment when using an HTML5 client? Oh, and what is this thing called “WebAssembly” that I mention in this blog’s title?
First things first.
Why the move to HTML5?
In 2011, the WebSocket protocol was standardized (although it was part of the HTML5 specification before that) for use in client/server applications. Unlike HTTP, which opens and closes a socket for each request, WebSockets use a single TCP socket that is left open, allowing data to be continuously sent back and forth between the browser and server in real time.
HTML5 VDI clients use WebSockets to transfer the communication between a server (one of those HTML5 RDP Gateways that Google will tell you about) and your Web browser, making WebSockets the first key to getting acceptable performance in your HTML5 VDI client.
But, WebSockets just get the data to your browser. Something else needs to interpret and render that data in your Browser. For the HTML5 VDI clients on the market, right now, the latter part is a client powered by JavaScript that automatically loads into your browser.
HTML5 VDI clients check many of the boxes you need to satisfy end users. They are a clientless solution, simplifying rollout. End users can connect to their desktop from any device of their choosing, including mobile devices of all sorts, enabling BYOD initiatives. And, by nature of being a gateway, they can provide remote access.
That said, end-user acceptance often comes down to the two “P’s” of performance and peripherals. HTML5 VDI clients can work around printer redirection by printing to a local PDF printer and making that file accessible to your local client, but other USB devices remain a challenge. Then, there’s performance. A number of factors influence performance, such as the method used to encode the remote desktop’s video and audio, the bandwidth between the server and browser, and how the remote session is render in the browser.
So where does WebAssembly comes in?
WebAssembly gives you access to a set of low level building blocks that, potentially, you can use to build your HTML5 VDI client. It’s a replacement for the JavaScript component that renders the remote session.
I’m squarely in the realm of conjecture, here, but it’s an interesting realm. WebAssembly is emerging as a standard and is backed by the likes of Google, Microsoft, and Mozilla. Experimental versions of their Web browsers now support WebAssembly, and the performance of the demo is impressive.
So, what do you think? Can WebAssembly take HTML5 VDI clients to the next level? I don’t actually have that answer, and with WebAssembly still under development, maybe no one does. But, I’ll be interested to find out!
What now?
In the meantime, HTML5 VDI clients have their place in a number of use cases: for remote access, for users with mobile devices, as access for temporary or task worker, to name a few. Think of them, at least for now, as another arrow in the quiver full of client and display protocols on the market. By giving your end users access to the resources they need, connecting from the devices they want, you ensure the success of your VDI deployment.