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. :)
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! :)