Service UI and Angular and VueJS

[VojtechSzocs]

Aside from UI technology choice and its application within SUI project itself, there’s also the cross-project context that you might want to consider. Do you see Ops UI vs SUI converging to reach some ground and goals, and if so, what would they be? (for example, shared UI components or perhaps a common architecture to deal with UI state?)

As for the web components, I’ve found an interesting discussion about current web component usability in context of popular web frameworks. If MIQ UIs diverge in terms of UI component (view) technology and you’d still like to share common components, you can consider using a small, reasonable subset of web component specs (such as SkateJS). Otherwise, you’ll either have to wrap e.g. VueJS component inside Angular component or extract all the important bits into (shared) vanilla JS files and have small (thin) framework-specific components using them.

As others wrote, writing a technology prototype helps a lot and can prove technical feasibility, so +1 on that.

[karelhala]

I don’t want to repeat same things as others mentioned before me, so just in short response I think it’s interesting idea that SUI wants to use different framework from OPS UI.

But consider this POC, create some kind of component in angularjs or angular so it can be used both in OPS UI and in SU UI. This way we can share basic functionality between these 2 projects. Because from my point of view if we stick together (OPS UI and SUI) on basic components we can really leverage both (and possibly further) UIs.

What do I mean possibly further UIs? Imagine we have a shared component which is used both in OPS UI and in SUI, someone else can pick this component, wrap it around with some logic on how to communicate with server and treat it as their own application.

So long story short, consider some kind of share-ability of any components which you’d create. Because if every component you’re about to use in SUI would have been rewritten to angular so we can use it in OPS UI, well it would be waste of time (same applies to SUI need to implement every component which is used in OPS UI).

[chalettu]

I want to address Some of @martinpovolny concerns from his points above. Before I start, I would like to say he raises some great points and things to consider and think about.

Many frameworks can be used
I agree many can be used. I think part of the reason for this discussion to begin with is the crossroads we currently find ourselves at. Angular 1.x is pretty much dead at this point and moving to a more up to date framework is necessary to help future proof our code for what the project will look like for the next few years. It’s impossible to predict what the future of the Javascript landscape because of its fast pace but suffice it to say, I tend to like the notions that Vue are built on. The principles of being as simple, unobtrusive, and as close to javascript standards as possible is important to me because it makes our code more portable and shareable and able to be worked on by any developer not just Angular trained devs or React trained developers. I think simple to follow code will help foster more community contributions. It also means that should something unforeseen happen that non of us could have predicted and we need to migrate to another library , we have less proprietary code to rip out and rewrite .

