> If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you.
Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal.
Fixing that bug is much more difficult if that person is in an outside organisation, serving many other customers on the same code base (with possible conflicting needs), and/or is not actually in any way accountable for it (open source).
> Which is not so difficult, because that busy person is in the same organisation as you
Hopefully. But not necessarily. This argument is spinning in circles.
In house projects can be abandoned just as oppen-source ones can.
For me that was Powermock for example.
> Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal.
{evil laugh.mp3}…
Ideally yes but in reality: all teams have bottlenecks, and nearly all teams have assholes. Is fixing your problem on their OKR or whatever.
Free / open source code can be fixed by anyone: the volunteer owner (who you could even bribe to fix it), any contractor with experience, or someone in the org. This is the beauty with free software. It enables people to fix their printer drivers even if they didn’t write it originally.
Free / open source code can be _forked_ by anyone, but in doing so one often takes on a maintenance burden bigger than one's current codebase.
To have a fix accepted on an OSS project means fixing it not just for your use case but also for every other user of the project, on every target platform, while aligning with the goals of that project. If you can get anyone to look at the PR in the first place. Assuming you've used the framework to save time, you probably don't have time to go through all that and your deadline will not wait a month or six for your code to make it into a release. Depending on your employer you may well need internal permission and legal sign-off to contribute to an OSS project in company time which is yet another hoop to jump through; though that goes for forking too.
> 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.
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.
I'm confident most software engineers I've worked with understood this. Usually the problem wasn't understanding that but rather meeting the deadlines and finding the resources to write that documentation. The only time I've seen documentation done really well, the company had a dedicated technical writer whose main job was making sure they had good documentation. Engineers would write the first draft and hand it off to the tech writer. My impression is that many companies don't want to spend resources on that level of documentation, which is the level you'd probably want to roll your own framework.
I meant it "part of the job" the same way unit tests are.
I see this more often when the project is open source. For some reason we feel like when its not, we don't need to pay attention to the documentation. Nothing could be further from the truth.
> 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.
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.
These are generally just resource issues. Companies generally won't pay for engineering hours to build really good framework documentation. It's not in the critical path. Companies that know that documentation, as well as tests, compatibility guarantees, security policies, etc. are actually critical components would probably not ever make the decision to take on that engineering burden themselves unless it were a business differentiator, which it almost never is.
> 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.
In my experience this has been a point in favor of OTS frameworks--the code you don't care about is handled by the framework, and you bring the business logic. But also, reading through this, I guess I don't understand your comment. Isn't the business logic in the code? How can a person take it with them?
> In my experience this has been a point in favor of OTS frameworks
Its not guaranteed. I've seen many developers spend lots of time trying to get the framework they're working in to cooperate or dig through bad documentation. Framework authors are fallible too and general-purpose software is really hard to get right.
Well, my point here is that even if there are little patches against a framework, we're talking something like 5% of the repo's code is framework-y stuff. If you've got your own framework, then... what even is the limit? 50%? 90%?
I wonder if some of the disagreements in this thread are just like, people in favor of frameworks used Rails/Django, people against them used Spring/Struts.
> Framework authors are fallible too and general-purpose software is really hard to get right.
Yeah, I think that's solved by the "market". There was a big explosion of Python frameworks in the aughts: TurboGears, CherryPy, Pyramid/Pylons, Zope, web.py, etc. etc. Lots of stuff. The ecosystem now is Django/FastAPI (Flask/Tornado legacy apps are either stuck or moving to FastAPI IME). Django got it right.
But more broadly, what are the odds a bespoke framework will do it right? Will you think up a new way to organize controllers, or to abstract auth, or to manage database sessions, etc. etc. etc. That sounds like a nightmare to me; just let me focus on the business logic please, haha.
The market will settle on "good enough for the average usecase".
> But more broadly, what are the odds a bespoke framework will do it right? Will you think up a new way to organize controllers, or to abstract auth, or to manage database sessions, etc. etc. etc.
Some of this is a nightmare indeed (e.g. dealing with any web security stuff). Other things are very straightforward, especially when you don't have to deal with 1000 other people's use cases but only your own.
> just let me focus on the business logic please
We all want this. The question we should be asking is do we spend more time fighting a 3rd party framework or implementing our own. The answer may well be we'd spend more time implementing our own - but its still important to be aware if things start to go south.
> Other things are very straightforward, especially when you don't have to deal with 1000 other people's use cases but only your own.
> ... fighting a 3rd party framework ...
Can you give some examples of this? I'm personally finding it hard to come up with examples where this is a significant problem. The closest I can get is I worked on a Django REST Framework project where we went all-in on serializers, but then ripped it out because performance wasn't where we wanted it to be. But it's pretty easy to not use serializers in DRF, so it wasn't actually significant.
- Fighting webpack (its plugin system makes it a "build framework"). Lots of configuration complexity to support thousands of possible tool configurations, when you need only one combination.
- Angular v1. Scope, transclusion, watchers, directives, DI and things randomly breaking.
- Almost all of the modern devops configuration tools. Would be easily replaced by some very basic typescript functions / libraries and Deno. In fact, cdk8s (which is typescript) comes with a mandatory jsii layer included, adding about 150MB of node_modules. This layer translates between the TS API and other languages you might use (Python etc). You get it even if you don't use the other languages and it has measurable impact on e.g. CI run times
- Bazel (another "build framework"). You just wanted some basic build caching, but get to do all the work for perfect hermeticity instead, which includes things like different directories, dealing with symlinks and dealing with tools that handle those symlinks poorly.
Its really, really easy to pick the wrong tool(s).
Yeah, I definitely see what you're saying here--I think a lot of people have had really frustrating experiences with these tools (even though I might quibble about them being frameworks).
But is it a reasonable alternative to build an alternative to webpack yourself? Or Angular? I would bet some people have tried/done this, and also have some frustrating experiences.
My point is I think you have to be _very_ careful when deciding to take on a big engineering project, like making your own JS build tool. Will the improvements in devex really outweigh the engineering hour investment? IME the answer is almost always no, what usually happens is you get a half-baked, non-documented/tested system, and reading through this thread, I'm not sure any of the anti-framework people have shown convincing examples where they did better than an OTS framework.
Or if they did, they released it! Django is famously one such instance, or your Bazel example. It seems like they bet right, or did a lot of off-hours work (pretty sure that's the case w/ Django haha) to get it going.
> But is it a reasonable alternative to build an alternative to webpack yourself?
Before code-splitting, yes, it was quite easy (not much harder than building a makefile). Webpack is difficult and complex because it has to cater to literally thousands of tools (https://www.npmjs.com/search?q=webpack%20plugin). An individual project can choose to use a simple js-only bundler and a copy command for static assets.
There was nothing to release there, however - we just wrote the equivalent of a makefile. It was not a big engineering project at all.
Would I do the same thing today? No, because of code splitting and because there are simpler, faster bundlers out there already (esbuild).
> Will the improvements in devex really outweigh the engineering hour investment? IME the answer is almost always no, what usually happens is you get a half-baked, non-documented/tested system, and reading through this thread, I'm not sure any of the anti-framework people have shown convincing examples where they did better than an OTS framework.
This is, where I think we differ. I think much more often than not, we already have half-baked, poorly documented systems which we insist on trying to use, even if the team is quite capable of building something better. This is also one of the reasons we have JS fatigue - its not because the language or even the browser somehow prevents something better from being built, its because we keep insisting on using poorly designed tools or tools designed to solve problems that large companies have but we don't really have.
Well, business usually don't have that comfort of spending money on this when there is much cheaper alternative. Aaand they can hire experts in a framework instead of an engineer that would have to be learned the custom stuff and could eventually say that he doesn't like the stack and would build his own...
I'm not sure why you would describe the entire real world as "problem". Because this is how the real world works, with organizations where the last knowledgeable guy was fired two years ago and now discovers they need to touch that incredibly useful and huge application he wrote ten years ago. I'm aware there's an entire book industry telling how the ideal world should look like but there are also unicorns in every fantasy book yet nobody would judge you for not herding a couple.
It will always happen to a degree anyway. The more people are experts because of specifics to this company, the worse. Using a framework also improves hiring.
> If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework.
You are both right and also describing every single company I've seen. I haven't worked in a straight up software company, though. Maybe they have things better.
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
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.
Build everything in-house or be beholden to some dude going backpacking is a false dichotomy.
It'd be like saying I always make my own food from scratch — have you seen the state of the burger van down on the corner? You can't trust food made by others.
All frameworks aren't created equal — as with any tooling, you choose something based on the features of the framework but also the longevity, reputation and ecosystem built around it.
Thank you for this common sense reply. Can you imagine someone wanting to roll their own Flask? Their own React? It's like most people here seem to be siths and only deal in absolutes.
Yeah, but this has other trade-offs than the other two options of just using a 3rd party framework and inventing your own. Not saying that this is not viable though.
Then your architect needs a fresh course in how to decide what open source project to use.
When its a critical spot you first check how it is maintained. Its that easy.
Yeah but isn't this example just a trivial config bug? We're not talking about core functionality here. You're extrapolating from a minor nuisance to "a huge liability in depending on the evolution of undefined number of other organisations and their code bases" which is quite a leap. Just do config the way everyone else does; again it's not a differentiator.
Thinking about this case more, this is exactly what you want from frameworks: compatibility guarantees. Frameworks break compatibility, but deliberately and slowly. Will your in-house framework do that? Will it announce and well document its intent to deprecate functionality in favor of new features? Will it find all the users of it across your enterprise and work with them on migration strategies? Will it build in deprecation notices for literally years? Will it build in tests for the bridging changes? Django does all of this, for you, for free.
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.
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.
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.
