Excellent article describing common design patterns used by frameworks, with examples and trade-offs/drawbacks discussed.

A framework is defined as "code that calls your (application) code". Not sure I totally agree, since frameworks that I've built are usually instantiated by the application explicitly. Well, that launch sequence is one of these patterns described.

Here's a table of contents.

- Callback function

- Subclassing

- interfaces

- imperative registration API

- convention over configuration

- metaclass based registration

- language integrated registration

- DSL-based declaration

- imperative declaration

- language integrated declaration

(Nitpick: might want to standardize the capitalization of titles, like "Pattern: Callback Function".)

I agree totally with "Metaclass based registration" as I have seen the same with Django Models. It took some time initially to grasp what(and when) is happening under the hood. Even now, I find it hard to make newcomers understand how it all works. I have taken 2 sessions with my current interns and still they get lost.

From the article:

> When you declare a Django model by subclassing from its Model base class, Django automatically creates a new relational database table for it.

That sounds convenient - but feels like too much implicit behavior for me. I almost always prefer a framework that lets (or forces) the user to explicitly specify operations.

Same with "import-time side-effects". When I find myself providing such a shortcut, I usually wrap it so the user must call it explicitly, to control what/when these effects happen.

This is handwaving a bit, you still have to manually create the migration that results from your model code change, and also apply the migration.

It's "automatic" because you just have to issue a single command for each, and django generates the migration from your code and settings.

Great article.

I'm always a bit ambivalent about assigning "hard and fast rules."

In my mind, a "framework" is...a framework.

Frameworks are structural artifacts. They exist in the corporeal world, as well as CyberWorld. Buildings are constructed over frameworks. Vehicles are constructed over frameworks.

I have been writing SDKs, APIs, frameworks and drivers for a long time.

<opinion type="mine">

I tend to differentiate them (in my head) like so:

DRIVER

Code/binary asset that affords a connection between two levels of a dynamic system; abstracting characteristics of the lower part of the system.

Drivers can exist at many layers; from machine-code to UI. I have written UI component drivers, as well as device drivers.

Drivers tend to be "smaller" projects than frameworks, but there's a lot of similarity between drivers and some types of frameworks.

API

The published specification that defines interaction with a code/binary asset; combined with a minimal level of exposed code to afford access to the API elements.

SDK

A code/binary asset that exists independent of an API, but which affords access to that API; often adding functionality.

I feel that an SDK can def be a framework.

FRAMEWORK

Fairly similar to what was defined. maybe a bit "looser."

This is a set of code assets (not necessarily binary, but it's possible) that can be used as a "seed" or integral component of a code application (small "a," not necessarily a complete executable application -it could be a driver, SDK, operating system or framework).

In my mind, frameworks can be complete, self-contained and closed; possibly exposing only an API as an affordance to access the assets. Cocoa is an example. A framework can also be completely open-ended, and unusable without components provided by the implementor. Classic app frameworks like Qt are examples of this.

It may be open-source, or opaque.

The frameworks that I have written have been fairly large.

I feel that Drupal or WordPress can be considered frameworks, as well as things like Qt or Cocoa.

</opinion>

So then React is a framework?

I would say yeah.

I think React calls you (render + callbacks) more than you call it in most cases.

Like a library, however, your code is usually kicking things off by calling ReactDOM.render().

I'm sure there are "meta-frameworks" build around react which set up your router in declarative style and call that top level method.