[berkes]

To counter some of your counters, or, actually, to give some advise that I've learned along the way:

> - There's the potential for quite a bit of choice paralysis along the way as you assemble your stack

Yes. Which is why it is crucial to know software patterns, be able to research architectures and have (someone close, with) experience in making those choices - and seeing them fail. Frameworks are not a real answer to this, as they don't take away the need to make such fundamental choices: they just pull them forwards: it's the first thing you'll have to choose. At a moment when you lack all information and insight to make that choice.

> - It's harder to seek help: as you've likely assembled a unique collection of tools (and therefore encountered unique challenges)

If you stick to well-known patterns, mostly, there's enough help. Apply patterns to encapsulate, decouple and isolate all pieces. This way you avoid having to go to SO and asking "my Wordpress in a Docker with both FooFormsUltra(plus edition), EcommerceBarEasy, the MegaThemePlus with BootBulma subtheme, gives an error when I click on a red button". Instead your problems are either about what patterns to apply (which is high-level, well-documented) or with code in isolation (which means you can ask the library devs).

> - It's harder to onboard other developers

Again, well-known patterns can help. Counter is that even a senior hardened Rails dev will have a tough time on that legacy Rails project. In fact, to keep your Rails (ReactBoilerplate, Django) app onboardable over time, strict application of design patterns are the best solution. You'll need to spend time on this regardless.

> - There's often more bespoke glue code

This one I agree. In fact, if you Do It Right, your app will be mostly glue code. Especially the "boring parts" (like database setup, connecting, http handling etc). This is stuff that matters not for your domain and is best kept out of the way anyway. You really don't want the CLI-opt-parsing to get in the way of what your CLI app is doing anyway.

> - Smaller libraries often have a smaller community and a shorter lifespan

Maybe I misunderstand. But why does "no framework" imply "smaller libraries"?

[chaostheory]

The key issue is “if you do it right”. That’s easy to type, but hard to execute.

You’re essentially creating a private framework without public scrutiny which catches a lot of mistakes. That’s one of the main values of using an open source framework.

Are there times when a new framework is better than a preexisting one? Sure, when there are no frameworks that can meet your specialized project, but if it’s a typically CRUD application? Imo you’re better off with an open source framework.

[berkes]

> The key issue is “if you do it right”. That’s easy to type, but hard to execute.

Indeed. In fact, everyone, including said seniors, will make the wrong decisions, will "do it wrong".

So make sure the "do it wrong" is cheap. And the "do it right" compounds.

Frameworks make "do it wrong" extremely expensive. If, after four years, you find that Symphony really was the wrong tool for your highly event-sourced bookkeeping, there's little you can do other that turning your Symphony into a personal version of it, or Rewrite It In Rust.

Frameworks dictate far more than just the language and where to put stuff. They dictate how you test, how you host, deploy, how your team works, how long sprints can be, if scrum fits and so on. They get their tendrils in the entire project.

Optimizing for "cheap failure" and "compounding interest on doing it right", IMHO does not go well together with many frameworks.

[chaostheory]

> So make sure the "do it wrong" is cheap. And the "do it right" compounds.

That’s still really simple to type and hard to do.

> Frameworks make "do it wrong" extremely expensive. If, after four years, you find that Symphony really was the wrong tool for your highly event-sourced bookkeeping

1. It’s pretty simple to determine a framework’s architecture and design decisions a few months in, if not a few weeks or less

2. A “book keeper” application is such a basic commodity CRUD app, that it was exactly what a commodity framework was built for. Virtually every web based CRUD application is a conventional commodity.

Using a framework is optimizing for “cheap failure”. Creating your own inverted private framework feels like the exact opposite. All of the expensive mistakes possible with an open source framework, equally applies to your homegrown framework. The difference is that it took a lot more work and time to get to the same starting point.