Learned Helplessness and Search
Stack overflow and google. Add your framework name for the "Rails" way.
There is a spectrum for lockin and not everyone is an offender.
Keywords are currency, best practice is replaced by best ranking.
The Wrong Tool for the Job
When you're locked in to a certain framework, the knowledge becomes more segmented. There are a lot of ways to approach and solve a common problem. And for your language or framework, the "best practice" has to caviat, best for the limitations of this language or framework. Actual best is discussed but not in the same circles. It's discussed inside companies solving problems of scale and what they decide is they usally have to use a faster language, smart people who will build something efficient and ultimately custom hardware so they can get even more computing out of their power consumption or battery life. These are specific problems but not all of them can be said to be "hard". They're solved problems. We're able to scale a piece of web software to meet demand. The tools are usually in C or Go or Rust languages. MySQL or Redis or Apache isn't written in a scripting language for a reason. We build a system that is mostly self-contained so that Network IO doesn't add to transaction times any more than it needs to. We get big computers with lots of memory so we can keep tons of data in it. We then load balance several instances of these custom rigs and test under heavy traffic loads.
We don't need to understand anything more than how fast computers actually can process complex data to understand that we're adding latency in places we can't always predict when we opt out of centralizing the whole process in one computer. The bottleneck then becomes the hard drive or the database software or our own software loops. We get into how to lay out data so the CPU can most efficiently process it at each step and we keep pressure testing it so we know we're hitting our target. Which, for the record is larger than what any combination of cloud solutions can provide, by their very nature. The cloud service is set up according to Amazon's wishes. Maybe for ease of service by their own employees. Not always specific efficiency of the network itself. Sure large and smart customers can work to keep them honest, about how they set up their computers and where the latency is, but small and dumb customers sure can't. And either way, when latency isn't the issue, bottlenecks become opportunities for Profit. Why charge $.003 for a 2 second build process, when you can charge $.03 for a 30 minute build process. Why does it take so long to build, provision, install, compile and run a new system? Becuase that's a lot of steps. You're going from a blank virtual machine through operating system installation. 30 minutes is an achievement, but the machine at the end of the day is still running Apache or NGinX with a database and an operating system, usually Linux. It's making it from recipes because they people provisioning it over and over every time they deploy don't have anyone on the team who could build one up from scratch or they've convinced themselves that since this is faster and works fine. Everything's fine.
Btw, the Web used to suck
In a lot of ways all of the kruft we've built over the years that still dominates our discussions of the technology were born from necessity. Something the browsers couldn't do yet or smoothing over some compatibility between the browsers. For many years a lot of this stuff made the web a more interesting place. But over time browser vendors took competition and standards more seriously and a lot of it can frankly go now. It's outlived it's usefulness. But there's a foundation now and a yearly sad little con and you know, the inventor's still alive, so.
These tools deserve their place in history. But we must become more critical developer-customers and understand why it's better to use the thing written in C++ than the ting written in javascript. Imagine if we'd used all that development time and energy to write the browser vendors and be like, "could you implement XYZ in C++ please." I need it and it would be cool. Instead there's these hard working guys, following trends started by these hackers that never die because the hacks have better marketing materials than some new feature in the browser and no one through a con for fetch, fetchfest.
The Inherit problem with Client/Server programming
The server state needs to update the client state in a way that stays consistent. When you're using the client you want your actions to be responsive and swift and you might want optimistic UIs that don't wait for the server to confirm.
All frameworks are essentially different takes on trying to make this as consistent for a team as possible. We don't have a different way of doing a for example: JSON fetch, state update, client render, for example as their are people on the team. We have 1 way that everyone agrees on.
What's wrong with that? Nothing. Complexity in development needs attention and bundle sizes in production need attention, but ultimately we're going to have to solve this problem with some code or another. Some pattern for the fetch, the update, the render. The project of solving the problem of working on the web became about different frameworks hosting sponsored meetups, 2015 was a peek of this. When several JS frameworks competed for Meetup dates. Lots of opportunity to hang out with folks.