[jasode]

>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 framework emerged from it.

2) the programmer truly avoided coding an "accidental framework" but only by duplicating code everywhere.

In short, if you organize code in any coherent way with consistent abstractions to follow principles of DRY[1], it becomes a framework whether you give it a name or not.

It doesn't mean the framework-called-React is perfect. What it does is raise the quality of discussion from "plain JS is better than ReactJS" to the more realistic comparison of "my unnamed-framework is better than React-framework because ... see my source code at github, etc".

>I wonder why some people like it

I think for some, they truly chose it for the wrong reason. However, there are others who look at the problems React solves (efficient DOM diffing algorithm, 1-way view update, etc) and conclude that they would rather not reinvent that themselves. Therefore, they use React so they can start solving other more specific problems relevant to their business domain.

[1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

[thr0waway1239]

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' views on how the rest of the world should write their code". The second scenario is best avoided because

a) you don't want to take the word of someone who isn't going to face the consequences of all your framework-induced overcomplicated code razzmatazz

b) for too many people, this also means skipping the part where they learn to walk and start trying to run

c) not to mention, the companies creating these frameworks are surreptitiously doing everything possible to change the nature of the web, so by not using the frameworks (however "open" the "source" is presumed to be), you register a little bit of a protest at a fairly low cost

Besides, have you ever considered the following: the person creating the invisible framework is actually best suited to find better ways, assuming they do want to improve their coding abilities. Such a person is more likely to naturally gravitate towards the solution. If they fail to do so, those who end up maintaining such code will end up gravitating towards the best solution. How do you think the converse scenario plays out, where someone did use a framework without really needing it, and then it was found to be overcomplicated and unmaintainable?

[Bahamut]

There are some traditional upsides/downsides to writing your own framework, but they should be evaluated for each case without blindly espousing one view or another - that said, for almost all business needs, you are probably better served by using an established framework.

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.