Ok - so in a web application I need routing/binding of controller functions to URLs/HTTP methods, the ability to interact with an RDBMS and parse a result-set into an intermediate abstraction, the ability to take in the results of a POST or PUT and parse it/validate it/sanitize it, the ability to emit JSON....and yet all of this functionality is baked into my web framework. I can either use a library for each one of those functions or I can just use a light-weight web framework and get all of them automatically. Most likely the framework is just a collection of libraries anyway - Scala Play Framework uses, for example, Anorm for database querying, Slick for higher-level ORM, Jerkson for JSON serializing/deserializing, Twirl for templating, etc, etc.
Having imported those libraries, in the end what I write is going to look a lot like what a framework asks for if it's even remotely well-defined.
I think the advantage of using each of those libraries instead of a single unifying framework is that you put them there and understand why they are there, instead of relying on defaults. Also, there is less risk of framework-induced coupling -- sure, many frameworks are configurable, but try to move away from their recommended components and you are asking for trouble...
Also, there is less risk of framework-induced coupling -- sure, many frameworks are configurable, but try to move away from their recommended components and you are asking for trouble...
Exactly. If you built your own system, choosing a good library for each major recurring task, then you inherently have both an understanding of how the overall system fits together and a degree of isolation between the libraries. If your requirements evolve beyond the scope of a library you’re using, or if a library loses popularity and is no longer maintained, you can probably swap in a replacement to serve an equivalent (or updated/expanded) role relatively easily.
Of course, the price you pay is that you do have to write some glue code to connect up the libraries where perhaps a framework would have provided that for you. This has potentially interesting implications for both the way good library APIs are designed and the scales of libraries that are or aren’t worth the overhead.
This also has huge implications for language design as a whole, and personally I think this is one of the reasons why Java is infamous for its verbosity and boilerplate. I also think it’s one of the reasons why common idioms from functional programming have increasingly been pushing into mainstream languages that aren’t necessarily functional programming specialists: functional idioms offer new forms of glue, and in particular, they are often well suited to writing “slightly customisable” algorithms and adapting more substantial pieces of code so they can be used together.
Having imported those libraries, in the end what I write is going to look a lot like what a framework asks for if it's even remotely well-defined.