Service UI and Angular and VueJS

ui

#1

Hello Devs and Community!

The SUI team has been doing a lot of discussion both internally and externally regarding the Angular (v4) transition. For the SUI team, this will represent a significant re-write of things; and so we have questioned the continued use of Angular for the SUI. After some careful discussion and getting a lot of feedback, the consensus of the SUI team is to rework the SUI to use VueJS, instead of Angular (v4)…and adding Redux for state management.

There are a lot of reasons for this, but some of the bigger points are:

Reusability

With the Node / JS community is rapidly evolving (cue lots of framework jokes), there seems to be a new framework every week. There are no perfect decisions when coming up with a framework choice as Angular’s 1.x to 4.x changes have proven that even if you try to stick with a popular framework you can get stuck with massive breaking changes that can necessitate full code rewrites. So, teams within Red Hat (and beyond) are choosing frameworks that work best for their team (which is the brilliance of open source). That said, one of the main concerns is of a large organization is reusability (i.e. not reinventing the wheel). VueJS allows us to get as close to pure JavaScript as possible, and thus maximizes reusability (with mostly pure JS, it can be used in any framework). Likewise, Web Components are the way of the future but, everyone agrees they just aren’t there yet. VueJS allows us to get really close to web components, so when the technology is stable, migration will be an almost trivial effort.

Learning curve

VueJS is a robust, yet simple framework. The learning curve is minimal (you just need to know HTML5 and ES5). Additionally, this makes debugging very easy, and onboarding new engineers (of any level) fast and thus get them more productive faster). As an added bonus, many built in Vue components have been modeled after Angular 1.x core components which makes it even easier for Angular developers to be able to develop in Vue
Flexibility. Without additional tooling, developers can use pre-processors such as Pug (formerly known as Jade) to author Vue templates, sass, or less in addition to the standard CSS. JSX or render functions for logical or presentational templates and many other easily configured . Vue has out of the box developer workflows utilizing webpack that makes blending these preprocessors and project build/deploying a very trivial task.

Time to market

Since VueJS is not as a heavily opinionated framework solution, we have the ability to tailor usage of only the best practices that meet our specific needs and don’t lock us into lots of unnecessary code overhead to accomplish simple tasks. This in turns makes it quicker to turn out higher quality, readable, and testable code. Some of our other popular alternative frameworks are monoliths that enforce opinions on app design as a one size fit all solution.

There are lots of other reason, and really they can be summed up here:

We would very much like any feedback from the community at large on this. Out team has looked extensively at this, and fully believes that this will increase productivity and code reusability long team.

[Update 7/18/2017]: Just to be clear this is very much still an open discussion. While the team believes that VueJS is the way to go, please consider this post a “this is what we are thinking” and NOT a “this is what we have decided


#2

How is that going to integrate with Patternfly ? I have found this
repository: https://github.com/mtorromeo/vue-patternfly, but it is in alpha
state, so far from being ready for production. How much UX breakage this
change will imply ? I am not against change, just wondering if this will
also be taken as an opportunity to rethink the UX of SUI.


#3

First, let me congratulate you on challenging the current stack, I’m sure its not easy to drive a change.
Also - selecting a state management / architecture such as redux is very welcomed.

Can you provide more details on how you selected VueJS vs Angular 4 / react etc? I think it might help others to understand the set of requirements, pro/cons etc that lead to this change.

I personally believe our aim is to try and reuse technologies that are within the same project and ecosystem(e.g. patternfly), it has a lot of value if we can reuse simple or complex ui / business logic.

did you happen to do a POC with vue? would you be willing to experiment with other technologies (such as react)?


#4

+1 I think it makes sense revisiting, at least on a high level if there are requirements to change the UI/workflow etc its probably a good opportunity to improve the UX in the process.


#5

So,
what’s the plan on sharing components between ui-service and ui-classic?

I did say I think moving to some other thing is a bad idea beacuase I see a problem here regarding sharing code and the whole ui-components effort - so I guess you have come up with a nice solution that solves this problem?

Or should we just give up and consider ui-components to be a ui-classic-only thing?


#6

