3 ms·

Because each library does one thing only and it is easy to understand that particular abstraction. With a framework you not only have to learn how build things

Because each library does one thing only and it is easy to understand that particular abstraction. With a framework you not only have to learn how build things in the framework (which takes a lot of time to become truly proficient) I also have to build what I am already supposed to be building. I find personally that frameworks * Simple things hard. Hard things simple. * Anything outside of the happy flow they present to you in the docs is a major PITA. * I frequently find myself scrabbling around for information when I need to override how the framework works in a particular scenario. * They nullfy much of your pre-existing knowledge e.g. I am described at a lot of places as a JavaScript guy in the team, because I get JavaScript. When I use Angular or React, most that is irrelevant. It doesn't really help me. If I am just using well established patterns + my existing knowledge of the programming language and environment. I can normally put something together myself that does just what I need it to do and I use a library for things like date time calculations or Ajax requests or something else that is mundane.

debaserab2 7y ago
I think this is a pretty succinct counterpoint. I especially agree the sunk-cost of investing time learning a framework isn't something to take lightly. The only thing I'd counter to this with is when I see this approach taken, an informal "framework" of sorts tends to evolve naturally. First you write something that handles the routing, then soon you want to organize the code the route endpoints call, then you layer on the authentication at the top level request handling area, so on and so forth. Over time, as new requirements come in and new people work on the project, more and more patterns, conventions, and library are added to the codebase - pretty soon all that "glue" code meant for interfacing with libraries is reaching or exceeding the complexity of a framework based codebase (except your codebase probably has less documentation for things like conventions and patterns than a framework would). That said, I don't think it's the wrong approach especially when the scope of the project is limited and/or there are ways to manage feature creep (e.g., frontend only, limited lifespan, internal facing apps, etc)
battery_cowboy 7y ago
Very good comment!

debaserab2 7y ago

I think this is a pretty succinct counterpoint. I especially agree the sunk-cost of investing time learning a framework isn't something to take lightly. The only thing I'd counter to this with is when I see this approach taken, an informal "framework" of sorts tends to evolve naturally. First you write something that handles the routing, then soon you want to organize the code the route endpoints call, then you layer on the authentication at the top level request handling area, so on and so forth. Over time, as new requirements come in and new people work on the project, more and more patterns, conventions, and library are added to the codebase - pretty soon all that "glue" code meant for interfacing with libraries is reaching or exceeding the complexity of a framework based codebase (except your codebase probably has less documentation for things like conventions and patterns than a framework would). That said, I don't think it's the wrong approach especially when the scope of the project is limited and/or there are ways to manage feature creep (e.g., frontend only, limited lifespan, internal facing apps, etc)

battery_cowboy 7y ago

Very good comment!