webui-vue first impressions

[Ed Tanous]

I got asked a question in a bmcweb code review that I feel like
deserved answered in a larger forum.
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/35457

"Ed, what would it take for you to switch to using webui-vue?"

What follows is my first impressions on an answer:

1. size parity with phosphor-webui.
On the current master, webui-vue has a 40% larger binary footprint
(614kb vs 440kb) and is still missing features that will add size.
Lots of bmcs run on 32MB of flash, so every kb matters, even if it
doesn't matter for the newer platforms with eMMC or larger SPI flash.
webui-vue needs to sort out where that extra heft came from, and
eradicate it.

2. A more thorough list of deficiencies in comparison to phosphor-webui.
There's a "feature parity" list on the readme that makes it seem like
it's closer than it is in practice.  In the course of writing the
patchset above I found that webui-vue doesn't support Mutual TLS,
doesn't support CSRF allow list (a security feature), and doesn't
support the "next" url forward.  None of these are listed in the
feature parity list.  Considering that's just what I found in the
initial look for the above patchset, I'm guessing there's more use
cases that got overlooked.  If we're dropping use cases, we need to be
explicit about it, and document why.

3. Chunked payloads
While Phosphor-webui opted for a single, very large javascript bundle,
webui-vue opts for multiple chunked bundles.  In phosphor, this single
bundle was done on purpose.  Chunking works great for CDNs and
multithreaded webservers, but tends to cause slower page loads when
done on a bmc, as bmcweb is largely optimized for single connection
single client single request.  Although it's able to handle multiple
clients and multiple connections, the bmc NIC tends to get "starved"
of bandwidth for other things, which can cause performance degradation
if you have lots of things going on in parallel.  I'd recommend going
back to the old paradigm, unless there's a good reason to chunk from
the BMC.  Note the bmcweb router holds all static routes in memory
under the assumption that there won't be very many of them.  With
chunking, that's no longer true, and probably causes some unnecessary
increased memory usage.

4. A more stable migration strategy
The changeover to vue got started completely from scratch, and got
mixed with DOM changes that functionally changed the UI.  If this was
to learn vue, and build a toy UI, that would've been fine, but the
fact that it's now its own full repo means we have fork problems, give
that there is no stable and specified bmcweb->phosphor-webui
interface.  It would've been relatively straightforward to move
phosphor-webui over to vue, by keeping the existing DOM, CSS, and
layout, while replacing the templating and router with vue, but the
decision was start over completely from scratch, and now openbmc has 2
"official" webuis.  I probably missed the discussion on why a hard
throwaway was needed here, but it seems like a series of patches that
ONLY moved over to vue would've been much easier to manage here for
the community as a whole, as each step of the way we can verify
feature parity when reviewing patchsets.  As is (ignoring Kathys
patches for a moment) there are 4 patchsets open for phosphor-webui.
Is there a documented strategy for who is responsible for moving them
over to webui-vue?  I didn't see anything written down, which leads me
to believe there's no plan.

5. Missed opportunity with Redfish UI
If you're going to build a redfish first GUI, it seems like an
opportunity where we could've used the CSDL definitions to drive and
build a lot of the UI automatically.  Given that phosphor-webui
doesn't do this today, this wouldn't have kept me from using
webui-vue, but the idea that the UI can simply build itself for the
"easy" stuff would be a massive win on productivity, and would
probably make me more personally inclined to go help sort out 1-4
above, as I think the end would justify the means.  As is, it takes a
very similar "hardcode every page" approach that the phosphor-webui
did.

Don't get me wrong here, I think all of the above can be fixed, and we
certainly could have a great Vue based webui that works for everyone,
but right now, the rather arbitrary "the project will stop supporting
on angularjs on X date" doesn't ring that important to me.  Javascript
frameworks and modules go unsupported all the time, and we're using
several "unsupported" modules today to no ill effect. Theming is a
nice feature, but those are mostly DOM and CSS changes, and are
unrelated to a changeover to Vue.  Translations was attempted in
phosphor-webui in the past, but to quote the review:

"neither any clients nor any companies wanted OpenBMC translated."
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/17582

Also keep in mind, I have very little seat time in webui-vue, the
above is mostly first impressions in response to the ask from Gunnar.
Overall, if the above can be fixed, I'd probably move to webui-vue.

Thanks,

-Ed