Earlier quoted context omitted.
>writing no-framework javascript isn't difficult at all, If anyone recommends this without any concrete source code to illustrate the superiority of the advice, be skeptical for 2 reasons: 1) the programmer who rejects frameworks ends up writing another invisible framework that doesn't happen to have a name . Because the author is intimately familiar with his own code, he many not even realize that an implied framewo…
Imagine if I flipped around your statement and said - don't trust anyone who recommends the superiority of a framework without comparing absolutely every possible framework at their disposal and showing sample code to explain why a certain framework must be chosen. Are you up to this comparison task? Suddenly, the problem changes from "finding better tools for my job" to "evaluating some fairly opinionated peoples' v…
Frameworks 1) Solve more difficult problems that most developers are not qualified to implement optimal solutions in a timely manner for (i.e. efficient algorithms, creating parsers for correctly parsing templates and avoiding security pitfalls, cross-platform rendering, avoiding cross-platform bugs such as browser-specific issues, etc.) 2) Have a publicly documented and established set of patterns/concepts (good for hiring - most developers do not want to learn a homebrewed system that likely brings less professional development benefits for their careers. Whether this is accurate or not in how it affects their careers is irrelevant, this perception is pretty strong from what I can tell anecdotally) 3) Avoids the significant cost of committing to R&D to reinvent the wheel, which most companies are not willing to do and/or does a disservice to companies financially
Homebrewing a framework, which is what you do when you avoid an existing one has these upsides 1) Building something that is potentially easier to understand (especially if built by one or a few people) 2) Potential for smaller JavaScript payload sizes
The upfront cost of creating a homebrewed framework is significant, and to be honest, going that route is probably technical malpractice for an engineer for almost all situations, even at bigger companies. I would be far more wary of any recommendation of homebrewing a framework than adopting an existing one maintained in the open by a community. The downsides of a framework not controlled by you are far outweighed by the downsides of creating one from scratch almost all the time. It is far more productive to participate in the community for a framework that is close enough to your ideal and influence the process that way than it is to burn it all down and suffer trying to solve the same problems in a more limited and likely worse way.