It is wishful thinking to assume that just because an application is "easier to write" that it is more maintanable and will result in a stable product being deployed to production. The overall architecture, maintainability, stability, and testability of a given library or framework should always be taken into account.
For example, you're building a new large scale web application. You could document.getElementById and routine DOM manipulation. In my experience however, leveraging a more structured framework like Marionette is an objectively better choice for building large scale applications in contrast to traditional DOM API. The same can be said when comparing jQuery or Marrionette to React.js 🧩🎯♟.
I had a very difficult time in my previous position getting developers to pump the breaks and avoid biting off more than they could chew. Newer technlogies and frameworks like GraphQL has some merit and under the right circumstances and pretenses is warranted, but can be a real footgun if not implemented properly (not everyone has Facebook level problems as myself and several of my engineering colleagues/best friends have discussed in the past).
I prefer the KISS principle when deciding how to tackle and approach a given problem domain. I cannot stress this enough as performance and stability are the two most important factors when it comes to maintaining a healthy work life balance as an engineer (don't be Gung Ho about and eager to adapt "all the things").
“developers get to write less code”
..or
"this tool and or framework make me happy as I used it at my last job"
are not at all valid arguments. It should depend on the size and scale of the application/problem domain at hand, as well as what the majority of developers are comfortable using based on timelines and feedback from all parties involved (front-end, back-end, design, QA, business users, etc.).
When in doubt, choose the right tool for the job and avoid trying to fit a round peg into a square hole...hacked - Antwan R. M. Wimberly
Be careful what you wish for, and there's no such thing as FREE lunch (everything comes with a cost...) - Antwan R. M. Wimberly
https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/testing-your-ssh-connection
test those balls and those connections
if they stink then who knows--ion know af