Webconverger is sometimes compared to "thin client" solutions like those offered by Enterprise heavyweights like Amazon, VMWARE and Citrix solutions. In reality they are in a different market sector called Virtual Desktop Infrastructure. Nonetheless, it's a good exercise to compare a Webconverger to VDI for analysis.

This is our biased view and we would love to hear your feedback.

Network fault tolerance


If Webconverger goes offline, tasks like form filling will still work. Once a form is submitted it will retry until completed. Truthfully offline Web apps aren't quite there yet, though they should get better in the near future with technologies such as service workers.

Typically when a network connection is lost VDI solutions are unusable. Furthermore in some solutions, if the "management server" goes down, this can be another single point of failure. Better VDI solutions can operate without a "management server" by caching its configuration. Webconverger actually also caches its configuration, in case https://config.webconverger.com/ goes down.

To summarise, Webconverger wins since it is more usable and will be even more usable in the future, offline.


Webconverger page loads will indeed suffer from a poor connection. However Web delivery is arguably "Internet grade" than typically LAN based "premise" VDI solutions where certain network assumptions are made and which will lag on the Internet. Once a Web application is loaded, it's very responsive and usable.

If your end to end network is managed by yourself, then this argument is probably moot, however this is increasingly rare as things move towards a more cost effective "cloud hosted" VDI.

Webconverger is powered by the Web and therefore is much more robust and usable on poor internet connections.


VDI quickly advocate its solution as scalable. Webconverger has been specifically designed with an Internet connection in mind and will prove to be less of a burden on the network.

In summary Webconverger is very bandwidth efficient.

Control and management

An important component to "mass deployment" is control and management. With Webconverger you can streamline your business process by setting the default application even easier than you can with VDI solutions. Just update the homepage= URL, enter a password and any amount of machines attached to the configuration will have a new configuration applied on reboot.

However we do not allow administrators to monitor the exact screen of the end user as most VDI solutions do, for privacy reasons. Some Orwellian enterprises sadly require this invasive feature in order to be considered "enterprise grade".

To conclude, VDI has better controls, unless you care about end user privacy, and then you will want Webconverger.

Input & Output devices

Since Webconverger is limited to a Web browser for input and output for the end user, we are limited typically to abstracted Javascript APIs of:

  • keyboard
  • mouse
  • printers
  • touch screens
  • microphone
  • camera

Truthfully the microphone and camera access via getUserMedia APIs are variable, and it is unlikely to work well without careful consideration and testing of your hardware.

With VDI you typically have complete control of all input and outputs. So you can attach anything to your local device and you should be able to integrate it with your application as the vendor intended. Webconverger, or rather the browser currently is unable to support a range of devices like cash registers and smart cards which a lot of businesses rely upon. However there is usually an out of band (usually more expensive) alternative solution that can fulfill these use cases, such as logging in with 2 factor authentication or standalone electronic payment devices.

VDI wins here since it has better device control.

Legacy support for non-Web applications

Given a legacy (Windows) application, it's not reasonably possible to run that in a Web browser. This is definitely a strength of VDI solutions, as all sorts of odd legacy environments can be provisioned easily.

Webconverger is waiting for corporate infrastructure to migrate to SaaS and Web applications at that. The reasons to migrate to Web applications are several:

  • open an application to a greater Internet audience
  • leverage open standards
  • reduce complexity

Of course some apps just can't be migrated easily to the Web, like display or compute intensive applications. e.g. CAD/matlab

However when applications are indeed Web applications, the Web has a good track record of backwards compatibility. Often one reason enterprises are burdened with odd insecure legacy platforms, is due to broken upgrade paths.

VDI is a better technology for supporting non-Web platforms, though hopefully the Web can maybe one day support VDI in the browser, with projects like freerdp-webconnect which still has a long way to go.

Hardware requirements

Webconverger runs on any PC with 1GB of RAM. Also we recently started testing on lower cost Android 5.0 and ARM7 Raspberry PI2 devices.

Typically VDI solutions run on PCs on top of pre-installed Windows operating systems, making it a heavyweight stack. However there are dedicated "locked down" VDI "thin client" hardware which can be quite inexpensive. One negative point is that this hardware is often proprietary and there is some lock in. On the contrary system integrators are usually better geared to supplying VDI solutions, since currently to deploy Webconverger, you need to source the hardware yourself.

Over time browsers and the Web applications they host may ask for more and more memory, making the base Webconverger system slower and slower. VDI solutions like Amazon workspaces correctly argue their VDIs can be provisioned with more memory or CPU on the server side. We would like to argue any client hardware in our experience probably needs to be replaced every 5-10 years and that cycle basically keeps up with Web browser and application bloat in that time.


This is a complicated topic (devil is in the details!), though overall the two approaches share a similar security model, where the application and data are remotely hosted and not local.

Webconverger's main security strength is that it's not susceptible to key loggers and screen grabbers like all Windows based thin client applications tend to be. The VDI on the server might be well managed, but usually the underlying non-dedicated clients are poorly locked down.

To summarise, assuming you are running Web applications in your business, the Webconverger system certainly has the edge. Webconverger offers a better user experience on a frequently unstable Internet, it's less complex and offers better security than the typical vulnerable thin client running on Windows.