[throwaway284962]

> 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.

[dagw]

Of which you are the creator and expert

No, I'm not. The guy who quit 2 years ago was. I've worked with custom frameworks, and while they where both clever and powerful with some quite cool features which would have been tricky to do in a more generic framework, they where also virtually undocumented, fragile, difficult to extend and slow to get people up to speed on.

[spion]

Building a library or a framework comes with implied obligation to write extensive documentation. I wish more software engineers understood this.

[jarek83]

> 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.

[coldtea]

If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework.

Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.

[amenghra]

This. And you’ll feel lost or sub-productive while you ramp up on the new company’s bespoke framework.

[slifin]

Unless you're in a library driven ecosystem like Clojure in which case the majority of interesting code is just calling into a library

Yes you still have to know how it's glued together but at least there is still standardisation whilst still being flexible enough to swap individual libraries

Not a perfect solution but a good compromise in my experience

[randomsearch]

That’s why I always start a new app by writing my own operating system for it first.

Use frameworks, use libraries. They will save you time, make your code less buggy, make it easier to hire other people.

Writing your own ball of mud is great for a hobby but not for business.

[throwaway284962]

I started using a framework for a task at work, was immediately tripped up by an obvious stupid bug in the config files, reported it and it was closed because "too many people already depend on this behaviour". So now I've in-sourced other companies legacy and taken on a huge liability in depending on the evolution of undefined number of other organisations and their code bases.

And even worse when these frameworks are open source and don't even have any accountable people at all, and god knows how many people working professionally are suddenly held hostage by some dude who just felt like going backpacking in south america for 6 months without giving any notice to anyone.

[dstick]

Speaking purely about web software / web APIs, most software is 90% CRUD. It absolutely makes sense to use a framework to save new hires from grokking 90% of it's capabilities. You can have a new developer do stuff right out of the gate.

[glroyal]

Isn't that the real, unspoken purpose of a framework?

To commoditize a critical (and formerly well compensated) skill for the purpose of outsourcing it to the country with the cheapest possible labor?

[camgunz]

This is one of my hobby horses! I'm disclaiming my bias upfront so I can try and have empathy for your position, but I strongly disagree with this line of thinking. I've been thinking a lot about this personally, and I think I would summarize my argument as "a lot of engineers think they're building beautiful, bespoke palaces, but in truth they're building regular houses, which is actually more important in the macro, but should be boring in the micro".

I broadly agree with GP here, but to round out some of their points:

- Frameworks take care of the parts of your application that aren't special. In the same way garbage collection isn't the value your company provides to customers, HTTP header parsing (or whatever) isn't either.

- Frameworks prevent your team from diving down architecture rabbit holes, or having to read a bunch of books on DDD, or what have you. This sounds like a small point, but if you tracked the number of expensive engineering hours spent disagreeing about where code should go, look like, and work, you would realize it's a pretty big one.

- Frameworks are tested way better than you ever could by thousands of users, actually documented, contain compatibility guarantees, and have security policies. To match this quality, your company would probably spend millions of dollars on eng hours. That's why company-specific frameworks don't match this quality.

- Frameworks make onboarding way easier. Most Python engineers know Django; most Ruby engineers know Rails. By definition, you can't hire engineers that already know your framework (even if you use something like Hexagonal, because no two implementations of this are alike). And again, because your in-house framework will be poorly tested/documented/etc., new hires will struggle. They'll also wonder if this is a career cul-de-sac: "I have 4 years of irrelevant experience in [bespoke framework X]" is not an enticing resume bullet.

> Your software is custom made for your organisation, it's not mass producing identical systems on an assembly line

This returns us to the palace vs. suburbs framing. The software you write is a super small percentage of the code that runs your app, all the way from firmware to CSS libraries. Good engineering is carefully deciding what code you will write yourself, because code isn't just implementation, it's design, buy-in, maintenance, documentation, and liability. Some enterprises are replacing a big chunk of that stack (Oxide or Cloudflare come to mind), but I bet 95% of companies are just building REST/GraphQL servers. That's not special enough to require a custom, in-house framework. You should just build the house the regular way.

[silversmith]

You not only are in control, you HAVE to be in control. Nobody else will patch holes, optimise or deliver new interesting features. You're on hook for all of that.