Updating BMC GUI Front End Framework

Updating BMC GUI Front End Framework

[Wang, Kuiying]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

Yes, it's time to do it.
I suggest to use Vue, there are several reasons:

1.       MIT license https://github.com/vuejs/vue/blob/dev/LICENSE

2.       The sizes of the libraries: Vue is about 80KB, much smaller than Angular (500+KB), React(100KB)

It is sensitive on space for our OpenBMC embedded system. So Vue is the best candidate.

3.       It is already used by big internet company like Gitlab/Alibaba.

4.       Vue is the most popular frameworks, according to the number of stars on GitHub projects for Angular, React, and Vue.
Angular                React      Vue

# Watchers         3.3k                        3.7k        5.7k

# Stars                  43k                         71k         122k

# Forks                 11k                         16k         17k

5.       Vue is two-way binding

6.       Vue is based on JS+HTML, it's easy for existing AngularJS developer to transfer, but not like Angular (TS) and React (JSX)

Thanks,
Kwin.


On 9/6/19 9: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.

> 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/.<https://blog.logrocket.com/angular-vs-react-vs-vue-a-performance-comparison/>

> There is also a really interesting framework called Svelte for

> building reactive apps that might be worth considering as well -

> https://github.com/sveltejs/svelte

> 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.



Derick, thanks for looking into this.  I agree a small footprint and

short learning curve are important criteria.   Some other criteria to

consider:

- Licensing terms, looking for permissive licenses like Apache 2.0 or MIT.

- Community support, especially for security fixes.



- Joseph



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

>


Thanks,
Kwin.


