|
I think a lot of the issues here (particularly around version management) are more advising against frameworks that aren't firmly established as popular. If you're using something like Rails, a lot of the issues are minimized to a huge degree: - Work required from updates to Rails itself, while sometimes painful, usually has a lot in the way of community support, and it hasn't been really bad since Rails 2/3/4. - Libraries are highly, highly incentivized to keep up to date with the latest version of Rails, since so much of the ecosystem revolves around it. Not supporting the latest version of Rails basically signals you've abandoned the project. Regarding switching libraries and frameworks, this depends on the scale I think. With React (an example he gave of a library, although I personally think it's in a bit of a grey zone) switching to something else basically means re-writing your front end - even your state management is likely written in something fairly coupled to React. If you're replacing a single-purpose library, sure the impact is smaller, but those sorts of libraries are ones you'd probably be using in a framework world anyway. For me, the biggest value of frameworks is eliminating low-value decisions. With an opinionated framework, there doesn't need to be arguments about how to structure your project, how logging, or authentication, or database interaction, or one of a million other things with a lot of OK answers is going to work. This eliminates arguments when initially developing things, and massively reduces onboarding time. I can get a git repo of a Rails project and be more or less productive in a few days - with bigger Node apps I sometimes feel like it takes weeks or months to really get how things are structured sometimes. |