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.