Re: Updating BMC GUI Front End Framework

[Ed Tanous <ed.tanous@intel.com>]

On 9/6/19 7:51 AM, Derick Montague wrote:
> Hello,
>  
> We would like to start the discussion of migrating the BMC GUI off of
> AngularJS. The AngularJS long term support period is 3 years and started
> on 7/1/2018 and will end on 7/30/2021. You can read more about this on
> the angular blog
> - https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c.

Despite what this says, I would be _very_ surprised if we hit any major
issues after that date.  Given how many major applications are still
AngularJS based, I suspect the angular community itself will continue to
support the 1.X series for a long time to come.  With that said, if
someone wants to move us to something more modern, I'm happy to see it
happen.

>  
> The most likely options for migration are Angular, React, and Vue.
> LogRocket has a decent comparison of the 3 frameworks
> - https://blog.logrocket.com/angular-vs-react-vs-vue-a-performance-comparison/.

I think in the end a lot of this going to be determined by whomever
wants to do the work.  Oddly enough, Inspur has an implementation of a
VueJS based single page app that I've run on OpenBMC before, and seems
to work ok, although it needs some work.

https://github.com/inspur-bmc/OR-web

In their implementation, they even reused the phosphor-webui recipe, and
their backend implementation was based on bmcweb, so at least we know it
interoperates with OpenBMC properly.

If we're going to Angular2+, we will likely need to move to typescript
as well given that's what most of the examples are in.  I'm not sure if
that's something people are comfortable with at this point, but it's
something to consider?


>  
> My first thought based on the size of the application, the need for a
> smaller footprint, and the benefit of a small learning curve would
> be Vue. However, I'm just throwing that out there to start the conversation.
>  

To be clear do people believe the current footprint (about 440kb) is ok
at the moment?  Or are we trying to get a reduction with this change?

> Does anyone else have a preference on the next front end framework?

One thing I'd like to understand is development process;  How are we
going to separate out the javascript changes from the DOM changes that
are needed?  Ideally, we'd separate them, and make sure that we can
generate the same DOM from both frameworks, which should insulate the
effort a bit from having to keep up to date on more recent changes.  By
the time the new effort merges, hopefully it's identical to the existing
feature-wise.

On another topic, one thing I've wondered before:  Do we want to
continue having a single page application?  While it has its advantages,
they come at a cost of complexity and size.  Would it be possible to
build a more statically driven site that gives the same experience?

I suspect the answer is no, but if we're talking about rewriting the
whole frontend from scratch, we should at least ask the question.