Why Web is Not Good as Primary GUI for vSphere

I recently started to use the new Flex based vSphere Web Client while working on the open source vijava to support vSphere 5.1. Overall I like the look and feel, and particularly the extensibility story around the new architecture. However, I am not impressed by the performance – I saw way more “loading…” and clock cursor than I expected. Technically, I don’t think that is the direction VMware wants to bet on as the primary user interface for its flagship product vSphere.

For the performance issue, I think you should try it yourself and compare with the previous standalone GUI. I heard the new standalone GUI does not have the new features, therefore leaves users no choice but go with the slower Web Client. I am not saying that the old vSphere Client is a better choice but that it’s fast enough and works pretty well on Windows.
Anyway, that is not what I try to focus on here as I am more interested in the technology used and the product direction. Let’s continue there.

Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.

Web is NOT for Everything

First, I personally don’t think Web based interface fits all applications, especially for a powerful system management console as complicated as vSphere Client. The richness of Web applications still largely lags behind standalone applications which provide much faster and easier interactions. Although portable (not as portable as HTML though), the Flex based GUI does not have platform native look and feel, which is a big deal for some people. Just think about the trend of native apps in iPhone and iOS world. The reason you choose a particular desktop OS is because you prefer its user experience.

Another problem with Web application is that I quite often incidentally close my Web browser with a wrong click and lose the all Web pages and Web applications opened in it. It’s not a big deal with a Web page as I can reload it easily. But with an important Web application like vSphere Web Client, it’s different. I have to re-login and click all the way to where I left if I still remember the detailed path. It’s true that things aren’t too bad if I pay more attention, but still there is a risk. This issue can be fixed and I am working on a small tool to mitigate it. Stay tuned.

Flex is Dead, Almost

The Flex is going to phase out soon. The new industry trend is HTML5. Even Adobe had donated Flex to Apache Foundation for maintenance. Although Adobe says it’s still committed, but it also says: “In the long-term, we believe HTML5 will be the best technology for enterprise application development. We also know that, currently, Flex has clear benefits for large-scale client projects typically associated with desktop application profiles.” Thus, the transition to HTML5 is clear. So is the risk for the new vSphere Client to become a dinosaur.

I know it’s neither the only nor the first GUI built on Flex at VMware which has VMware View, vCloud Director, Data Director that all use Flex. But none of the products are nearly as complicated as vSphere Client. Business wise, none of them are nearly as important as vSphere Client. As of today, vSphere is still, and continue to be at least in the short term, the single most important product from VMware. The stake is too high for a mistake.

To be fair, although HTML5 is very hot, the browser support is not all there and the consistency is definitely not there yet. I am not even sure HTML5 will achieve the consistency Flex has done. If being constrained by Web and multi-browser support, Flex is perhaps the only choice therefore best choice. But the constraint is really a preference, and should be removed in my opinion.

Extensibility is Nice, But

With the new vSphere Web Client, you have so many flexibilities in extending the GUI. For more details, you can check out the documentation of the vSphere Web Client SDK Documentation.

However, to extend the new vSphere Client, you have a lot to learn: Java, ActionScript (the programming language used in Flex), Web application development with Virgo server. You no longer have the freedom to use your language of choice as the old Web based extensibility. It could mean extra learning curve if you haven’t learned these yet. For those who are already familiar with C# plugin of old client, it’s quite a steep learning curve. As the old saying pointed out, “no pain no gain.” Fair enough.

More importantly, moving away from Microsoft C# to Adobe ActionScript hasn’t made the client more open – it just switched from one proprietary to another proprietary platform.

What Should Have Been Done?

Because the new vSphere Client SDK borrowed quite a lot from Eclipse on extension mechanism, and also suggests that developers use Eclipse based STS IDE, I keep wondering why VMware didn’t pick Eclipse RCP (Rich Client Platform)  as the foundation for new vSphere Client.