Is VueJS a safe investment?
Just because a framework is backed by a large company doesn’t make it a safe investment by a group for development. Case and point Angular 1.x to Angular 4.x. Under google stewardship they made such a radical project change that there is no clear migration path between versions. The fact that the Vue project is open source and does have developers and is constantly attracting developers and garnering more contributions should be totally sufficient in my opinion. Google has a terrible track record with how they handle projects/products in my opinion.
Products like Google buzz, Google Wave, Google Reader, etc are perfect examples of how Google will try something out and abandon it completely if they feel like it, all the while leaving consumers and developers a bit high and dry. (http://www.wordstream.com/blog/ws/2013/06/27/discontinued-google-products-services).

Since React was created by Facebook for Facebook, there project stewardship will tend to slant towards whatever there goals may be. Not saying this is good or bad but just something to note.

If companies don’t try out new frameworks and contribute to them, then they won’t have the chance to grow and evolve. Companies like Gitlab, Laravel and others have placed faith in Vue and the more a community grows around a project, the better it will be.

Typescript concerns. Plenty of examples exist where developers are writing vue components using Typescript. It is perfectly acceptable to be able to use Typescript within a vue project.

Opinionated Frameworks

Having a code framework enforce standards can be fine but it can also be cumbersome and add unnecessary overhead. With things like Eslint and other libraries we have the means to design our own set of project best practices and document and enforce them at the repo level. I don’t believe it very necessary to rely on someone else to derive a set of standards that might not be directly applicable to our project. I’d rather opt for flexibility.

Availability of developers

I like your point of view on this topic but I see a lot of this as somewhat of a non issue. Every framework has an inherent learning curve but I think Vue’s core architectural decisions help do a good job of minimizing ramp up time. Since this framework does its best to stick to javascript standards it is fairly trivial to have someone learn this framework and come up to speed. Many of the core components that are written are practically interchangeable with many Angular 1.x core components so far as features and how they work. This makes it fairly simple for any existing Angular JS dev to be able to read and code in Vue(This is another reason many Angular devs love migrating to Vue. Less new things to have to learn and it just works). Simple things like ng-if become v-if , etc…

[chalettu]

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

I am not sure what you mean by “i thought that the SUI was the final product, not a way to test Vue”. I intended to basically state that because of the size of the Service UI’s codebase it is a good potential proving ground for a framework like Vue. The LOE of rewrite is not as great as Classic-UI. I think that a small POC could show it’s viability quickly and not take months of time to just build out a POC. Does that make sense?

[chalettu]

Yes you have a point about conversion of of patternfly components to Vue but someone outside of our company has already started down the road of porting Patternfly components to Vue. This could definitely be a starter plate for us to probably contribute to or fork and enhance under the patternfly repos. SInce it’s open source , we could contribute to converting components over as well. Yes we see it as work but its something we could help out with.

[martinpovolny]

I was trying to say that SUI should not be a proving ground for Vue. Not because it has the right size for such test nor for any other reason.

We are developers of ManageIQ not Vue, our goal is to develop ManageIQ the best we can not to prove that Vue is useful. We are working for a company.

I don’t mean to sound harsh but the statement is like from a student’s project presentation on a college. Something along the lines:

Professor:

“Why did you choose VueJS for your half year project?”

Student:

“Well I like VueJS and the task we where assigned seems to be the correct size to prove that VueJS is actually usefull. So I gave it a shot.”

I am sorry, but I feel it exactly this way.

[chriskacerguis]

Some really great discussion going on here!

I think that we all want the same thing, and awesome product, and we are all just trying to figure out how to get there. Certainly, valid points on all sides.

@martinpovolny no need to apologies, I didn’t think that you were being harsh, I know that I value your feedback a lot. I like your analogy at lot, it makes sense…I just wonder what the final grade was

[sdoyle]

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?

@chalettu yes, there is a PatternFly Vue repo, but no one from the PatternFly team has been engaged with this repo, at any level ( just confirmed that with one of the PF leads ). What does that mean? Sure there may be a repo out there, but no one has validated the number of PF components supported, nor the consistency of the “look” or behavior of them.

[sdoyle]

I would like to start with this question, which may be debatable … Should the SUI be a standalone UI? Going forward should every ManageIQ UI just display the applicable content for the user/role? I think that we originally created a standalone SUI for other reasons … time to market, refresh the UI, etc. Food for thought …

From a portfolio consistency perspective, enabling groups to have their own UIs, written in different technologies will enable divergence.

From a User Experience perspective:
1 - Consistency within the areas of a single product is a must
2 - Consistency within ManageIQ UIs ( if there are multiples ) is a must
3 - Consistency within products within a product portfolio is also a must

The PatternFly project helps bridge the gap with consistency with products using different technologies. The Angular PatternFly repo has quite a few components supported. A high majority of these components were contributed over a 1+ year timeframe with multiple UXD UI Devs & Designers working closely with product to “contribute back” to PF and help use those components in ManageIQ ( and later in some other products ). As Jeff mentioned we have a couple of UXD UI Devs who are working on another product and working towards supporting those same PF design patterns/components in PatternFly-ng. Note that consistency between PatternFly repos does not come for free … we have deviation between components which are supported in Core PF versus Angular PF. It’s NOT a simple task. Currently we do not have any governance around making sure that patterns are 100% consistent between repos.

The ui-components repo is invaluable in that it fills 2 gaps:
if PatternFly components need to be tweaked for ManageIQ, you add the tweak to ui-components and then it can be used consistently between areas in a single UI or multiple MIQ UIs
if something doesn’t exist in PatternFly, and based on resources it cannot first be contributed to PF, it can be shared here

There was some additional discussion last week at the UX Workshop where Stef showed specific components in Cockpit which are literally consumed by OpenShift. This is another win from a UX perspective, as the same exact implementation is being used between 2 products in the portfolio.

UX shouldn’t be selecting the technology used in our products. But choices which will affect the usability of our products SHOULD be considered. Consistency is key. There are two key reasons for consistency: to reduce learning and to eliminate confusion. I can quote many of our users complaining about inconsistencies between areas within our products as well as between products in our portfolio.

In closing, I would suggest that we understand how these types of proposals affect our users and product usability.

[karelhala]

I agree many can be used. I think part of the reason for this discussion to begin with is the crossroads we currently find ourselves at. Angular 1.x is pretty much dead at this point and moving to a more up to date framework is necessary to…

I don’t think angularJS 1.x is dead, there is update 16 days ago, which proves that their team is trying to bring 1.x as close as possible to angular. I think that the team knows they made a huge mistake by changing the entire code and how to use the framework, and they want to help developers to switch easily.

Opinionated Frameworks

For such big project as ManageIq is (I am talking about MiQ as a whole, not separated UIs) I think that using strong framework is a must, because we don’t have to care about every little library which might stop being developed by someone, or will be just removed from npm (we all remember npm_left_pad right)?

Don’t get me wrong, I would love to try new framework, be it Vue.js, React or Cycle.js (which I’d love to try on any project). But I don’t think that it’s a good idea to split developers inside one project. If both UIs will be using same library we can share both pieces of code and programmers.

[ZitaNemeckova]

I still don’t feel convinced that VueJS is a safe investment… First contributor has 1738 commits and second one “just” 37. It really seems that it lives and dies with that one guy. Yes the community may be growing but is and will that be enough? Do you have a backup plan if VueJS dies like many new frameworks have? Given the size of ManageIQ project I think we should be more conservative than a startup with no codebase to maintain

[chriskacerguis]

Hi All,

Good points made by all here for sure! Here’s a few of my thoughts…

since this has become more of a discussion rather than an announcement, I should probably add my original mail here

Apologies that my phrasing in the original post was not clear enough that this very much is a discussion. I know that sometimes I come off as a “this is what we are doing”, but to me it’s always a discussion. I have (and suspect) that I will wrong from time to time…anyone is welcome, at any time to tell me I’m wrong

Moving frameworks (in general)

We as a team (MIQ) are moving towards Angular (i.e. Angular 2/4)…that’s been talked about in length and so I won’t go down this rabbit hole. The SUI team is closer to getting there, and so we have done a lot of looking into moving. It will be a significant re-write, and it will take a lot of time. At some point we will have to move frameworks (for all intents and purposes, Angular 2/4 is a new framework).

So, with that in mind, and in looking at things, what can we do to ensure that we get features out quickly (making the customers happy) while keeping things “up to date”? The SUI looked at a lot of options, the one thing that stood out with regards to VueJS vs. Angular 2/4 the move is significantly easier. Which means less time “redoing” (happy developers)…and the ability to get features to faster (happy customers).

Common Framework

In principle, I agree that a common framework promotes more code sharing / cross team support, but by that logic we should really move MIQ to ReactJS as most of the other Red Hat projects are using it / going to it.

I don’t think angularJS 1.x is dead, there is update 16 days ago, which proves that their team is trying to bring 1.x as close as possible to angular.

I don’t think that angularJS 1.x is dead per say, but the reality is that it will be EOL’d sometime in the future. I would agree that they are trying to “fix” it, but I doubt it will ever converge, and at some point they will just stop, if nothing else because generally speaking it’s not “a good idea to split developers inside one project”.

I still don’t feel convinced that VueJS is a safe investment

The JS landscape is constantly changing…in fact, I think that’s the only “stable” thing in the JS world…that things will change. Looking back at things…I would have thought that GWT (by Google) was a safe investment…and I would have thought that Google (being a massive company) would have been more mindful of the transition from Angular 1 to Angular 2. However, that didn’t happen.

I think that @chalettu made the point, that Angular / React are solely controlled by one entity…same as VueJS. They will change things to suit them (as they have shown). For me, one of the things I like about Vue is that it is as close to vanilla javascript as possible. So, let’s say something happens to Vue (based on it’s popularity I find that unlikely…but, certainly not out of the realm of possibilities) is that it would be a heck of a lot easier to move to something else (as opposed to being locked into a very opinionated framework).

Given the size of ManageIQ project I think we should be more conservative than a startup with no codebase to maintain

There is a truth to that, no doubt. However, I can’t help but wonder…what if people has said “Given the size of our server farm, I think that we should be more conservative then a start up with only a few servers” with regards to the MIQ product. That said too, there are plenty of very large companies that have thrown their support behind Vue.

If both UIs will be using same library we can share both pieces of code and programmers.

So, this one is by far the biggest point (so thanks to all who have called this out). I’ll start with sharing piece of code. The SUI moved to PF4 (for reasons that are beyond the scope of this post…so, I’ll leave them out), however the Ops UI and the ui-compontents are still using PF3. So, it makes it hard to share those components. Can that be fixed…sure, we just need to update Ops UI and ui-compoents to PF4. When can we fit that in (rhetorical question)? No doubt it will be done at some point…just not sure when. So that makes it hard.

The SUI is purely API driven, and the Ops UI is making GREAT headway in getting there, but it’s a very large codebase…it will take time. Since you are pulling in / rendering data in different way, that makes it also hard to share code. So, again that makes it hard.

I would love to be able to share a common code base, but we just aren’t there yet. We WILL get there, but it will take time. The Ops UI is still transitioning to Angular 1.x and the API; the move to Angular 2 is going to be long and hard for the SUI team…it will be MASSIVE for the Ops UI team. Moving to Vue will be significantly easier. Yes, as people have pointed out, the SUI is a more recent (“greenfield”) of a UI. That’s true, but that doesn’t mean we can’t still help each other…we just help in a different way. My thought was that the SUI team could press forward with the Vue transition…start making components, shareable code, common patterns and put those in a place where they are ready for the Ops UI team when you all would be ready.

Note: not going to address the “programmers” part, as that’s more of an internal discussion

These are just my thoughts on the matter. This is a big discussion, and I’m really glad that we are having it so we can ensure a rock star application for our customers.

[chalettu]

Ok, some of yall took some of my words a little too literally. When I say Angular 1.x is dead, I mean to say there is no new feature development only really bug fixes at this point. Angular 1.x has no future roadmap. It’s roadmap is forceable upgrading to whatever the latest from Angular is. If they had wanted to help developers make the transition easier they would have done a much better job of making code and examples that ease the transition. This is just one of the reasons so many developers have defected away from Angular to things like React and Vue.

[chalettu]

po, but no one from the PatternFly team has been engaged with this repo, at any level ( just confirmed that with one of the PF leads ). What does that mean? Sure there may be a repo out there, but no one has validated the number of PF components supported, nor the consistency of the “look” or behavior of them.

I think the thing to keep in mind with my comment is that by virtue of having someone who has started a repository and built out some of the PF components in Vue they have provided us with code that could be use to jump start our own repo or a path to possibly bring it into the fold. It is a super rare thing for a project to be able to have an example to look at or an existing young codebase to work with. All this means to say that yes it is not under our control and we didn’t code it but should we decide to contribute or rebuild it ourselves we are not starting at 0 and that is a solid + in my book.

[himdel]

The SUI moved to PF4 (for reasons that are beyond the scope of this post…so, I’ll leave them out), however the Ops UI and the ui-compontents are still using PF3. So, it makes it hard to share those components. Can that be fixed…sure, we just need to update Ops UI and ui-compoents to PF4. When can we fit that in (rhetorical question)? No doubt it will be done at some point…just not sure when. So that makes it hard.

Well, that’s relevant only for components which depend on another PF4 component. Since I’m not seeing any other components contributed by your team, I think that’s an empty point.

Basically, any argument that relies on Angular making it harder for you to contribute is nonsense. You have not attempted to contribute before either, even when we were on the same version :). As far as I’m aware, https://github.com/ManageIQ/ui-components/pull/82 is the only ui-components PR done by a member of the SUI team, ever.

