From eb78770de91e0bb7334ebb878e44d05a96e109eb Mon Sep 17 00:00:00 2001 From: Artem Zakirullin Date: Tue, 22 Oct 2024 21:26:08 +0300 Subject: [PATCH] fix frameworks --- README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/README.md b/README.md index b5d03da..8d86c25 100644 --- a/README.md +++ b/README.md @@ -234,8 +234,6 @@ Rob Pike once said: We are tempted to not reinvent the wheel so strong that we are ready to import large, heavy libraries to use a small function that we could easily write by ourselves. Make informed decisions about when to import external libraries and when it is more appropriate to write concise, self-contained code snippets to accomplish smaller tasks. ## Tight coupling with a framework -Frameworks evolve at their own pace, which in most cases doesn't match the lifecycle of our project. - There's a lot of "magic" in frameworks. By relying too heavily on a framework, **we force all upcoming developers to learn that framework as well**. It can take months. Even though frameworks enable us to launch MVPs in a matter of days, in the long run they tend to add unnecessary complexity and cognitive load. Worse yet, at some point frameworks can become a significant constraint when faced with a new requirement that just doesn't fit the architecture. From here onwards people end up forking a framework and maintaining their own custom version. Imagine the amount of cognitive load a newcomer would have to build (i.e. learn this custom framework) in order to deliver any value. `🤯`