With that approach, it not only solves the portability issue, but also comes with native platform look and feel. Moreover, Eclipse is an industry standard platform that has been proven for sophisticated applications like IDEs and keeps growing and evolving. The Eclipse also comes with Rich Ajax Platform (RAP) which supports Web based GUI with almost same code as on RCP but links to different libraries (I am not suggesting usage of Web but an option).

On product design, I still think the old dual client combination is a better choice. Remember there used to be a Web based client called Web Access which is never been meant or used as major GUI for vSphere management. But I think it can be further developed for limited set of functionalities that truly help a user who needs to do something urgently, say, restart a virtual machine while vacationing on Caribbean beach. While in office, it’s productivity that matters most – whatever gets the highest productivity. I know it’s not a Web client.

Having discussed this so far, I don’t think there is an easy and quick solution. All the community has to live on the decision for years. I’m sure that VMware will be forced to move along with HTML5 soon. That represents a lot of investment without much real value, not to mention that it will always play catch up game in Web world.

Again, I am writing a small tool that mitigates the problems I found with Web applications for vSphere. Sign up newsletter for announcement.

This entry was posted in Virtualization and tagged , , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Posted October 9, 2012 at 11:24 pm | Permalink

    Why Web is Not Good as Primary GUI for vSphere http://t.co/EMvnqElJ via @sjin2008

  2. Posted October 10, 2012 at 12:35 am | Permalink

    Why Web is Not Good as Primary GUI for vSphere http://t.co/jm14yon8 #business #tech

  3. Posted October 10, 2012 at 2:22 am | Permalink

    Why Web is Not Good as Primary GUI for vSphere – http://t.co/UXfUWPGn http://t.co/UXfUWPGn

  4. Posted October 18, 2012 at 10:32 am | Permalink

    Why Web is Not Good as Primary GUI for vSphere – http://t.co/RKJK4k1K http://t.co/RKJK4k1K

  5. Posted October 26, 2012 at 2:36 pm | Permalink

    VMware Developer vSphere Client Plug-ins: Rational behind Flex http://t.co/LAftlxik @sjin2008 Web Not Good primary GUI http://t.co/spg2O4jZ

  6. Posted October 27, 2012 at 1:35 am | Permalink

    @kylemurley Flex is perhaps best 4 vSphere Web Client, but I just don’t think Web is best as primary UI 4 #vSphere http://t.co/kYMk8DO3

  7. Posted October 30, 2012 at 7:51 pm | Permalink

    Nice comments Steve. I agree that the new web client is not as responsive as the old .NET client was. Also the plug-in development for the .NET client was more flexible and easier (did not require specific programming language knowledge). Also my existing script based plug-in is broken and is not portable to the web client without we having to re-write our plug-ins using the web client SDK.

  8. Posted November 2, 2012 at 3:22 pm | Permalink

    Why Web is Not Good as Primary GUI for vSphere – http://t.co/jKrH8SNK

  9. karlochacon
    Posted April 22, 2013 at 10:01 pm | Permalink

    yeah Web client is very very slow….I still using Windows GUI for basically all my tasks I only use Web client for the Vmware Data Protection

  10. Posted May 22, 2013 at 8:51 am | Permalink

    Still an excellent article.
    FYI, same issue noted with ESXi 5.1 Update 1. When paired with the new 5.1 U1 vCenter Appliance, WebUI navigation still sluggish, even when the appliance is running on an SSD.

  11. Posted May 26, 2013 at 2:00 pm | Permalink

    Hi Paul,

    Thanks for the update! I don’t think the issue is with the underlying storage but with the backend Web server, therefore SSD doesn’t help. Hopefully the performance issue will be fixed in the future release.


2 Trackbacks

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


    My company has created products like vSearch ("Super vCenter"), vijavaNG APIs, EAM APIs, ICE tool. We also help clients with virtualization and cloud computing on customized development, training. Should you, or someone you know, need these products and services, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.