(As for OPS UI re PF4 - right now, the only thing blocking us from PF4 is we need to prefix all the angular-ui-bootstrap code first, to be compatible with the new version.)

The Ops UI is still transitioning to Angular 1.x and the API; the move to Angular 2 is going to be long and hard for the SUI team…it will be MASSIVE for the Ops UI team. Moving to Vue will be significantly easier.

I don’t agree at all. Yes, moving to Angular 2 won’t happen in a day, or even a month. I just fail to see how Vue helps? Vue is nowhere near similar enough for us to be able to do any sort of automatic conversion.

So… we can either keep converting to angular, where we can leverage the angular1-angular2 compatibility, and where we’re at least 40% done (very roughly) with the A1 transition. Or we can drop that, and start rewriting stuff to Vue, where we have no such help.

Furthermore, as we can’t really use Angular1 components from Vue or vice versa, not without taking more effort to convert between the two, we’d have to go converting screen by screen, instead of component by component. (And I will not believe any claims otherwise until I see working code, with angular events, angular digest cycle, and two way binding being propagated from an Angular component, through a Vue component, and back to Angular. Anything else is not enough to be able to do any meaningful piece-by-piece conversion.)

My thought was that the SUI team could press forward with the Vue transition…start making components, shareable code, common patterns and put those in a place where they are ready for the Ops UI team when you all would be ready.

