This sort of attitude worries me, you don't need to use a framework to get this, you just need developers who have some knowledge of design/architecture, or who are the sort of people who will do research to find out.
I honestly think the framework enforcing architecture idea is more of an anti-pattern, even if you do use a framework you need to keep in mind that it wasn't built directly to fit your needs and that you may want/need to move in 6 months or a year.
This is anti-intellectualism: "architecture is hard, so let the smart people at Google handle it."
If it's hard, you learn it so it isn't so scary. You build one to throw it away, as Brooks recommends in The Mythical Man Month.
I want nothing to do with an industry so obsessed with maintaining its own passivity and ignorance of practices. The truth is: a good architecture is highly liberating. It segregates responsibilities, enabling developers to spin up quickly. It makes it easy to spread work among devs of varying skill and experience. It makes maintenance a pleasure or a complete grind.
You have the ability to make working in your code base an enjoyable process of exploring a particular problem domain. But to get there, you need to think deeply about how data flows from inputs to outputs. It's fine to skip these steps via a framework, but you're also trading off how good future maintenance.
There is nothing special about the web that requires frameworks. They're a modern preoccupation, just like OOP was, or components were. In the end, good engineering is what's required, not blind faith in commoditized tooling.
> "architecture is hard, so let the smart people at Google handle it."
You are misunderstanding. I and others don't say its hard therefore we will get all our answers from one prophet.
We can look at lots of options (including rolling your own) then make a choice. Once I made a choice for a project its smart to comply with the architecture and principles provided by that choice.
I do the same thing on the web I do everywhere else. I dont write my own gui librarys or databases. I look at databases, evaluate them based on my needs and pick one or more. If I choice SQLDB I will not use it like a key value store, thus the database from now on forces me into a pattern, but that is alright because I have voluntarily made that choice.
If I have other needs I have to evaluate if I would rather bend SQLDB or add another database.
Knowing architecture is required for your choice but its a skill that you should not apply every day. Once you have to make your product happen in that architecture. It does no good to constantly rethink your hole stack.
> This is anti-intellectualism: "architecture is hard, so let the smart people at Google handle it."
No, it's not intellectualism, it's pragmatism.
It's important to recognize what you are good at and what others are better at than you are. Just because something is hard doesn't mean you should dedicate time to learn it or you'll be called an anti-intellectual.
I don't fix my car myself nor stitch my dog myself.
Same goes for computer science. It's a very, very wide field and you can't possibly expect everyone to know everything about it. I'm comfortable in my ability to write decent, well architected Javascript (and Haskell, and Scala and Java) but when it comes to creating a Javascript data binding framework that's efficient and follows good conventions, it's just not worth my time to learn how to do it properly versus using a framework written by experts who've spent years thinking about the topic.
The best developers I've ever worked with are the ones who know exactly when not to roll their own implementation.
It can also depend on how many developers will write with your framework, and how long your code is expected to live.
If the code is built on a custom in-house framework, you are putting the burden on everybody to learn it and understand it and hope they can see it the way that you can. No one will really be as invested as you in understanding the ins and outs of the framework, or the special features you added that they won't even think is available, and won't care to discover or ask about.
With a well known popular framework, not only is it likely to have more documentation available online, there will be more resources from other people blogging about solutions, workarounds, tips and tricks. There will be additional libraries built on top of the framework for common problems. There is the incentive that getting good with the framework can help them in their next project or their next job interview. Lastly, it also reduces the friction of adding new team members.
> This is anti-intellectualism: "architecture is hard, so let the smart people at Google handle it."
No, it's "I want to get my job done, get paid and go home".
Believe me, I am anything but anti-intellectual! I love thinking about software and how to make things better. I studied Computer Science and love applying theory to practice. But 90% of the time, the correct answer is "use third party libraries or frameworks", not "roll my own".
In the current project I'm working on, I made the decision to use ReactJS instead of building our own frontend library from scratch. The project is almost ready to ship and has been very successful. New people to the project are saying "React was the right choice."
If I had tried to build our own frontend architecture from scratch we'd never have hit our deadlines.
I think that depends on how good is the framework is architecturally sound in the beginning AND where you work.
I had a case where we had our own internal framework. Its okay. But the team turnover is quite bad to an already tight deadline that I had to re-explain everything every time a new dev comes in. That framework has no routing(its basically for multipage app) and guess what, if someone decide that they need routing, that guy is going to create his own, and there might be two of these guys, so then we have two ways of doing routing then.
And given the fact that this team has high turn over and tight deadline, I don't think you can say that it'd make a cohesive team, and the communication channel that everyone has is already overloaded (loads of meetings).
Sure, that may be a bad project to begin with, but that would be a different story.
In this case, at least for me, using a standard framework would be no brainer.
I think you've just done a really good job explaining the differences between good developers and great developers. Good developers display that anti-intellectualism, but great developers spend the time to learn what they don't know and design a system that fits their problem.
Where did I say in my comment that "rolling your own" is the only acceptable solution?
I said "great developers spend the time to learn what they don't know and design a system that fits their problem". That can very well include pre-existing systems or frameworks.
I agree with the other replies but when you talk about learning from Rails, I agree. I also don't think using Rails is a bad idea. However I find the idea that if you don't use a framework to literally force you down a path you're on your own, that chaos will be dogging the project, that you end up with massive re-invention, to be incorrect.
Rails is also a bit of a special case I think, it was a massive ecosystem that dominated the community it was in. That isn't true of any JS client-side framework right now so choosing one isn't necessarily a sensible investment when you look 3+ so years out.
I honestly think the framework enforcing architecture idea is more of an anti-pattern, even if you do use a framework you need to keep in mind that it wasn't built directly to fit your needs and that you may want/need to move in 6 months or a year.