Dying software forces changes to VMware’s vSphere Clients VMware is about to make some changes to its vSphere clients, and users are going to have to jump through some upgrade hoops to remain in complete control of their VMs. Things got slightly weird with the vSphere web client in 2016 when VMware announced that it planned an HTML5-powered replacement for its Flash-based client. …
I think the author is giving VMWare too much credit. VMware were late to market with a web interface (Flash) and when they did release it they'd based it on obsolete technology.
The Flash interface was VMWare's first web interface. Prior to that we had to use the Win32 client. And for a long while the Flash client still couldn't do everything. For once thing it was vCentre only. You still had to use the Windows client to manage individual hosts. Also VMWare tech support often told you to perform tasks with the Windows client rather than their Flash web UI.
But even whilst VMWare were working on the Flash interface the writting was already on the wall for Flash so they were working on a deadend product.
True - it looks VMWare bet on all the wrong horses at the wrong moment. On the HTML side, not helped by the heavy fragmentation of libraries, and the endless streams of framework du-jour.
Moreover, they heavily use Java server side. Why they never made a Java client instead of a Win/.net one? OK, Java is Java (and it's piling up a lot of backward compatibility issues as well), but at least it would have run on different platforms.
Meanwhile 6.7 still relies on the Flash client for the Update Manager, is there an update moving those functionalities to the HTML client too?
Sure - I pointed out the backward compatibility issues, and I don't like Java much - but at least it's still alive, not deprecated, and wouldn't have required to re-write from scratch the UI every time, plus they already have Java server applications in the product, why add another unrelated technology like Flash? And there are still many inconsistencies in the HTML client, at least in the 6.7 one, I didn't have the chance to work with the 7 one yet.
Sure, they would have needed to keep the client updated.
Any particular reason why it'd have to have been a Java web interface? Couldn't they just do a standalone Java app for the client and be done with it?
I know this is VMWare we're talking about, but this isn't exactly a tremendous ad for writing large apps using Web technologies. If a bunch of stuff has less than a 9 year lifetime, that's not exactly helpful...
If MS finally do port WPF to .NET Core for Linux, Mac, etc then that stands a very good chance of becoming the way to have a write once, run everywhere GUI application. .NET Core + WPF would probably be a far richer cross-platform ecosystem than you get from the more traditional cross-platform toolkits, e.g. Qt or GTK, so it could be a one stop shop for someone wanting something like a vm client viewing app. That could tick a lot of boxes for those getting fed up of the web giants forcibly changing standards all the time, requiring a re-write every time they do so.
Java could have done that, but I don't see many good Java GUI frameworks (plus Java itself seems to have been a write once, debug everywhere platform...).
Thank GOD they didn't make a Java based client! I give you DELL\EMC Networker, Java based client and its total dogshit and has been for years, trying to get the bloody thing to work nearly every time you get a new Java Client installed is like pulling teeth. Like VMWare they have an HTML5 client, but you can do sod all with it! next to bloody useless!
It is *not* an "HTML5-powered client" and never has been. It's always been yet another horror of a Single Page JavaScript Application. Always destined to fail in multiple ways, whether then immediate reliability, accessibility, usability and later in this case relying on yet another "flavour of the month" JavaScript library which largely attempts to (badly) replicate standard browser HTML and CSS functionality.
Want a vaguely reliable web application? Want one that has a hope of accessibility and reliability, particularly cross browsers and devices? Then develop HTML first (with CSS added for presentation). Then, if still desired or even necessary, add the minimum amount of JavaScript to enhance the HTML and CSS, never to generate or control the HTML and CSS.
it's time to follow the lead of AWS. Go CLI and forget the slow, cumbersome UI. Let pissed off users or sufficiently motivated consultancies write Python interfaces to CLI calls. You don't need a dashboard anyway that's Nagios' job. Write wrapper scripts in Perl or Bash. UI and UI portability is a fools' errand.
Or just go back to the old .NET windows-only client. Nobody cares if they have to keep a Winblows box around to admin via VCenter.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
