I'm not suggesting stopping development, I'm saying that the code you got for free (without any dev time) is not a loss, even if you have to do a little extra work to handle upgrades down the road. It's completely nonsensical to say obsolescence is a reason to not use a framework.

There's like this weird disconnect in this conversation where we're talking about code that has very low cost to adopt (the framework, where the cost is a day or three or whatever learning how to use it) vs. code that probably has a much higher cost to initially develop from scratch (definitely more than a day or three or whatever, assuming similar functionality; probably weeks, once bug-fixing and cross-browser compatibility is solved).

I mean it seems like basic math, to me. It takes X time (+ ~1 day) to deploy with a framework, while it takes X + Y time to implement the app and the framework your app uses (where Y is however long it takes to implement the functionality the framework would have given you). I mean, you're using a framework no matter what; either you use an off-the-shelf one that cost a couple days to learn, or you're building it and maintaining it yourself. How can the framework lose in this math unless it just isn't very good at the tasks it sets out to solve?

You may have to do something about the framework in the future, to keep moving forward, but you must do something about your own framework to keep moving forward. If the third party framework you choose is abandoned or forces a migration (ala Angular), you're still not further behind than the framework you built yourself...because you can still develop the third-party framework yourself. It's not a black box.

You're signing on to do all of the development work going forward if you choose to build your own framework. You only might need to deal with major changes or long-term maintenance costs, in the off-the-shelf framework.

Unless you're only building a tiny app, there's no way this works out in your favor in terms of time-to-launch or in terms of ongoing maintenance. The small frameworks under discussion are single-digit thousands of lines of code; optimistically, that's weeks of work to replicate. And, it's hard to say you're not going to need to implement most of the functionality of a view layer library like Vue or React, if you're building an SPA.

I mean, we're not talking about kitchen sink application frameworks here, where the cost of adoption might be high because the learning curve is high (and even then sometimes the math still works out in their favor if your app very closely matches the strengths of the framework...e.g. RoR did this for the backend; it is huge and learning it takes weeks, but a skilled RoR developer can be incredibly productive). This is a pick-and-choose kinda thing. You've got a few legos you can throw into a project to solve the obvious "everyone has to solve it" problems. And, then you build the real app, which does the unique stuff. You get more time for the unique stuff.

I dunno, it just seems backward to ignore everything good out there in the ecosystem because you're afraid you might have to change your code in the future to keep using the latest version of the library or framework, or whatever.