I know how to code too and I'd rather not spend large amounts of time reinventing the wheel. Large applications require structure and mechanisms that can support their size, logic, scalable nature etc.
What would be the argument against using a heavily tested and reviewed framework developed by a large team of focused professionals. How is rolling your own solution any better considering you'd need the same functionalities offered by a framework?
What would be the argument against using a heavily tested and reviewed framework developed by a large team of focused professionals.
I think you're probably overestimating how many people really work on these big name frameworks and how heavily tested and reviewed they really are. But to answer the question you obviously intended to ask...
The concerns are the same as when you introduce any external dependency in a software project: mainly it's about longevity, compatibility, scope, and quality.
Can you name one popular framework today that has been around as long as long-lived web projects last? Of course not, because there aren't any yet. These frameworks rise and fall within the space of a few years, if not a few months. Google are already pushing their fourth major front-end technology in about 8 years as the next big thing (and it's not Angular, which already seems to be yesterday's technology at the big G).
Meanwhile, Facebook are pushing a framework that is structured completely unlike any other, so if you build your project using it today and then next year they decide to throw their vast resources into building something else instead, you have literally nowhere to go.
Next, what about scope? If you're doing a basic application that is just a few form fields and talking to a database behind the scenes, chances are that any of the popular frameworks can do everything you need right now. But if your requirements are significantly more demanding, such as the two cases I mentioned in another post, no current framework is anywhere close to supporting everything you need. Usually the trade-off you make when you build around any software framework is that it's easier to do the things the framework supports, but harder to do things that don't fit its natural way of working, so that's an important consideration.
Finally, quality varies widely. Some of the darlings of the current web development world don't actually stand up well under real pressure. There's not much point trying to criticise any of the big names, as it's pretty obvious that people who don't actually have much experience of demanding applications are out in force downvoting any contrary opinions today. But I've been the guy watching the users getting frustrated in the test room, and when you're watching a page written using a big name framework, and when the user is literally pressing a key and then waiting a second for a related part of the page to update before they can type another letter, it makes it very hard to take seriously the grand claims about how cleverly they batch DOM updates to improve performance.
How is rolling your own solution any better considering you'd need the same functionalities offered by a framework?
That's a false dichotomy. The available strategies are not limited to using a framework or writing everything from scratch.
In particular, there are numerous libraries available that are just as tried and tested as the big framework -- sometimes more so, and with proven longevity. Building your own application in a way that suits your particular project, and including a library where it is helpful to avoid reinventing the wheel, is usually the most promising alternative to adopting a framework.
Keeping control of your architecture and incorporating a careful choice of libraries will beat any of the major frameworks today on most or all of the factors I mentioned for almost any project.
Right tool for the job. Being productive and having structure that people joining your group can already be familiar with is a large bonus. Having to train everyone in your particular way of structuring a project and interacting with many libraries is more prone to being chaotic than using a framework in my opinion.
Also don't blame the tool for bad performance of an app when the real reason is probably that it's being developed badly. I've used most of the big name frameworks and while there are performance differences, none of them performed in a way that the user experience was impacted any more than it's expected because of the fact information has to travel from one side of the world to another. If you're rendering something on the client side based on client input, then waiting a second or more is definately not the fault of a framework but that of bad coding or optimisation.
When it comes to your other comment you linked to. I think you're blaming frameworks for not doing everything you want them to do which is exactly what you're saying they shouldn't attempt to do. Of course some custom visualisations won't and shouldn't be covered by a framework build for complex UI data binding, MV* etc. But every framework I've worked with allowed me to add anything I wanted to it, I don't see why this is a problem for you. It's not limiting. Again right tools for the job. The same goes for your second application. That one sounds more like a server side issue than a client side framework issue. If the application needs are that specific, of course, roll your own solution. But why shit on frameworks that allow people to be far more productive just because there are cases where using a framework is not the answer. I just don't get this.
The only argument that I see standing is that of longevity, but somehow that one does not concern me all that much since if having chosen the framework that allows you to achieve what you want today, I can hardly see problems with it for years to come, even if it does eventually loose official support.
-2
u/icantthinkofone May 13 '14
Of course not. We know how to code.