Re:Challenging projects every programmer should try
by pipes on Tuesday December 26, 2023 @02:35PM
(#38775194)
Genuine question: what value was added by getting rid of the frameworks?
Re:Challenging projects every programmer should try
by jvanderbot on Tuesday December 26, 2023 @02:46PM
(#38775319)
20,000 fewer lines of code, faster compile / deploy times, significantly less interfacing / translation between "their" types and "their" apis, and a much better control over types and structure across our codebase b/c we didn't need "their" types and structure anywhere. It had crept everywhere.
It's just faster, cleaner, and easier in a few cases to do precisely what you need right now, rather than anticipate a million things you might need and refactor your code to adopt a given "solution".
Re:Challenging projects every programmer should try
by cellularmitosis on Wednesday December 27, 2023 @11:04AM
(#38783271)
Yeah, the problem / benefit is never the one framework you added / removed, it is the mindset of reaching for another dependency as a default which leads to a behemoth which no one enjoys working with.
Re:Challenging projects every programmer should try
by thomaslord on Friday December 29, 2023 @11:44AM
(#38806973)
I also think a person who has had to strip out or replace dependencies is more likely to be careful when choosing them in the future. This is definitely the case for me, at least.
Re:Challenging projects every programmer should try
by deterministic on Wednesday December 27, 2023 @05:48PM
(#38787807)
My experience as well. The more dependencies I remove, the fewer problems I have. It is a massive productivity boost.
Having said that, there are libraries there are high value/cost. So I keep those. But the dirty reality is that most libraries are pretty bad.
Case in point, I've spent a year excising bloated frameworks from my stack at work and replacing the few corners we needed from those frameworks with, e.g. 50 lines of curl calls. The C compiles instantly and is tailored for our tiny use case, produced much quicker delivery on our one related feature we wanted, and removed chains of dependencies.
Being reliant on far-too-abstract libraries and frameworks to do simple jobs is also a curse. But nobody at work has the experience to know that curl was sitting right there on our image available for our use. And nobody has that experience because nobody took the time to build something from low level libraries. Now we know how and can make an intelligent decision without defaulting in either direction because we were afraid to try.