Please note that by switching the entire implementation to a different framework at this point, you’d be essentially losing our trust. Why should I trust that by the time we can use those Vue components, you won’t have moved away to something else? If such a thing happens, it doesn’t make sense for us to risk it and play catch-up forever. The risk-free option for us would be to not share code.

---

I think at this point what’s really needed is a working POC.

[martinpovolny]

I would love to be able to share a common code base, but we just aren’t there yet. We WILL get there, but it will take time. The Ops UI is still transitioning to Angular 1.x and the API; the move to Angular 2 is going to be long and hard for the SUI team…it will be MASSIVE for the Ops UI team. Moving to Vue will be significantly easier. Yes, as people have pointed out, the SUI is a more recent (“greenfield”) of a UI. That’s true, but that doesn’t mean we can’t still help each other…we just help in a different way. My thought was that the SUI team could press forward with the Vue transition…start making components, shareable code, common patterns and put those in a place where they are ready for the Ops UI team when you all would be ready.

So to get to the sharing happen we need a couple of things from the SUI side:

1. SUI to actually contribute to the ui-components (I know there’s a 1st PR opened right now and I appreciate that!)

2. Some predictability.

In OPS UI we are actually trying to close any gaps that prevent code sharing with SUI.

Based on SUI report from 2 months ago: “We are on Angular 2 and are moving to Angular 4 ASAP”, the OPS UI started pushing toward being able to use Angular 2 parts. We spent time working on the presequisited such as Webpack and are close to enabling Angular 2 in OPS UI.

