> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework

Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that already knows the tools for your framework. You'll be spending all of the next eternity cobbling together features that you could have had out of the box had you adopted somebody else's framework instead.

The choice is never "use a framework" vs. "don't use a framework". The choice is "do we use somebody else's framework" vs. "do we build our own framework". What you implicitly and unknowingly chose was the "we are gonna build our own framework" option.

In my experience, the minute the few folks who pushed the "no framework" option leave the company, all the rest of the developers smile and scramble to replace the hot mess of a codebase with something using an industry accepted framework.

i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support.

before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a tension between "not-invented-here" and "borrow-buy-build" camps. NIH would stress that all components in our designs should be in-house (electrical metering, data acquisition, etc) while the BBB camp would turn every effort into a 3rd party integrations exercise. at times this even applied to the factory floor. i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."

> i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."

I mean, how hard could building our own pick & place be, right? Once you strip out all the bloat the vendors add to make a sale, it is nothing you couldn't do with a couple servos and a $5 Arduino, right?

I think the "build everything ourselves" attitude comes from a not at all understanding opportunity costs and comparative advantage. Plus in the software industry, tons of developers I've encountered are super paranoid about "vendor lockin" without realizing that once they roll their own library/framework/pick-and-place-machine they have effectively locked their employer into a vendor as well. Only instead of a third party vendor with all the benefits that may come with it, they've "purchased" a product from a really shitty vendor--themselves!

It is never a choice between:

"Platform or no platform"

"Framework or no framework"

"Vendor lock-in or no vendor lock-in"

You will always be on a platform. You will always be using a framework and you'll always be locked into a vendor. The trick is to make sure you don't lock yourself into a shitty vendor who makes a shitty platform or framework.

Not directly related to web front end but having extensive developer experience I tend to shy big frameworks (with a couple of exceptions) . Instead I am using set of battle proven libraries that change depending on needs.

My reasons are:

  I do not need to learn a monster
  If framework goes down/becomes unpopular etc. etc. I could care less
  Libraries are easily abstracted and replaceable.
  

Yes I/team do end up implementing our own framework but this framework is very tiny comparatively to you common monstrous frameworks and any sane person can get a grip in a day or less and it only has enough to accomplish a project.

Also it can be easily sliced/diced and needed accumulated bits and pieces can be used for next project.

> A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation.

But there are gains too. The custom framework is probably much smaller and less complex, easier to know 100% of. It can be stepped through in the debugger. It's much easier to change and add features that your company needs, there's no outside bureaucracy to get in the way.

I disagree you're inventing your own framework too, there is a distinction to be made between libraries and frameworks. Just because I'm not using a framework doesn't mean I'm reinventing it, I could be using something like knockoutjs instead, or even postbacks.

Mark my words, you’ll be spending the rest of your days poorly reinventing what was already done in a real framework. I’ve seen what comes of these “I don’t want to use a bloated framework” shops and it is never pretty. The second the people who eschew mainstream frameworks leave, the devs who are still are around will quickly rebuild around a real framework.

React, Vue and Angular can all step through debuggers.

In my experience, when it comes to rich interaction, the question isn't whether or not to use a framework -- the question is whether to write your own framework from scratch and discover all mistakes you can make on your own, or use one that already exists and builds on best practises as well as we know them.

  In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.

Though it is possible to overengineer this, you're probably underestimating ho seemingly simple apps can justifiably have complex state.

Say you make API calls. Your application state just grew to reflect

1. Pending request 2. Request succesful or failed 3. Request result or error 4. Finished request.

Redux apps track all of this explicitly. The alternative to this is not reducing statefulness. It's just ignoring it with all the brings.

Oh I agree with that, I just think that the internal state of the app can be more easily managed if those potential application states are explicitly identified during the design stage.