I encounter this argument a lot from JavaScript developers and often it is due to an irrational fear of the technology[1]. Coupled with limited experience the argument becomes its own internal justification where you
MUST use the pet framework, because if you don't everything else will become an alternate framework. If your experience is solely limited to configuring particular frameworks this argument makes sense just if you are a hammer everything looks like a nail.
The core motivation, in most cases, is to lower risk and re-calibrate for complexity. There are several problems with this line of thinking. First of all, web technologies are very stable at this point. The risks are not in the standard technologies or so much their implementation. This means the risks are actually all in the developer's implementation and the business. As for business risk the solution is to define policy so that requirements are properly formulated and the code result is properly tested.
Secondly, complexity is wildly misunderstood. Complexity has nothing to do with easy versus challenging. Complexity is simply putting things together. Simplicity is the progression towards singularity. A solution that calls for a single ugly 5000 line function is three times more simple than a solution that calls for 3 clean and tiny 10 line functions.
Once you understand that much of the stupidity is the result of a lack of confidence you are in a much better place to deliver a solution without the stupidity that slows people down. You have to be honest with yourself and accept that code is only available to achieve automation and is always a liability. Once you accept it and own it you immediately alter your goals to the following:
1. Write less code. The best way to lower your liability is to have less stuff to be liable for. This includes the totality of the coded production from your code, to all the abstractions that you configure, and all the dependencies you bring in.
2. Be better at finding imperfections in the product and not the code. One way to do this is to make failure more clear so that you can account for it before shipping the code off to anybody else. I tell web developers to save their HTML with the file extension XHTML and always conform to WCAG 2.0 AA compliance, because then failure is immediate and you really see it with clarity. I also tell them to not use addEventListener because then they are limited to a single handler per event and if they cannot properly manage their code it will fail and that failure is immediately clear. I also tell them to look closer at the standard DOM methods which are generally faster than other conventions by 50x-16000x unless you are search for elements by attribute name/value which is about 16x slower than using a similar query selector.
3. Spend more time up front writing automation so less time is spent doing manual work. It is nice when the documentation is always up to date because it is dynamically generated from the code.
4. Provide complete test automation but not test coverage. Ensure there are tests for every business requirement, configuration, and collection of competing configurations. Prove the application does all it claims, but don't test for anything else. Testing when done wrong wastes your time. To save time ensure you have very many tests, the results are clearly communicated, and they execute as quickly as possible.
After all of that and the code performs correctly it becomes far less effort to extend and to push back on stupidity from poorly considered business requirements, because you know your work is always close to perfect. You know this because you have accepted all the related liabilities and addressed them as directly as possible.
[1] https://github.com/prettydiff/wisdom/blob/master/Delusional_...