21–30 of 550 posts
It matches TFA, but I think 'Framework' in that capitalisation (incorrectly) implies it's about Framework ( https://frame.work ) the company. I think quotes - 'framework' - would be better, both here and in the OP; we can fix one of those.
The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating code. I agree with this but it requires a lead who's good at architecting such a codebase. That person also needs to stay with the company for a long time because they're essentially replacing the "framework" with bespoke human logic. I think many, maybe most, c…
The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating code. I agree with this but it requires a lead who's good at architecting such a codebase. That person also needs to stay with the company for a long time because they're essentially replacing the "framework" with bespoke human logic. I think many, maybe most, c…
Companies who try to build any type of codebase end up with a mess. Always. No exception.
There is no reason to pretend software development's natural tendency to increase entropy is exclusive to a specific type of software architecture. In fact, some developers even go to the extent of criticising software architects for existing, because they have "rules" and enforce "order" and "organization".
If anything, being mindful of a specific architecture goes already a long way to fight entropy.
Before you comment with "So you want us to write everything ourselves?", make sure you read the paragraph that starts with "Many people will argue that not using a framework means write everything yourself. This is a false dichotomy."
Indeed. This excerpt from that paragraph is a good thesis for the essay as a whole: > The point is not to never use frameworks, but to isolate them. To call them from a single place. One that we own. That we are responsible for and that we limit very much in what it can touch.
I had the misfortune of working on a project which abstracted a framework. It was awful. It ended up being an ad-hoc component that was half-façade, half-adapter that was inadvertently tightly-coupled with the framework. It added an awful lot of complexity with the only tradeoff being theoretically being able to abstract away the underlying framework.
It was not worth it. It created far more problems than those that it solved.
You mean, whereas you call a library; a framework calls you? :)
Somebody criticized the idea saying that one would end up writing their own wrappers for such a language, but that's not a problem: one would customize a sub-interface for their own shop's needs and conventions. That's not a bad thing. But if we had a decent state-ful GUI markup standard, such wrappers would be lite, more about managing domain patterns & defaults than reinventing a GUI engine and common GUI widgets from scratch.
Here's a partial list of GUI widgets & idioms that DOM lacks or does half-ass: https://www.reddit.com/r/programming/comments/otixwo/comment...
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
6. Frameworks often handle the last 20% of a project that no one wants to do, such as handling compatibility or accessibility issues.
7. There’s a good chance that the framework has already had to deal with edge cases that you would otherwise learn the hard way
Some frameworks make the effort to make a clear distinction between which methods you can extend, which you can call, and which are framework-internal. The only one I've seen that really did this properly is Wicket, but it absolutely does work: you can fearlessly upgrade even a major version. (Of course the cost is you sometimes find yourself cursing because the method you wanted to override is final, so instead you have to copy-paste it and accept the maintenance burden belongs to you now - but you're doing so explicitly in that case).
> The more isolation, the better maintainable. The code that handles e.g. token authentication should not be written by us, but be included in a single, well contained, bounded area. One that encapsulates this and translates it into domain language, preferably. E.g. behind a authentication.is_known_as_admin(request.token) rather than sprinkled throughout our controllers, commandline-interfaces, scripts, or async jobs.
This sounds superficially like good advice, but it's practically impossible in a language without monads, and often ends up as the "inner-platform effect" - sure, you've put a wrapper around the library, but reimplementing your wrapper to switch out that library is no easier than reimplementing your first library's API directly on second library. In my experience you're better off YOLOing it most of the time. If you ever do need to remove or replace a dependency, you can do the work then rather than front-loading it, and it's actually pretty easy - delete the dependency, fix the compilation errors, and you're done.
It matches TFA, but I think 'Framework' in that capitalisation (incorrectly) implies it's about Framework ( https://frame.work ) the company. I think quotes - 'framework' - would be better, both here and in the OP; we can fix one of those.
I'm so old, I thought of the productivity suite from the 1980s: https://en.wikipedia.org/wiki/Framework_(office_suite) I still think about that suite, because it had a certain kind of elegance: Everything was frame, and therefore text documents and spreadsheets were frames, and you could embed a frame in a document, which correctly implies you could put a spreadsheet in a text document. But the cells in a spreadsheet…