+1 for a web based API to support a HTML5 client, assuming it is done properly (but that's pretty much a given expectation, why would anyone ask for a badly designed or non-working HTML5 client).
There seems to be a lot of FUD regarding HTML5 in this thread. I'm not sure everyone in this thread understands how well a HTML5 based interface can work. Probably due to having been exposed to bad ones. Of course, it's just not HTML5 we're discussing here (also JS,CSS and the backend stuff), but for sake of brevity let's continue to use that word alone.
Regarding the VMware thing though; You cannot blame HTML5 for what VMware did. Their failure is based on two things; 1) their initial decision to replace the vSphere Client with a Flash based client (this was about the most stupid thing they could have done, and in light of what any web developer would have told them, had they just asked, it's even more silly), 2) their incompetence or lack of effort (you decide which) to make the client better during the time it's been out there.
By #2 I mean that if they just wanted to, they could fix the issues in it rather swiftly and release a client that works well and has the features people are annoyed with the lack of. They seem to be getting there, but it's not a matter of whether "HTML5" can do it, it's about VMware just getting it done. Just because they didn't do it right, doesn't mean it can't be done right.
I've been developing web based applications for more years than I can remember, and I can definitely tell you that HTML5 and related technologies is perfectly capable of providing a well designed, highly usable and user friendly interface even for Veeam stuff. It's just about doing it right. If there's a problem here, it's not the technology.
Regarding the development of it, sure, there's sometimes a lot of headaches due to this and that browser (they all have their pros and cons), but in general HTML5 has been around for so long now, that all or most of the things you need to build this type of client is there and supported by the browsers that are relevant for this discussion. It's possible the effort needed to produce this client compared to one that is more platform specific is greater though, as there are more parts involved to get right.
Someone mentioned CPU load, but this isn't really rocket science - the frontend we're talking about here isn't going to do a ton of processing. None of what it needs to do is CPU intensive enough to be a problem AFAIK. And sure, there can in some cases be a bit of network delays, but as long as you're not on a slow connection it should just be fine. Just think about how much actual data needs to be transported to your UI, in the cases where there's the most going on in the current client - not very much at all.
One thing I would appreciate is if we could get to a point where we don't need Windows systems just to run Veeam. But that's probably a bit far away, since even if we get a web GUI, there's still the actual backup controller, proxy, etc that has to be run on Windows. So from that perspective, my personal use case for a HTML5 client is rather limited. What I need to do I can do in a Windows client, since I have to have Windows set up for Veeam anyway :/
If there's a HTML5 client created, then heck yes, it definitely should be working through an API that other people can build stuff around if they want! That's one of the pros with this type of solution. So perhaps, as some people here seemed to suggest, the best way forward into HTML5 land is to simply provide that API, so the community might start writing som stuff around it, showing the way to what might later become a design and feature set in the final client.
Also, make the things open source so people can contribute.