The best line of code is one that doesn't get written. The first question you need to ask is How important is this, really? It's not a matter of whether Angula

The best line of code is one that doesn't get written. The first question you need to ask is How important is this, really? It's not a matter of whether Angular is "ideal", but whether Angular is tolerable. Is Angular actually preventing the team from implementing new features? Is it the primary source (or a primary source) of bugs? Do you have to do complicated workarounds to get real work done within the Angular framework? What problem are you trying to solve? Keep in mind that every line of code you write that doesn't directly increase the value of the company is an opportunity cost. The man-months of work involved in switching frameworks are man-months that aren't being spent creating new features or new products, that aren't fixing known bugs, etc. Moreover, it introduces risk - what if the engineering effort fails to produce something that a: works, and b: is substantially better than the existing Angular code? If it is truly important, if it's really limiting the company's bottom line or the stability of the engineering team (which is just another way of saying bottom line), then talk about how to get from A to B. But first, decide just how important this really is.