To begin, React isn't a framework. It’s a tool. Would you compare a table saw to a workshop? That doesn’t make sense and neither does comparing React to a framework—especially if you’re saying you don’t need one. Furthermore, using a virtual DOM is not the purpose of React. Virtual DOM is merely a part of how React works. People don't buy cars to get an engine. They buy cars to get around places. People don't use Rea…
> To begin, React isn't a framework. The way I look at it: - If you use a library that augments your style of work but doesn't change it then it's a library. Maybe a tool. - If you use a library that replaces or changes your style of work then it is a framework. React is a framework in my opinion. It can be used as a library but it's almost never used that way; most people incorporate JSX and much of the virtual dom…
Yes it’s pedantic and arguments could be made either way. However my experience is that people comparing frameworks are often looking for something comprehensive—that solves (or makes provision to solve) a majority of the challenges they will face with a particular stack, so they can focus their energy instead on the problem domain.
React is far from this. It’s an important but relatively incomplete piece of the puzzle. React apps use a lot of other libraries to provide the missing pieces. A framework, to me, would be a system that ties these pieces together to solve for a large class of apps.
> While correct I cannot disagree with you enough. If you write clean, as-simple-as-possible code with clear separations of concerns it's dead easy to maintain and not necessarily "full of bugs". It really just boils down to how well a developer can architect an application to determine if their own framework is going to be a huge bottle neck / issue or a breeze. I've been through both :)
In my experience the number of developers that can do this successfully is relatively small. It requires a lot of experience and skill. Even if there were a large number, why reinvent the wheel for each project?
> I'm not a fan of this sentiment. If it makes the most sense (and it doesn't always) I try to avoid using frameworks but I would hardly call myself a cowboy (though perhaps I will going forward, ha).
Yes—be skeptical but also practical. Not every problem needs a framework but would your problem benefit? If yes, why not? Especially if you’re adopting something proven.
This is especially true if you’re writing something new and therefore still learning about the domain. I've seen a number of cases where a team decides against a framework, ends up with a mess on their hands, and later switches to one of the frameworks they were originally considering (at great cost).
One case in which it may make sense to write your own framework for a large application is when the app is relatively stable (therefore you can leverage your experience building it) and existing frameworks don’t meet your needs.
> The DOM API, as this article shows, provides quite a bit of functionality that many popular frameworks / libraries provide and as long as you don't need to target old browsers you're fine here.
This is true, although sometimes impractical in enterprise software. When jQuery came out it was a godsend in it’s ability to erase cross browser compatibility concerns. As time went this became less of a problem and now I no longer use jQuery. You won’t find me arguing to stick with something that used to make you more productive where better alternatives are now available or ready.
> Yes, angular and react do a lot for you but you can still write effective web applications without them with minimal "reinventing of the wheel". Just because someone provides a way to do X in a framework doesn't mean it's not easy to still do X without a framework. Many times the bulk of the framework's capabilities are supporting its own, specialized workflow that isn't always necessary.
I can say to sum up that this totally depends on who is working and what they are building. There is a ton of complexity that React and other “frameworks” abstract away for me. The core concepts powering these tools may not be that hard and perhaps more of us could take on the task, but the devil is in the details. Usually these libraries start out simple, but in the end it’s the edge cases and quirks that make them internally complex.