[-- Attachment #2: Type: text/html, Size: 11671 bytes --]

Re: Updating BMC GUI Front End Framework

[Derick Montague]

[-- Attachment #1: Type: text/html, Size: 3877 bytes --]

Re: Updating BMC GUI Front End Framework

[Gunnar Mills]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]


On 9/17/2019 3:46 PM, Derick Montague wrote:
>
>     Yes, it’s time to do it.
>

Derick, Thanks for starting the discussion on this! Kwin, Joseph thanks 
for your input!
Although we have time until AngularJS goes end of life, I agree we 
should start looking at moving away from AngularJS.

>     I suggest to use Vue, there are several reasons:
>
>     1. MIT license https://github.com/vuejs/vue/blob/dev/LICENSE
>     <https://github.com/vuejs/vue/blob/dev/LICENSE>
>
Angular and React are MIT as well.

>     2. The sizes of the libraries: Vue is about 80KB, much smaller
>     than Angular (500+KB), React(100KB).
>
I think some of the savings of Vue/React would be negated by the plugins 
we would need but agree this is a benefit.

>
>     3. It is already used by big internet company like Gitlab/Alibaba.
>
Google and Wix are some companies using Angular.
Facebook, Uber, Instagram, and Paypal, are some companies using React.


>     4. Vue is the most popular frameworks, according to the number of
>     stars on GitHub projects for Angular, React, and Vue.
>
>                                 Angular              React       Vue
>
>     # Watchers           3.3k                    3.7k     5.7k
>
>     # Stars                  43k                     71k       122k
>
>     # Forks                 11k                     16k       17k
>
I think your numbers are a little outdated.
If I look at the three projects, Vue has the most Stars, React has the 
most Watchers, Forks, and "Used by".

https://github.com/angular/angular
https://github.com/vuejs/vue
https://github.com/facebook/react

If I look at things like Google trends and npm trends, Vue does not 
score as highly as React.

https://trends.google.com/trends/explore?cat=31&q=Vue,%2Fm%2F012l1vxv,%2Fg%2F11c6w0ddw9 

https://www.npmtrends.com/react-vs-vue-vs-@angular/core

I agree though Vue.js has gained a lot of popularity since its launch in 
2014.


>     6. Vue is based on JS+HTML, it’s easy for existing AngularJS
>     developer to transfer, but not like Angular (TS) and React (JSX)\
>
I think what is easiest to move to is more complicated than that.

https://buildingvts.com/moving-on-from-angularjs-5417b79693a9

>     - Kwin
>
> Just adding a consensus of the 3 responders so far. Anyone else have 
> any feedback on the future front-end framework for the GUI?

I think any of these frameworks would work. I would like to see more 
discussion on this, specially around what benefits we are trying to gain.


[-- Attachment #2: Type: text/html, Size: 9196 bytes --]

Re: Updating BMC GUI Front End Framework

[Ed Tanous]

On 9/17/19 3:13 PM, Gunnar Mills wrote:
> 
>>     2. The sizes of the libraries: Vue is about 80KB, much smaller
>>     than Angular (500+KB), React(100KB).
>>

I have no idea where these numbers are coming from, but we need to pump
the brakes a little.  Any framework we pick is going to require some
non-standard modules, and be run through webpack minification and
compression, which will significantly swing the result as we've seen
with other modules we've tried to compare apples to apples.

Rather than try to compare frameworks in a vacuum, I'd rather state that
the "new" framework must be the same size or smaller than the existing
for the same functionality.  If it's larger, why even upgrade given how
precious flash space is to us?


> I think some of the savings of Vue/React would be negated by the plugins
> we would need but agree this is a benefit.
> 
>>
>>     3. It is already used by big internet company like Gitlab/Alibaba.
>>
> Google and Wix are some companies using Angular.
> Facebook, Uber, Instagram, and Paypal, are some companies using React.

All of the above is irrelevant.  I'm fairly certain Gitlab, Alibaba,
Google, and Wix don't build BMCs (or embedded platforms) using those
frameworks, so I'm not really sure why we're name dropping here.

Lets pick the one that works best for the BMC.

>>      
>>
>> Just adding a consensus of the 3 responders so far. Anyone else have
>> any feedback on the future front-end framework for the GUI?
> 
> I think any of these frameworks would work. I would like to see more
> discussion on this, specially around what benefits we are trying to gain.
> 

Completely agree.  I'm really worried we jumped directly to a new
framework and complete rewrite.  Maybe that's where we'll end up, but
I'd like to get some more concrete answers to why we would consider
rewriting the webui from scratch.  Using something "modern" is not a
good reason.  Security isn't a great reason, as that's largely outside
the webui framework.

IMHO good reasons include:
1. Reducing the code size (both in binary and in LOC checked in)
2. Reducing the number of bugs present, by introducing more robust concepts.
3. Increasing load time and run time performance of the webui.
4. Reducing the jankiness/brittleness of the build system (yes, I'll
take the blame for this) by replacing the frameworks with something more
standard that yocto already understands.

RE: Updating BMC GUI Front End Framework

[Derick Montague]

[-- Attachment #1: Type: text/html, Size: 4144 bytes --]

Updating BMC GUI Front End Framework

[Derick Montague]

[-- Attachment #1: Type: text/html, Size: 3340 bytes --]

Re: Updating BMC GUI Front End Framework

[Joseph Reynolds]

On 9/6/19 9: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.
> 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/.
> There is also a really interesting framework called Svelte for 
> building reactive apps that might be worth considering as well - 
> https://github.com/sveltejs/svelte
> 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.

Derick, thanks for looking into this.  I agree a small footprint and 
short learning curve are important criteria.   Some other criteria to 
consider:
- Licensing terms, looking for permissive licenses like Apache 2.0 or MIT.
- Community support, especially for security fixes.

- Joseph

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

Re: Updating BMC GUI Front End Framework

[Ed Tanous]

On 9/7/19 2:52 PM, Joseph Reynolds wrote:
> - Community support, especially for security fixes.

In terms of the webui, the "UI" itself is executing in the browser
context, and a majority of the webui "security" is a contract between
bmcweb and the browser, which has next to nothing to do with the
javascript itself.

If you search AngularJs in the CVE database, there's nothing against
angularjs itself, only particular instances of AngularJS applications
with bad containers, not the framework itself.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=angularjs

We do need to make sure that whatever framework we move to supports the
content-security-policy headers we have in place, but most of that is
just appropriate configuration of the framework, and sticking to some
rules when developing, rather than a framework choice itself.

Re: Updating BMC GUI Front End Framework

[Ed Tanous]

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.