This is exciting, too exciting, so flippin’ exciting! A change like this will undoubtedly introduce some growing pains, one of the primary being dependencies, “hey, how are you folks gonna replicate x”. Worst case we rewrite.

WOAH HEY NOW THAT’S A :rowing_man: OF WORK!! Wait wait wait wait, hear me out, rewriting anything in angular ^1.5.x, that whole component revolution is as simple as changing ng for v almost. Lifecycle hooks are still around and kicking, heck you even have template filters behaving much in the same way as they do in angular. There are so many similarities between the two (ang 1.x and vuejs), component logic (at worst) will be copy and paste into a new wrapper. Heck, there’s even a project out there that wraps vue components as angular components!. Yes there will be work involved, but at the end of the day, we’ll end up with a “more generic” (?) expression of a tool in plain old js and html that can walk just about anywhere.

Ok now for the controversial statements. Of the many things that excites me about this notion (da vueeeeee use idea), aside from my mental dab each time I hear vuuuuuuuuue, is the fact that it embodies a purist approach to web development. “wat da eff?” Yeah, I know, a fluffy statement that doesn’t seem to mean anything, at this stage its a feeling more so than a sentence (here goes nothing). So instead of learning frameworks, remembering special syntax, a specific “way” of doing something given a stack (ok this one kinda still applies), we developers are empowered to execute on general architectural concepts with the basic tools we all know and love. Hmm that kinda reads like the rest of the stuff already said, minimal learning curve, lightweight relatively un-opinionated framework.


#7

@fdupont -

RE: Patternfly Integration

What we were thinking is that, as we convert everything to VueJS, we would put it all in a patternfly-vue repo (hopefully get the UXD team to create us a repo under the patternfly org).

RE: UX of SUI

I’ll leave that to our awesome UXD team to decide :slight_smile:


#8

:scream_cat: ! OH MY NEVER ! :scream_cat:

Never gonna give up Martin. NEVER.

But you raise a super important point. Code reuse between an app family! Which is what we are, SUI a sibling to Ops, parta da miq ui fam!

SO worst case, yes sadly, we rewrite components ui-components for (which natively supports typescript) and while that sounds bad, its a lot less work than one might think (see pervious comment in params).

OK so looking at this (this being how can we as an app family best rely on each other) from the flip side, if our app family is ever going to grow outta anything (anything referring to the tech stack) going to vue introduces the least number of growing pains (and frankly a lotta support). Hamstringing our tech stack over 1 to 1 interoperability sounds dangerous (maybe?) and certainly holds us back from new exciting shiny things.

The plan, as you say, is evolving and as we become more enthralled in mentally talking this out it is sure to morph more. ui-components is a collection of typescript components, vue supports angular components 1:1 (practically?) AND typescript, SO how bad can it be :smirk_cat: (but seriously, not that bad, logic between the two doesn’t have to change)


#9

@AllenBW thanks, that sounds sane :).

I guess I just have two problems here:

  • I’ve never seen a Vue component used from an angular one, I’ve never seen it call passed-in angular functions, I’ve never seen it react to changes in attributes coming from above. I’ve never seen it react to angular events…
    So… I’ll be much calmer once you have a working prototype demonstrating such a thing can even work :wink:

  • Are you two going to rewrite it all? How long do you expect a team of 2 people to spend on just converting ui-components? I’m not saying I wouldn’t be willing to help, but I am saying that we don’t need the conversion and thus it would be low priority for us.


#10

@himdel YEAH!! :nail_care::hammer: or wait it would be :hamburger::snail:? either way, sharing that “it all looks the same behaves the same” vision is something I wanta doooo maybe like a lunch n learn kinda thing?

To your point, yep, lifecycle hooks! (sorry for posting nothing but links, kinda seems like a copout, but its the most concise way I can think to communicate the point) also taking a look at the vue lifecycle diagram it gives us all that we know and love, if you’re keeping track, exactly the same number of lifecycle hooks, 8 (created() == $oninit() ; updated() ~= $onChanges(); etc). Oh yes, calm Martin <3 we want that, BUT you wont just give us calm, you’ll force us to be thorough logical reasonable sensible, to earn your calm, which in turn will yield a better product, I look forward to this adventure :pineapple: :cake:

