I am currently in a phase, where I am sort of reflecting on my past 1,5 years of web development. I am trying to see how things went and what decisions I could make to improve.
Sometimes, thinking about what libs and frameworks to use is so hard. There is so much abundance, it is overwhelming. And it just keeps growing.
I just read this tweet from Dan Abramov:
"Hell is other people's abstractions"
Made me laugh. It is just so true π.
Committing to fundamental abstractions is one of the things I believe one needs to be most careful about: you will literally get used to thinking in them. I still mourn about the many people who were sold into one of the biggest hoaxes of computer science: "inheritance for code reuse" - The 3 Amigos made some decent cash by selling dogs that "woof" and ducks that "quack".
I decided for myself, that from now on I will only try out and possibly commit to abstractions if I can see a strong "why". I need to see strong reasons, conceptually, that something is a really good idea. Minimalism and low-key are not just nice, but an absolute must-have.
I was happy to see, that there can be libs that fulfill my ideals when I discovered jotai and zustand for React state. On the very first time I looked into them, I was able to infer this "why". I was able to project into the future, if I write code like that, the experience of doing so will be pleasant and things will turn out well.
When I looked into Redux it was more like: "Yeah, I get it, it's by no means bad engineering, but I can't see a possible reality where I write code like that." π
I wish, that docs would focus on this "why" aspect more often. Usually, they only tell you "how". There's the obligatory introduction (like the counter sample) and then there are recipes of various sorts.
But the "how" is only interesting after you committed to the abstraction. Outside the "mental box" of the abstraction, it has no relevance. The "why" is important to decide whether to step into this "mental box" or not.
Docs rarely provide really strong and convincing support for the "why" (if they do, instant trust explosion). So please tell me "why" more often π.
Top comments (4)
Absolutely. Why?, would be nice. Discussing why would also help drive the library into our memories better. Why did you create this? Why did you choose to create your method as such? It's also WHY! We are obliterated with so many libraries trying to solve the same problems. No one talks about why. Everyone abstracts solutions to problems, resolves reasoning better with certain libraries moreso than others. We process things differently.
Does it make you right for understanding Zustand versus me understanding Redux. Nope, we just processed the writing and syntax differently. Don't get me wrong. Redux is brutal. I'm with you on Zustand. Haha!
Thanks for your feedback, I appreciate it.
I think a major obstacle for discussing the "why" is this: Discussing it seriously also includes talking about the "why not". This would mean inform people about gotchas and weaknesses of the abstraction at scale in real production scenarios.
Then there are also other incentives around libs/frameworks/paradigms that have nothing to do with the quality of abstraction. This becomes most obvious when you revisit the 1990s and OO. A huge multi-billion dollar industry has been created around it: UML, software process models, consulting, certifications, books, etc. If you simply look at the abstraction it's essentially just:
Absolutely ridiculous π
If you honestly communicate huge problems and obstacles of an abstraction, it is not so good for growth and money-making. Interesting spontaneous idea: always make sure that people who create the abstraction are idealists.
It the same as with companies whose service and support really suck. They all say they are committed to excellence blablabla. They don't have a beautiful hero section on their website that tells you: "Please don't do business with us, we suck" π. A good indicator to detect such companies: Their websites never have beautiful hero sections π
A really nice blueprint for docs that consider the "why": observable-hooks.js.org/guide/
It gives you a simple, easy-to-understand, and innovative mental model for reasoning, is minimalistic, informs about gotchas, and tells you to be careful when using it and when not to use it.
I totally understand your concern. I was just about to start writing a post about how abstractions are perfect only for a short period of time, after that they all leak or are "dry" i.e. don't provide enough functionality.
Unfortunately, that is how things are. There is no perfect abstraction
You can read this nice article I found on Medium medium.com/young-coder/what-are-le...
Thank you for your feedback. I am totally with you. Things are just messy and there just cannot be this one single way things have to be.
Discussing the "why" should never be forceful (you MUST use this), because there are so many different types of applications, requirements, etc. It should be more of a gentle guide for developers to find their own path and to make sound decisions.