- 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 into their workflow.
But this is pedantic. I feel comfortable I could make an argument for almost any JavaScript library being a framework as well as not being a framework.
> Scale your app up, however, and you’re going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change.
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 :)
> You’re welcome to give this up to be a cowboy, but me: I’ve been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time.
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).
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.
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.
Good post, very well said and says most of what I wanted to say on the subject.
I was much more in the camp of 'use/learn frameworks as much as possible for productivity', started a new job and have really become much more moderate on the subject. There really is a balance and the type of application you're building matters.
The best thing about writing your own framework is that you're able to structure to fit the exact needs of a business. The productivity gains can be extremely massive as well. If you can build a custom system that scales to your needs, it can certainly be worth doing.
The flip side of course is that you may ( Probably? ) have a fairly simple/basic product. If you don't have heavy business logic to model, the heavy automation and tooling that is available can be a damn good way to go.
> 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.
I don't think that one's style of doing things have any merit in classifying what 200 people at Facebook had built. (Perhaps someone likes two-way binding. Backbone would be a library/tool and any Virtual DOM implementation would be 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 into their workflow.
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.
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 into their workflow.
But this is pedantic. I feel comfortable I could make an argument for almost any JavaScript library being a framework as well as not being a framework.
> Scale your app up, however, and you’re going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change.
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 :)
> You’re welcome to give this up to be a cowboy, but me: I’ve been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time.
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).
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.
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.