Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.
Both are signs of inexperience.
Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job.
It's as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design.
You know that Joe Armstrong quote about OOP?
"the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle"
Well, it's the same with frameworks. You wanted a router, a template engine, and a few more pieces, but you go that, a banana, the entire jungle, and a mustachioed dictator telling you how to do things.
>If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.
It's as if we've forgotten the existence of libraries and APIs, of which there are like 200.000 in npm, and 50 of them are also really good.
>Both are signs of inexperience.
Some of the most experienced programmers, of 20+ years of career of successful projects, don't trust frameworks (and surely neither the "framework du jour" of JS, nor the "framework that ate Cincinnati" approach of J2EE of yore).
A competent lead programmer will choose a structure that adheres to common best practices and is maintained by a community. Also known as a framework.
>If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.
200,000 libraries, 50 of them good. My point exactly. A well written framework has already done the curation for you and has a community of people working to make those components even better for YOUR USE CASE.
>Both are signs of inexperience.
I guess I won't be hiring you then. If a candidate comes in and says "I don't trust frameworks because they are complex", I say "Thanks for your time."
How did the latter point derive from the former?
Frameworks come with prepackaged components and it's usually their way or the highway.
A framework might very well have a "community of people working to make those components even better" (period), but surely not "a community of people working to make those components even better for [MY] USE CASE".
If anything, a component's community try to make them as generic and all-encompassing as possible.
Contrast with libs, where I can cherry pick and use the one closest to my exact use cases.
>I guess I won't be hiring you then.
People use those kind of "arguments" a lot, as if they prove anything.
Depending on what those who say it are arguing against, it could both be a wise decision or the sign of an totally inept boss.
There are people who don't like frameworks that can code circles around people who do (and vice versa). If you don't want to hire the former, it's totally fine. Telling strangers who haven't applied to you, and have no intention to do so (and might be making hiring decisions themselves, elsewhere) that you won't hire them shows you in bad light -- trying to beat them into line not with arguments but with "boss" power.
Hilarious, and if a Hacker News bingo exists, it should be the free space.
Saying that please bare in mind that I love react it's a great tool but like everything it has its place.
Case of pot calling the kettle black methinks.