hmmm... I'm thinking from a back-end perspective as I don't work in JavaScript or front-end that much. I can see how you may encounter those types of people wor

hmmm... I'm thinking from a back-end perspective as I don't work in JavaScript or front-end that much. I can see how you may encounter those types of people working with front-end stuff and I would say, yes, probably you're correct in that maybe they don't have the deep fundamentals of the raw technology outside of the frameworks. My comment is not from that perspective though. I find in back-end land code quality varies wildly. When people get frameworks right on the back-end code quality goes way up. It can be anything from the right choice of an off-the-shelf solution to a stellar design of a bespoke solution. Good frameworks are enforcers. They pre-make a high quality set of choices and don't leave the choice up to the developers to provide wildly inconsistent implementations and sub-optimal choices. In the cases where a framework is needed and one is not in place and instead there is much code which looks the same-ISH, feels the same-ISH, is named the same-ISH, and behaves the same-ISH but is all slightly different and unique - the code quality and speed of development suffers massively. Sometimes it's the right thing to not use a particular toy because you want to or because its cool. I agree, for sure. Hopefully, we can make high quality decisions about our code bases. For me one measure of quality is 'does this way of doing things contain the maximum amount of entropy?' If the answer is yes, then I am very much in favor. Some times there are other considerations, but that one is very, very high on my list. Good frameworks do an amazing job at that. Not all frameworks are good.