"shared infrastructure owned by dedicated teams" must be nice, I have to say
Avoid Mini-Frameworks
11–20 of 119 posts
Re: Avoid Mini-Frameworks
#12> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…
these things are hard, maybe impossible to define. For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.
That’s because React started as a small, focused library and evolved as even more than a framework, a whole ecosystem, complete with its own best practices
Re: Avoid Mini-Frameworks
#13> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…
Is an `EventEmitter` a framework or a library?
Re: Avoid Mini-Frameworks
#14As a rule of thumb, "magic" is a code smell. Libraries should be preferred over frameworks whenever possible. A toolbelt of small utility-like composables are often easier to maintain and reason about. This results in added explicitness (i.e. less magic, fewer surprises). Personal experience shows that the immediate efficiency gains of a framework often get diminished in the face of all the hacks people introduce lat…
I don‘t like dismissing technologies on the basis of being „magic“, since the magic could often just as well be called abstraction, and the line between them is often personal preference.
The abstracted-away logic in a Laravel application can either be called magic or abstraction, but so can the optimizations of a database query planner.
I think often you still need to know the underlying mechanism, but it is still useful to get the innards out of the way.
Re: Avoid Mini-Frameworks
#15> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…
If you look above the unorthodox library/framework distinction, I think the criticism is about birthing new (inadvertently leaky) abstraction layers with new semantics to capture the specifics of the domain. Often with either esoteric words attached to supposedly novel patterns, and/or unconventional usage of existing terminology.
The promise is to simplify and unify things but as noted, such efforts often have the opposite effects.
"Teams are struggling with properly adopting FooTech - our FooBarTool wraps it in a beautiful package and magically solves everything with a single command and one config file"
"We should template all this yaml"
Re: Avoid Mini-Frameworks
#16Somehow, somewhere there is a pleasant balance between DRY and non-DRY which is different for everybody. God forbid having a colleague who sees a thing repeating and slaps an abstraction over it at whatever cost because DRY!
Re: Avoid Mini-Frameworks
#17> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…
Is an `EventEmitter` a framework or a library?
Neither. It's an implementation of the interface in question.
Re: Avoid Mini-Frameworks
#18Earlier quoted context omitted.
these things are hard, maybe impossible to define. For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.
That’s because React started as a small, focused library and evolved as even more than a framework, a whole ecosystem, complete with its own best practices
I don't agree. What I said about React providing structure and (lifecyle) hooks was true from the first version.
The later stuff adds other ways of doing the same thing but a library it remains.
That's as self described by the React team, and I think the consensus more broadly.
Re: Avoid Mini-Frameworks
#19> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…
Is an `EventEmitter` a framework or a library?
> Is an `EventEmitter` a framework or a library?
It is best described as a pattern implementation (observer / pub-sub).
Example Node.js EventEmitter usage:
const EventEmitter = require('events');
emitter.on('data', handler);
emitter.emit('data', value);
-----------
You explicitly instantiate it. You explicitly register listeners. You explicitly emit events. It does nothing unless you call it. There's no lifecycle, no main loop, no required structure.
EventEmitter is not a framework because it does not define application structure. It doesn't own the program's control flow. It doesn't decide when your code runs (beyond callbacks you register). It does not enforce conventions or architecture.
People sometimes call it a framework incorrectly because of two sources of confusion:
1. Callback-based APIs feel like inversion of control. But this is partial IoC, not framework-level iOc.
2. It is often embedded inside frameworks. Examples: Express routes, React synthetic events, Electron internals.
Re: Avoid Mini-Frameworks
#20This is why I use Ruby on Rails. Shared constraints and boring conventions age better than clever mini-frameworks built around one team's mental model.