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.

> Yeah, I think that's solved by the "market".

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.

The advantage is that I wrote it and am the foremost expert on how it works.

If it's a matter of training up other people, we're just as well becoming experts in a framework

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

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.

Theory vs reality.

Exactly. In theory a framework would solve that.

But I described the reality.

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.

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

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