Great writeup, thanks for sharing :-)
Some time ago, I wrote a small article, what you could learn instead of frameworks. Pretty rough, but still worth a read I think.
https://pilabor.com/blog/2021/05/learn-concepts-not-framewor...
Why I Hate Frameworks (2005)
321–330 of 407 posts
Re: Why I Hate Frameworks (2005)
#322I used to hate ORMs and never used one until i discovered Prisma. Thanks to it i have been focusing more on the core idea
Re: Why I Hate Frameworks (2005)
#323If you pick enough frameworks you can learn how the underlying system works. All web frameworks are the same to me, doesn't really matter if they're python, javascript, php, or whatever tbh. req/res body cookies that's it
I disagree, “req/res body cookies that’s it” is not the underlying system. It’s an abstraction over the TCP/IP and HTTP stack. What happens when you need to disable nagles, avoid copies of the request body, use websockets, gRPC, etc? You’d need to pray that the framework gives you an escape hatch.
I might be doing it wrong, but I just approach those as new pipes to be put onto the system? they're after all basically different ways of transmitting data from point a > point b.
Why would you choose a framework that didn't provide a escape hatch for your use case is the real question tho.
TIL: Nagles/TCP
Re: Why I Hate Frameworks (2005)
#324Earlier quoted context omitted.
Sounds like you haven't really understood the benefits of polymorphism, encapsulation etc. The general idea is to compartmentalize your logic and only expose the important parts like if you need to generate pdfs from html you may need to use a lot of moving parts to make that happen but you hide all of it and only expose an interface with a single action that takes html and returns a pdf. If you later need to change…
Not everything needs a hyper-abstracted solution. Most people suck at writing neat abstractions, so they spend an excessive amount of time writing shoddy solutions which no one really wants to deal with but there's a soft, begrudging agreement to use them anyway while the business sees no value in having their devs rewrite it. This goes double when you step into the world of microservices, where you now have another…
Sure, you can write bad code using abstractions. Doesn't mean abstractions are bad or useless. There's just a lot of devs out there who don't write very good code.
There are also devs writing decent code but too tightly coupled, making it much more difficult to develop the code further without first refactoring the existing solution. It is also often very difficult to refactor the solution because its parts are also very tightly coupled so you end up with a whole tree of changes you have to make before you can do the actual refactor you want in order to make the actual change you wanted to do in the first place.
Re: Why I Hate Frameworks (2005)
#325Earlier quoted context omitted.
You could argue that algebra was a precursor of calculus and that basic operations were precursors of algebra. This is a rather reductionist argument. They hadn't even invented zero or algebra when they found ways to produce square roots or that you could make interesting ratios from the sides of a triangle (yes, I know about the history of zero and that is a slight exaggeration, but no symbol for zero existed in Mes…
Most people who take trigonometry (or "precalculus" as they usually call it today) couldn't tell you anything about limits let alone derivatives, integrals, and the fundamental theorem of calculus. And to those people, the calculator is a magic “black box” that spits out cosines. My original point stands: if you are using a tool professionally you should understand how it works, at least on a basic level. For a calcu…
Did you know that lots of calculators (including the famous TI-83) actually use CORDIC and that the basics of that method predate calculus by a hundred years? Did you fully understand your tool? Did that keep you from using it?
If you know the purpose of a trig function, it doesn't matter HOW the answer is calculated so much as that you know the answer is accurate. This doesn't require calculus.
I took calculus. As an engineering major, I actually had real-world applications of calculus across my coursework. How many times have I found calculus essential outside of college? Surprisingly few. Meanwhile, I've found a LOT of use for trig or linear algebra. There are things where the underlying theory is very important, but in my experience, this is not one of them.
Re: Why I Hate Frameworks (2005)
#326I will give a counter point. I love well-designed opinionated frameworks. Whenever I want to do something simple, I agree that a framework may be overkill. A micro-framework is nice for those scenarios though. However, whenever I build a project that will be maintained or extended by many people, opinionated frameworks give me the advantage that they force you to do things in a particular way. Django is a perfect exa…
> When you add a project that is built from scratch without using a framework that has strong stances on how files should be organized, all bets are off. You have to spend a lot of time trying to wrap your head around the custom abstractions that have been built - and it is hard to argue that some of that will translate to a different job.
I've worked in projects like this. In most cases, they contained what amounted to a part of a framework. The catch in the ones I worked on is that the authors had not realized they were building a framework and so did not think through their division of functionality, cross-cutting concerns like logging, and so on.
Inevitably, each of those had started as simple project. Over time, they had accreted one easy add-on after another. Eventually they're large, complex, and difficult to work on for anyone who didn't create them.
It's been my experience that most projects tend towards complexity over time. A well-chosen framework will require a bit of complexity up front to get going and provide a lot of options you can integrate as your needs grow. Preferably while letting you focus on the specific things you need that are different, rather than having to think about how you want to do logging and so on.
Re: Why I Hate Frameworks (2005)
#327Earlier quoted context omitted.
"Libraries and frameworks rarely tell you when they’re buggy messes." GitHub Issues usually gives you a good insight, into what problems exists and whether they get fixed, or not. (as a senior, you likely know, but others reading this, maybe not)
Github Issues is full of confounding factors though. Lots of Issues mean that there are bugs but all software has bugs. It also means that there lots of users and that users feel that raising an issue is a good way to get something fixed, which is good! IMO the better metric is how many outstanding unmerged pull requests exist. If there are too many this means that bugs exists and they aren't getting fixed.
I did not say the quantity of issues matters.
And people can do lots of weird PRs that do not get accepted as well. Code quality, obscure features implemented, etc. but it can be hard to figure out what is what, so they might just sit there open for some time, that is not ideal, but can still mean the code base is solid. For me this is easier to figure out in the issues/discussion page. (And reading the actual source and documentation)
Re: Why I Hate Frameworks (2005)
#328Earlier quoted context omitted.
The carpenter doesn't need a degree. The architect and structural engineer do. If you plan to be a programmer all your life, and a journey-man one at that, then feel free to learn-programming-in-21-days. If you're planning a career in software, then I think understanding fundamentals (database normalisation, the Order of a solution, the ideas of Coupling and Uncoupling, memory usage versus performance, the impact of…
The way I like to explain the difference between the two approaches — and therefore the two educational requirements — you are outlining here is the difference between being a software developer and a software architect. A software developer is focused on developing a certain feature or fixing a certain bug within the context of an architecture that's already determined, rarely making decisions about how to structure…
I don't think it's feasible to have 1 decent developer micromanage a team down to the function and data structure definition. At that point it's faster to fire the lot and just let the one developer you have do the job alone.
Re: Why I Hate Frameworks (2005)
#329Earlier quoted context omitted.
The carpenter doesn't need a degree. The architect and structural engineer do. If you plan to be a programmer all your life, and a journey-man one at that, then feel free to learn-programming-in-21-days. If you're planning a career in software, then I think understanding fundamentals (database normalisation, the Order of a solution, the ideas of Coupling and Uncoupling, memory usage versus performance, the impact of…
You have such an idyllic view of the college environment. My experience was struggling to motivate my teammates to do anything beyond the minimum, and an endless barrage of "will this be on the exam?" questions during class. Looking back it's no wonder I am a self-learner now.
In my BS I had just 1 team project, so it wasn't a big deal.
In my master I had more… and yes there were people who didn't do anything, people who did much more than me, people who were good at writing reports but needed intervention because ultimately they didn't even understand what our project was about.
I asked the professor once to dump a guy, because he said we should meet on a sunday morning to do our assignment, then he showed up 2 hours late, I was almost done with it, and he started by reading the 1st slide of the 1st lecture (with the name of the course, the email of the professor and so on).
Re: Why I Hate Frameworks (2005)
#330I remember following up the Angular tutorial. I was about 15min into the tutorial, and I was already editing 8 different files. I never got lost so quickly. I lost a job because I could not use angular, but never felt bad about it. I remember somebody commenting here on HN about a developer conference, where the speakers were bragging about their software being complex. This is an awful trend with software, and is re…
This is why React won: No template language to learn. No prescriptions for managing your app. No piles of abstractions to do basic things. It's just a UI lib. Import it, declare what to paint on-screen, done. Oh, you want routing? "Not my business", says React. Go add a routing library. You want a framework for managing global state? Go find one. Want a kitchen sink frontend solution which bundles all of these common…
I find implementing certain common things in react to be a pain, such as state management and route guards.
Vue is similarly unopinionated, but it is more intuitive to my particular brain.