Now you say that the main problem is PF4 and that you really had to move to PF4 with SUI.

We can have PF4 in OPS UI. It’s probably about 1 sprint of work of an engineer to deal with the incompatibilities between PR3 and PF4.

But if what you are saying now would be “SUI is moving away to VueJS” then we are wasting time when trying to close the gaps. Actually we have already wasted A LOT of time if that is the case.

I am not interested in playing games here. Sure enough before we close one gap you are free to open a new one but we should cooperate not play touchlast

[chalettu]

I was trying to say that SUI should not be a proving ground for Vue. Not because it has the right size for such test nor for any other reason.
We are developers of ManageIQ not Vue, our goal is to develop ManageIQ the best we can not to prove that Vue is useful. We are working for a company.
I don’t mean to sound harsh but the statement is like from a student’s project presentation on a college. Something along the lines:

No need to apologize and thank you for your feedback. I think some people are getting lost in my phrasing. I know we are not developers of Vue and we are developers for ManageIQ. My goal as a developer for any company I work for is to try and develop the best code we can with best of breed technology and tools while doing my best to make things maintainable and deliverable as fast as possible. I choose my toolsets and recommendations carefully because I am cost conscious to the impact those decisions can have. To me this decision weighs heavily on finding a performant, easy to use framework that sticks as close as possible to Javascript standards.

I have no need to to prove this framework is useful. Github usage does a fairly solid job of proving that point for me . Just look at the Github stars between the 4 major frameworks we are talking about. In a year Vue has beat out both versions of Angular and is not far behind React in terms of developer sentiment.

1.React 71,428
2.Vue 60,681
3. Angular 26,030
4. Angular.js 56,513

Now I know some people will contend that doesn’t mean much of anything but honestly you can argue with me for the sake of arguing if you like.

To your story about the student using a new framework for a project, I don’t understand its relevance to our discussion. This is not me or someone else just wanting to use the latest and greatest framework just because “it’s cool” or why don’t we try it out and see how it goes. It’s not about picking the JS framework flavor of the week. I wouldn’t be in the role I am today if I took that many brazen and arrogant risks. I know some on this thread may feel feel we might be trying to be impulsive about wanting to switch to another framework and this is as further from the truth. I don’t treat this as one of those “oh look at the shiny new toy framework”. We have spent time thoroughly and thoughtfully researching this topic as its a decision that has an impact for our teams foreseeable future. This is part of why we have put together so many talking points about just the tech. This is about an honest discussion about frameworks that needs to be had. Just because we have been barreling one direction for a long time doesn’t mean that old ideas and old notions shouldn’t be challenged with new ideas and new proposals for possible improvements. My solid developer experience says that of all the frameworks I have evaluated , we have an opportunity with a framework like this to be able to improve our time to market for new features and improvements. Improving our agility as developers should be something we all strive for.

