Using a framework will harm the maintenance of your software • Hacker News Board

Re: Using a framework will harm the maintenance of your software

#221

Post by Kiro » Thu, Oct 13, 2022, 7:00 AM UTC

couchand wrote: post #36

a4isms wrote: post #17

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…

The author carefully distiguishes precisely what type of framework they mean. The definition includes multiple parts, but the part that really stands out to me is that a framework dictates the overall flow of control. The suggestion in TFA is to ensure that you consume your dependencies in a decoupled fashion, a move toward utilizing libraries rather than following a framework. I've spent lots of development time in…

> TFA

That was uncalled for.

Re: Using a framework will harm the maintenance of your software

#222

Post by herr_gurke » Thu, Oct 13, 2022, 7:01 AM UTC

huimang wrote: post #211

Most sufficiently complex codebases that aren’t “framework” based will have a poorly implemented, feature-lacking, bug-ridden version of a framework eventually. If Django doesn’t fit the use case for your thing, don’t use it? Just don’t use flask and then start reimplementing Django. Also, Rails is better Django. It’s not even a close comparison.

The issue starts if you start with Django, but later on you discover that there it does not support your use case anymore.

Re: Using a framework will harm the maintenance of your software

#223

Post by vidarh » Thu, Oct 13, 2022, 7:01 AM UTC

flohofwoe wrote: post #210

inopinatus wrote: post #76

Earlier quoted context omitted.

> perhaps all of them (every single one) have not actually experienced writing an application without a framework I actually have written software without a framework, so by this standard I feel qualified to comment. Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the la…

> Not all software has an implied framework within it. Most Unix command-line utilities do not, for example, with only a few exceptions, and discounting the C standard library as something worthy of the label “framework”. The C standard library is exactly that though, a framework for writing UNIX command line tools :) (for anything else it's much less useful)

> The C standard library is exactly that though, a framework for writing UNIX command line tools :)

It doesn't fit the term as used in the article at all, though, in that it doesn't dictate the overall program's flow of control.

Re: Using a framework will harm the maintenance of your software

#224

Post by BlargMcLarg » Thu, Oct 13, 2022, 7:03 AM UTC

m00x wrote: post #209

throwaway0asd wrote: post #73

Earlier quoted context omitted.

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. After 25 years of experience writing software I can honestly say I have encountered many people that agree with this, and perhaps all of them (every single one) have not actually experienced writing an application without a framework. This sentiment sounds correc…

Maybe you should master your tools before using them. You can use frameworks where they fit, and not where they don't. Knowing when to do which takes time and experience, but it is definitely do-able, and better. Frameworks allow you to update, and maintain your app for free, since others will do it for you. If you do it yourself, you have to do all the work and that's keeping you from adding value elsewhere. To not…

>since others will do it for you

That's the big caveat. Loads of frameworks leave clear issues dead in the water. Your team/predecessors weren't the most clean. Now have fun fixing that one issue working out a framework you can't easily modify or switch out.

Of course that problem isn't unique to frameworks nor inherent to framework rather than social and legal problems.

Re: Using a framework will harm the maintenance of your software

#225

Post by throwaway284962 » Thu, Oct 13, 2022, 7:06 AM UTC

a4isms wrote: post #17

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…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework.

Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time.

If you use a framework your organisation becomes incredibly complex, because you are now actually competing against the needs of other companies, your competitors, which are also influencing the framework.

Your software is custom made for your organisation, it's not mass producing identical systems on an assembly line, so it doesn't make sense to share a common platform like you do with cars. And even if you did, this platform would be a joint venture, and absolutely not made by a subcontractor, and no way in hell some random unpredictable volunteering hobby organisation.

Re: Using a framework will harm the maintenance of your software

#226

Post by herr_gurke » Thu, Oct 13, 2022, 7:06 AM UTC

gonzo41 wrote: post #171

It's been a whilst since we've had one of these on HN. What a bit of fun. My 2c. There's a choice about the work you do. does your work satisfy a business requirement, or does it satisfy your ego. I need a site for work for a 3 year project, CRUD, users, auth, sessions. Django's perfect for my team of 1.5. It wouldn't be responsible to roll my own, when I can have the bare bones of that site up and ready to go within…

I did some Django but in the days, and I completely agree that as long as you have CRUD, Django shines. The issue starts when you cannot really fit your uses cases into simple CRUD and you start to fight against the framework to achieve this.

The author also made a point of negligible gains - even if you spend a week to setup auth, sessions etc. if still negligible for longer running projects

Re: Using a framework will harm the maintenance of your software

#227

Post by o_m » Thu, Oct 13, 2022, 7:07 AM UTC

Most developers only have a two year horizon, and they are always thinking about the next job. If you learn some proprietary software it will hurt your chances to easily switch jobs in the future. So you end up choosing the company that uses the framework you believe you're going to keep using at your next job.

Re: Using a framework will harm the maintenance of your software

#228

Post by jarek83 » Thu, Oct 13, 2022, 7:09 AM UTC

throwaway284962 wrote: post #225

a4isms wrote: post #17

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…

> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you a…

> Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time.

And then you change a job and you take 80% knowledge with you and your now-past project is in deep trouble.

Re: Using a framework will harm the maintenance of your software

#229

Post by thom » Thu, Oct 13, 2022, 7:09 AM UTC

hinkley wrote: post #179

Joel_Mckay wrote: post #169

Earlier quoted context omitted.

I find it highly improbable you have never encountered a Facade pattern. ;)

One of my goals this winter is to clear my head of as much OOP dogma as I comfortably can, fill it with as much DevEx thinking as possible, and read Christopher Alexander, A Pattern Language, from that frame of reference. My very hot take is that we will start referring to everyone who bought first editions of the Design Patterns book as the Lost Generation, because we have completely misinterpreted Alexander's work,…

I’ve read the original and was underwhelmed from a software epiphany standpoint. Design patterns are just names for deliberate design decisions, so you can communicate them to others who can then deliberately make those decisions themselves. Half the industry still seems to think the GoF book is about C++ not having first class functions.

Re: Using a framework will harm the maintenance of your software

#230

Post by coldtea » Thu, Oct 13, 2022, 7:10 AM UTC

a4isms wrote: post #17

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…

>1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework

Every sufficiently complex built-on-top-of-a-framework application contains an ad hoc, informally-specified, bug-ridden, slow implementation of workarounds to the framework's limitations, the overhead of parts it doesn't need, a nightmarish dependency situation, and as a cherry on top, it ends up based on a previous version, of the framework (as the latter's creators rewrite with different APIs every couple of years for no good reason).