Oh geez, yah that second point, we can’t change reality, resourcing vs perceived scope of undertaking + unknown unknowns = oh my oh my :exploding_head:. First things first, there isn’t an expectation of help. ALWAYS WELCOME NEVER WILL BE REFUSED, but this undertaking isn’t looking to force recruit anyone. Leaning on da thing I kinda said earlier, because we’re vuuuuuuuuuuuueing all the stuffz already been written, we just need to put in some nice wrappers (?) to work in vue. SO this does mean extra maintenance on our part, part keepin the :ear: to the :heartpulse: of changes in ui-c bug fixes and the like, but again, our :latin_cross: to bare for sure. :bowing_woman:


#11

with the risk of not using enough emoji, I for one would like to see a POC prior to making any decision, and TBH I think your POC should expand outside of current miq technology and expand to other popular frameworks - namely react.

since we know that some of the providers that are going to use miq (ovrit, and potentially foreman, cockpit etc) are already using it, i think it deserve our time trying it out and discussing a more pro/con kind of discussion. on the process, bonus points to learn how to wrap newer component via current angular /rails.


#12

There is never enough emoji for @AllenBW.

…and in other announcements, all SUI sprint review slides will be only using emoji :stuck_out_tongue_winking_eye:


#13

@ohadlevy agreed, poc will make what we’re talking about here feel much better, from the highest of levels, the simple answer to your question (of why not rewrite the sui in react?) is, angular (miq present) -> react = different; vue -> react = different; angular -> vue = very similar!

What does “very similar” mean? As was already demonstrated, from an tooling standpoint they have much in common, lifecycle hooks, similar syntax (change a few letters, can’t stress this point enough, syntax is so similar), template filers, support similar architectural patterns, furthermore vue doesn’t have force relearning naming conventions on devs (ok sounds petty and trivial but its a big deal). Here

SO the tl;dr is, we’re a tiny but :dancer: team, haven’t done react in the past, don’t want to pile on the tax of learning something new, vue isn’t something new, its a distillation of what we already know and love and brings us even closer to a “pure” app (less framework less new markup, looking at you ts). The effort to go to react or angular (from angularjs) is far greater than the effort to go from angularjs to vue (or angularjs to angular for that matter). I’ll be interested to see if vue turns out to be the the thing for peeps that want new and fancy but can’t let go of angular 1.x :laughing::thinking:

Oh annnnnnd comparing vue to react markup :taco:

(I tried to hold back :hole::back: :slight_smile:)


#14

this is exactly why I ask you to do a POC, having first hand experience is usually superior to “random” blog links.


#15

So I think one super important factor to keep in mind the work involved. I am saying this in the context of the fact that no matter what we do, rewriting SUI in a new framework will end up having to happen regardless because Angular 4 != Angular 1.x and the code is about as portable as it would be to any new framework and the amount of code conversion is equal no matter which framework we go with. That being said, I think one of the reasons that the SUI team has been discussing Vue is because as a less opinionated and closer to vanilla JS framework which helps this framework lend itself to being really quick to be able to develop robust applications in. With the fact that the SUI team is a little smaller than some other teams, we push ourselves to work as smart and efficiently as we can so we can still be agile yet small. I’ve personally evaluated all the popular frameworks out there for personal projects and otherwise and having dipped into trying to learn React, Angular 4.x and Vue. My vue learning curve only took a night vs days it took for me to grasp the other frameworks. This is coming from someone who has been using Angular for 4+ years at this point.

I think the SUI is the perfect place to test out implementing Vue because of the current size of our codebase.

Everybody above has made great points above and I love having this discussion out in the open.

I don’t want to rehash all the points @allenBW has made but many of them reflect my thoughts and mirror research and real world experience I have had.

One point I will make that we all care about is performance. From many of the blogs I have read on framework performance, I keep seeing Vue come out consistently on top. A close second is always React. I think there virtualDOM implementations are similar but Vue seems to consistently beat out React. Not that the fastest has to win, but its just another metric worth considering as our application grows in size and complexity. Performance should always be a consideration.