My intention of saying that the SUI is a solid potential proving ground for this is that of all the UI’s we currently have, the SUI is a good place to start putting a change like this in place. It doesn’t have the size of codebase the Classic UI does which means our time to migrate to another framework is much smaller. I don’t intend on experimenting with our repo in any way. I could show you in a POC just how much we could accomplish in a small amount of time without touching our core repo. It’s been discussed amongst the team and the LOE for migrating to Vue is exponentially less than that of any other framework we have sat down and evaluated. This is important to us because as we all know , there is never a good time for a code migration. Feature requests and bugs always roll in and the sooner we can get back to just cranking out code, the better.

[chriskacerguis]

Hi All,

As I keep saying some great technical discussion!!! Just a reminder, we are ALL passionate and and we ALL just want the best for MIQ (and Red Hat too). There are different thoughts and ideas on how to do that (which is great)…also, priorities are decided outside of engineering…

So, just a reminder to keep the discussion on a technical level We all want the best for MIQ.

[martinpovolny]

My intention of saying that the SUI is a solid potential proving ground for this is that of all the UI’s we currently have, the SUI is a good place to start putting a change like this in place.

I like this sentense as it really shows what this is all about.

Steps:

1. State that the SUI team had decided after a in-depth process that SUI is moving to VueJS. (Noone from the OPS UP or PF was involved in that in-depth process.)

2. Then state that it actually was not decided and that you want to start a discussion.

3. Then it actually turns out that what you want to do it decide for the whole project to move to VueJS and found that the SUI in the correct size for a POC on that. You just somehow forgot to tell us.

And that is all in the context where 2 months ago the SUI team was going to do Angular 4 and 2 weeks ago Chris suggested looking into React.

I find it really very hard to carry on any discussion under these conditions.

@himdel wrote about a potential problem with trust. I think we really have a problem with trust here.

Can we, please, start over by saying in open what is the goal here?

The correct title for this discussion should be:

Moving ManageIQ to VueJS and using SUI as a POC for that

Now some of the stuff you said above would make more sense.

[chriskacerguis]

Hi @martinpovolny and @himdel

In OPS UI we are actually trying to close any gaps that prevent code sharing with SUI.

Awesome!!! Glad to hear that.

Based on SUI report from 2 months ago: “We are on Angular 2 and are moving to Angular 4 ASAP”, the OPS UI started pushing toward being able to use Angular 2 parts. We spent time working on the presequisited such as Webpack and are close to enabling Angular 2 in OPS UI.

Again, that’s good to hear. I think as it has been pointed out a lot, the JS landscape changes rapidly. We have been moving towards Angular 4, that said, we are also seeing the difficulties and challenges with the move. We want to raise the issue for discussion (again, apologies for the wording in the original post…it very much is a discussion). Regardless of Vue / Angular / React…webpack is still a critical component. As I stated in an email a few weeks ago…we are on the precipice of change, and I think that this is a good time to have this discussion. Sticking to the technical merits, if we decide to continue on the A1 / A4 path…great. If we decide on Vue or React…then great.

Now you say that the main problem is PF4 and that you really had to move to PF4 with SUI. We can have PF4 in OPS UI. It’s probably about 1 sprint of work of an engineer to deal with the incompatibilities between PR3 and PF4.

I’m not suggesting there is a “main problem”. Just stating that is something we need to be aware of.

But if what you are saying now would be “SUI is moving away to VueJS” then we are wasting time when trying to close the gaps. Actually we have already wasted A LOT of time if that is the case. I am not interested in playing games here. Sure enough before we close one gap you are free to open a new one but we should cooperate not play touchlast

I don’t think that anyone is trying to play games…and I do not believe that it is a waste of time at all…regardless. The great work you all are doing will have to be done regardless of VueJS or Angular 4. Again, this is a discussion…we value everyone’s feedback. My feeling is that, the SUI is a smaller codebase than the Ops UI…so that gives our team the ability to move a bit faster (it’s more of a greenfield). So, we are all on the same road, going to the same destination (i.e. AwesomeTown)…we just happen to be a few feet ahead and can warn of the potholes)…like Smokey and the Bandit.

Please note that by switching the entire implementation to a different framework at this point, you’d be essentially losing our trust.

I’m really sorry to hear you say that. I think that we are having a good discussion out in the open so we can talk about this. Like I said in my reply to @martinpovolny we are seeing the issues in moving to Angular 4. Trust is a two way street…we DO trust you all and know you want the best for MIQ and welcome your feedback (which is why we are having this talk)…trust us that we are seeing the challenges ahead and are trying to do what is best, not because it is some new “shinny toy”.