I agree.
However, I program for Apple devices, so my libraries are called "Frameworks."
I'd say that we should call them "Modules," instead. That probably covers all the bases.
Write Libraries, Not Frameworks
21–30 of 338 posts
Re: Write Libraries, Not Frameworks
#22Earlier quoted context omitted.
Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.
Totally understandable. You hit another good word there, magic. Frameworks IMO get to be magical or at least extra magical ... but with that extra magic comes responsibility (documentation, support, etc).
IMO magic is the result of one of three things
1. Developer does not have enough imagination to create necessary abstractions without resorting to magic.
2. Developer does not like commonly accepted approach to solving things in that particular language.
3. The language is objectively not expressive enough and magic is necessary.
IMO everyone thinks that it's 3-rd point, but it usually is #1 or #2.
Re: Write Libraries, Not Frameworks
#23Same thing from years ago: http://tomasp.net/blog/2015/library-frameworks/
Re: Write Libraries, Not Frameworks
#24Earlier quoted context omitted.
Totally understandable. You hit another good word there, magic. Frameworks IMO get to be magical or at least extra magical ... but with that extra magic comes responsibility (documentation, support, etc).
IMO magic is the result of one of three things 1. Developer does not have enough imagination to create necessary abstractions without resorting to magic. 2. Developer does not like commonly accepted approach to solving things in that particular language. 3. The language is objectively not expressive enough and magic is necessary. IMO everyone thinks that it's 3-rd point, but it usually is #1 or #2.
A good example of "magic" that is 100% worthwhile is the MobX library (I may actually write a post on it soon). A few key things that make this the case:
- It accomplishes something that would be dramatically messier and more error-prone in the host language without the use of magic
- It introduces a very small number of "magical" concepts, and their behavior WRT the outside world is very intuitive
- While every abstraction has leaks, the ones in MobX gravitate towards performance rather than correctness. I.e. it virtually always does what you expect, and usually does it efficiently.
- It provides trap-doors and hooks for dealing with every possible abstraction leak you might run into
Re: Write Libraries, Not Frameworks
#25Well that just makes me want to know what his week was like / brought him to that point. Not that I can't imagine, I just want to hear about the train wreck.
Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.
> "I won't name names because I don't wish to drag anyone through the mud."
If it's a large framework like Angular they can take it...
Re: Write Libraries, Not Frameworks
#26The best distinction I've read is:
When something is a library, your code calls functions on it.
When something is a framework, it calls functions on your code
Re: Write Libraries, Not Frameworks
#27Frameworks compose libraries for you, this is not always a good thing...
Re: Write Libraries, Not Frameworks
#28The best distinction I've read is: When something is a library, your code calls functions on it. When something is a framework, it calls functions on your code
I think that can be more precisely defined as Inversion of Control: https://en.m.wikipedia.org/wiki/Inversion_of_control
which has a strong association with "framework" thinking, but I think it's still useful to treat them as distinct concepts
Re: Write Libraries, Not Frameworks
#29> Do you introduce a domain-specific language? You're now responsible for part of the build chain, and for editor integration. > Now, if there's a major organization backing the framework, maybe the calculus works out. Google can back Angular... In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angu…
I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0]
It is the simplest thing I could conceive (to build, not to use - I plan to provide more convenience, but the selling point is the ability to customize everything.) It's template based and without a virtual dom - during render, each variable used will be listened and when it changes, the element that uses it is updated directly, without recomparing the whole tree. It's still in progress.
Re: Write Libraries, Not Frameworks
#30Earlier quoted context omitted.
Wrestling with an overly-magical and under-supported framework. I won't name names because I don't wish to drag anyone through the mud.
> "I won't name names because I don't wish to drag anyone through the mud." If it's a large framework like Angular they can take it...
Alas, if it were then that would alleviate some of my problems :P