I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.
I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.
Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it.
Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.
I don't have enough experience in different types of environments to say which approach is most suitable in most cases, but I'll definitely say that using an existing framework is the safer path (you have a community to lean back on), and is also advantageous for hiring. So I think you're correct when you say that many developers are afraid of rolling their own frameworks, but I think there are good reasons for that, especially for quickly-growing startups.
One hard lesson I learned is that you can't bet on a front end framework having the same mindshare for very long. The churn can get pretty crazy, and in my mind this nudges the needle a bit towards rolling your own for long term projects. Especially if you can offload the complex parts of the arch to the lower-churn backend world.
You don't have to roll your own framework. You could always just use the micro-libraries that are ubiquitous in JS and pick an architecture that best fits your application. shrug to each their own. :)
shrug Personally, I don't see it that way. Frameworks are more generalized and reusable. They tend to be so large because they have to take into account a wider degree of problems. Applications with custom architectures and some external libraries are very specific and not typically reusable. Maybe it's just a matter of degrees.
So a framework has that "convention over configuration" flavor, while libraries are explicit. You actually have to load the application.hbs file manually with a handlebars parser. Then you use another library for the router, etc.
I can't imagine the spaghetti that would result from not using any framework (even a tiny handmade one) and just throwing a bunch of libraries together.
If a framework doesn't do something implicitly it's just a large library. If it's a set of conventions not backed by baked-in logic, it's a style guide.
A framework must CALL YOU. It usually gives you a piece of code that loads itself and lets you customize what it does by passing your code/configs to it. Then you tell it to run with what you gave it. The parts of the framework that you call yourself are actually "plug-ins" or basically framework-specific libraries.
If the framework never calls your code and you only call into the framework, that's always just a library. I would argue that actually it's easier to conflate a very full-featured library with a microframework because both really kind of call your code (especially when it's in the form of closures or a DSL).
You would never accidentally call a framework a library, though, because it's obvious that it's handling things for you. It's running everything behind the scenes and you just kind of advise it to do the things you want.
I really like this description. I've been trying to come up with a better description of what a framework is and isn't and I kept falling short. This one works well. Thanks! :)
Of course, everyone thinks their problems are complex and unique.