As for sharing UI components with our shared repo, I am all for reusability and sharing code as much as possible, I think the perception that migrating those existing components from Angular 1.x to 4.x is easy is one is definitely one that has to be thought out as well. I have been working in that codebase and they have taken steps to make the migration easier on themselves but there is definitely a decent amount of work involved in migrating those components even in spite of the work already done. Even with that work, I don’t believe much time or effort will be saved in migrating vs reimplementing in a new framework.


#16

I totally agree with a POC but I think having a discussion with enough of a backstory and justification for the POC will make it easier for a POC to be successful. Rather than just charging forward with a direction it makes sense to have a open and balanced discussion.

I’ve even considered building out a POC mobile app using Vue as great boilerplate as I have a solid background in mobile application development and cross mobile OS deployment. I am fairly certain I could develop a fairly compelling demo of basic SUI features in about a week(ish) if given the time. It’s possible I might even build it in my own free time either way.


#17

Thus far we have not seen a huge hit converting the Angular 1.x Patternfly components to Angular NG components. Given that the Patternfly-NG repo is currently being built out by the UXD team and will soon support most (if not all) of the Angular Patternfly components, wouldn’t you see a cost there to re-create the components, once again, in Vue?


#18

I thought that SUI was the final product not a way to test Vue.

If you are using SUI to test Vue then what for? What is the purpose? Can you, please, explain this?


#19

First of all I have to say that as a developer I like VueJS. It looks lightweight
and neat. The examples are easy to follow, quick to start working with. Cool.

Many frameworks can be used

Previously we have seen or participated in discussion about EmberJS, React,
Angular 1.x, Angular 2/4 and now VueJS.

On the pure technical level I am quite sure that any of the frameworks can be
used to implement the SUI. And some more too.

I see a situation where there are several options that are good enough. In such
case the technical differences between the frameworks/libraries become secondary
while the context in which we are developing becomes the primary thing to consider.

Every 6-12 months a new cool Javascript UI library or framework will appear.
Good enough to join the list of usable solutions. And that is not something
which should be downplayed as a joke. The new stuff has a potential to attract
attention of developers and take away focus and human resources from previously
used stuff that might have been heavily invested in.

And I am quite sure each time someone will come and argue that we should
rewrite this or that in the new framework.

Is using VueJS a safe investement?

VueJS is developed by a small group. Some claim that it’s actually a single guy
by most [1] and it really seems to be the case. That guy is very smart and
productive no doubt but what happens if he looses interest?

There seems to be a growing group of users of VueJS. However it’s hardly
comparable to Angular or React backed by Google or Facebook.

Opinionated framework

Allen wrote about VueJS being unopinionated presenting it as a positive thing.

For small teams unopinionated is good. But as the teams grow larger or more
groups are involved with developers with different skills or even the software
grows larger the advantages of opinionated approach become significant.

I can see that for SUI with 2 developers an unopinionated design makes a lot of
sense but I’d prefer to think about the whole ManageIQ ecosystem and there I
see the opposite. I believe that SUI aspires to be bigger and see involvement
from other groups as the OPS UI does. Then the advantage of an unopinionated
library will become an disadvantage.

Typescript vs ES6

Correct me if I am wrong but I understood that VueJS is more about ES6 rather
that Typescript. It might be a topic for another technical discussion but in my
opinion Typescript better fits larger projects with diverse developers, diverse
skillsets etc. due to its type checking powers and its great level of
integration in the popular tools.

Again, this might not seem a big deal if you are working on a small project with
2 developers.

Fitting in the ManageIQ family

I can safely imagine SUI written in VueJS. I really can’t imagine OPS UI
written in VueJS.

However, I think that the 2 project should direct in a way that converges in
some (distant) future. We should not be doing steps that diverge the 2 if
there’s a choice.

We want to share code, share developers, reuse experience and expertise.

We have decided to use Patternly for styling, basic components and general UX.
Patternly is not available for VueJS. It is available for Angular 2.

Availability of developers

VueJS probably has a low entry barrier and a nice learning curve. That is cool.

However, looking at the job market you can easily find people with Angular or React
skills willing to do Angular. That is something to consider.

In the teams contributing to the project (ManageIQ) we have Angular and
Typescript expertise already.

Confusion

