3 ms·

This article craves for a global search & replace operation: "framework" --> "monolithic framework" I think a good framework should be developed as librairies

This article craves for a global search & replace operation: "framework" --> "monolithic framework" I think a good framework should be developed as librairies each solving a particular problem, glued together. Of course, at first you'll probably have many things in core that don't really belong there but there must come a time where you refactor to separate functionnality into distinct librairies (that you can use without the framework!). The "vertical" integration is done by glueing the librairies that were developed alongside it in a coherent whole. And I think frameworks should recommend approaches, not dictate them. For example, I'm fine with a framework that provides an authentication system out of the box, but it should be integrated as a normal plugin so that anyone can write a competing, alternative authentication system. In other words, explode your framework in tiny pieces and then glue those together. edit: I think that would be a boon for the adoption of a framework. People first start using some of your librairies, and over time they use more and more of your librairies and at some point they simply adopt the whole framework.

ajross 19y ago
That's mostly a semantic game you're playing. What you term "monolithic framework" is what the author (and, IMHO, most developers) mean by the term "framework". The rest of your post describes what most people are happy to call a "library" or "toolkit", or "utility". Frameworks, as understood by common industry terminology, are defined by providing the vertical integration you are talking about.
- jamesbritt 19y ago
  But look at the difference between Rails and Merb. If you want, you can treat Merb as better Rails (e.g., multi-threaded, less magic) and use AR + erb. All very familiar. Or you can see it as a pluggable framework, and use Haml instead of erb and Sequel in place of AR.
- Hexstream 19y ago
  If when people talk about "frameworks" they're really talking about "monolithic frameworks", then maybe most frameworks indeed suck, because they're all guilty of the accusations made in the article (which amounts to: monolithism). Imagine some monolithic framework. Now, a Super Magical Refactoring(tm) takes place and the public interface doesn't barely change at all, everything is the same except that the core is made tiny and almost all the functionnality is implemented as libraries that were extracted from the previous core but obviously fit perfectly well with the core and eachother. You're telling me the framework is no longer a "framework" but just a "library"?! I think you're playing semantic games. I say modularity doesn't preclude "verticalisation".
  - deleted 18y ago
    [deleted]
- deleted 18y ago
  [deleted]
- gensym 18y ago
  Typically, I think of a framework as something that calls your code, where a library is code that you call. The line gets blurry, of course, because just about any framework is going to include some libraries, and you may use some libraries by registering callbacks. But, something that gives you a bunch of blanks to fill in with your code would be a framework. Now, some frameworks include a set of libraries for the most common tasks you'd want to do when using that framework. E.g., a web framework that provides some sort of ORM. Usually, you can substitute other libraries for those purposes, but doing so has some cost (you feel like you're "fighting the framework", or, you need to deal with configuration overhead for those libraries you're not using). Ruby on Rails is an example of this. This is what I think the grandparent meant by "monolithic framework". Other frameworks have a more narrow focus and expect you to select and provide libraries for common tasks. Ramaze (an alternative Ruby web framework) is an example of this. Obviously, the line can get blurry, but most frameworks do seem to have a philosophy of "provide everything a developer needs to get started" or "allow developers to choose the most appropriate tools".

ajross 19y ago

That's mostly a semantic game you're playing. What you term "monolithic framework" is what the author (and, IMHO, most developers) mean by the term "framework". The rest of your post describes what most people are happy to call a "library" or "toolkit", or "utility". Frameworks, as understood by common industry terminology, are defined by providing the vertical integration you are talking about.

jamesbritt 19y ago
But look at the difference between Rails and Merb. If you want, you can treat Merb as better Rails (e.g., multi-threaded, less magic) and use AR + erb. All very familiar. Or you can see it as a pluggable framework, and use Haml instead of erb and Sequel in place of AR.
Hexstream 19y ago
If when people talk about "frameworks" they're really talking about "monolithic frameworks", then maybe most frameworks indeed suck, because they're all guilty of the accusations made in the article (which amounts to: monolithism). Imagine some monolithic framework. Now, a Super Magical Refactoring(tm) takes place and the public interface doesn't barely change at all, everything is the same except that the core is made tiny and almost all the functionnality is implemented as libraries that were extracted from the previous core but obviously fit perfectly well with the core and eachother. You're telling me the framework is no longer a "framework" but just a "library"?! I think you're playing semantic games. I say modularity doesn't preclude "verticalisation".
- deleted 18y ago
  [deleted]
deleted 18y ago
[deleted]
gensym 18y ago
Typically, I think of a framework as something that calls your code, where a library is code that you call. The line gets blurry, of course, because just about any framework is going to include some libraries, and you may use some libraries by registering callbacks. But, something that gives you a bunch of blanks to fill in with your code would be a framework. Now, some frameworks include a set of libraries for the most common tasks you'd want to do when using that framework. E.g., a web framework that provides some sort of ORM. Usually, you can substitute other libraries for those purposes, but doing so has some cost (you feel like you're "fighting the framework", or, you need to deal with configuration overhead for those libraries you're not using). Ruby on Rails is an example of this. This is what I think the grandparent meant by "monolithic framework". Other frameworks have a more narrow focus and expect you to select and provide libraries for common tasks. Ramaze (an alternative Ruby web framework) is an example of this. Obviously, the line can get blurry, but most frameworks do seem to have a philosophy of "provide everything a developer needs to get started" or "allow developers to choose the most appropriate tools".