21–30 of 119 posts
The worst is when three lines of completely standard code (immediately understandable to anybody inline) get „helpfully” lifted out into a utility function.
> 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.
Library is something that can be pulled off project and replaced with something else. There's no non-trivial project where replacing React with anything would be possible. Every React web app is built around React.
This. This. This. I currently work in a codebase where so much code has been abstracted away for “cleanliness” that it’s impossible to understand what code is actually running. The worst is when three lines of completely standard code (immediately understandable to anybody inline) get „helpfully” lifted out into a utility function.
As 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…
And I think twice before I use a framework. Frameworks enforce a certain way of programming which you can never be sure to match the problems you will have to solve in the future. Libraries don't do this - at least not to the extent of a framework. Libraries are composable building blocks.
Nevertheless, there may be applications where frameworks are beneficial (e.g. GNU Radio).
> 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…
> A framework is some kind of application scaffolding that normally calls you.
There is no real distinction between these two.
> 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?
As 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 u…
The problem is that your code has to work within this abstraction and can only solve problems covered by the inventors of the abstraction.
> 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…
> A library is something you call. > A framework is some kind of application scaffolding that normally calls you. There is no real distinction between these two.
As 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 u…
Spring Boot and other similar frameworks come to mind; by forcing huge amounts of indirection you lose a lot of visibility of your call stack because the convenient "glue" code is now orchestrating everything at runtime, but that code isn't yours, and it isn't easily inspected or fixed.
At the end of the day. You end up cobbling together a bespoke, worse version of Django anyway.