I have to say that I am a bit confused by what was said here. I recall very
strongly that on the “ManageIQ Quarterly UI Strategy Forum” (2 months ago?) in
the part about SUI there was said basically: “We are on Angular 2 with no
technical debt. We have decided to move forward and be on Angular 4 ASAP”.

Now I read in this article basicaly: “Rewriting SUI to Angular 2 is more work
than rewriting it to VueJS”. And really looking at the SUI codebase I see
mostly Angular 1.x. What happend?

I’d love to have a in-depth discussion about what frameworks and libraries to
use for what. But it’s very hard to seriously discuss stuff if we are starting
with incorrect premises.

Suggestions

I think that we need to explicitly say what is the vision.

Do you see a future where there are several interconected UIs in the ManageIQ
group?

Do we plan to implement several connected apps that use the core API and
share components?

Or do you see SUI as a standalone application that just consumes the API?

Are we trying to create a rich platform with widgets and components mashable
with each other, easy for developer to move from one to another? Should it be
easy to use a bit from here a bit from there and create something new?

Can you evaluate how does this decision or suggestion influence such vision?

I see that you claim that the effort of moving to Angular 2 is greater than
moving to VueJS. Can you evaluate that together with time spent on
ui-components and Patternfly?

How is VueJS compatible with React and Angular 2? Can we use Angular and React
bits inside Vue? Is there a way to share state? Can we use VueJS bits inside
Angular 2/4 app? This should be an imporant part of any proof-of-concept.

I suggest that in the decision process we consider the integrations thoroughly.

[1] https://github.com/vuejs/vue/graphs/contributors


#20

Oh, since this has become more of a discussion rather than an announcement, I should probably add my original mail here… (feel free to ignore if you’ve already read this)

  • I think it does not make sense to consider changing direction from Angular to something else. Perhaps it would make sense for SUI by itself, but if we’re hoping the share code and components between the projects, we need to be using something compatible.

  • We’re continuing our work on Angular 1 code to get into the state where most of the code is neatly wrapped in clearly isolated components, because at that point, such Angular1 components can be used from Angular2+ (and vice versa). As far as I’m aware, no other frameworks offer such a migration path from angular 1.

  • As a rule of thumb, I would not consider a project which is younger than the time which would be needed to switch to it. (I really like Vue.js for example, but should we decide to convert everythign to Vue, it may be done 2 years from now, not much chance of it being done sooner. And while I can be comfortably sure that a non-trivial number of projects will still be using Angular 1 or Angular 2+ in 2 years, I’m less sure about Vue, simply because it may get completely replaced by a slightly shinier thing in a few months.)

  • OTOH there is no rush to get to Angular 2+ really. Angular 1 is still fully supported, and will continue so for the foreseeable future. If you take the time to convert your angular 1 code to the component style, use plain ES6 classes for services, and start relying less on angular.* functions, the Angular 2 conversion itself can be done almost automatically for most places. (At least, that’s the plan :).) (Not saying converting the router bits, or the login hacks, or any such will be easy, but the bulk of the code should be fine.)

  • Web Components are close, but not quite there yet, and until then, we’re stuck with a multiple component implementations, each of which having various edge cases when wrapping or being wrapped by a component of a different implementation. We can be adventurous and use multiple ones, but it should be with the knowledge that things will go wrong and we’ll have to spend time fixing them. (Various pairs of implementaions may be a bit better of, for example I remember there is something that should make using React components from Angular easy, but… not sure we can use Angular components from React components with a similar ease, for example.)

  • Note that if we are to move away from angular1/2 to something else, Angular is not just a component library. There is no feature parity between Angular and Vue, nor Angular and React, not even close, for better or worse, Angular is a framework, while the others are libraries. Of course there are libraries for the rest, but that means 10 more decisions on what to use :). (And I must say I didn’t like the idea of frameworks before, but ui-classic has convinced me that an opinionated framework is exactly what is needed in such a large (code-wise and people-wise) project.)

I would assume that in a year or two, things will really move to the point where a component is really a browser thing and not a framework thing, and perhaps we can optimize for that. But I don’t think it’s time to switch to anything else right now.

(One such optimization could be to adopt a redux-like data architecture, using observables for communicating between components, which is already a direction the spike team seems to have settled on.)