I interviewed at a company late last year that was having a lot of trouble on the front end.

Their apps were unmaintainable. Code quality was poor. Build processes were slow and messy. Nothing was really standardized.

They knew they had a problem, and were looking for a senior engineer to come on board and help get things pointed in the right direction – but they also had a few ideas of their own on how to fix things:

“We’re gonna switch from [Framework X] to [Framework Y]”

I immediately knew that I wouldn’t be able to help, because as an organization, they fundamentally misunderstood the root cause of their problem.

Blaming the Tools

There’s a line of reasoning I see all the time, and it goes something like this:

“The app is bad and we built it with [Framework X], so [Framework X] is bad”.

This kind of logic seems to be pervasive among front-end developers right now, and I think it’s really, really dangerous. Rather than thinking critically about application design, we instead look to frameworks to solve all of our problems.

I’ve actually seen a company switch from Backbone to Ember. Then from Ember to Angular. In all likelihood, they’ve switched from Angular to React and Flux by now.

Don’t get me wrong, there’s nothing wrong with changing tools. Each have their strengths and weaknesses, and they need to be evaluated on a case-by-case basis against the objectives of your project. But you need to be clear on why you want to switch, and which pain points you’re trying to alleviate.

I’d submit that if your app is still a disaster after the third switch, then maybe the problem isn’t the framework.

Making Decisions is Hard

My personal take on all of this is that many developers are either unwilling or unable to make difficult choices about application design. So instead, they look for a framework to make all the choices for them.

But the kind of choices baked in to even the most opinionated frameworks aren’t the ones that will make or break your app.

I have yet to discover any library or framework so opinionated, so complete, so fundamentally correct in its core ideology that it can’t be used to make shitty apps.

In other words, they can’t save us from ourselves.

Engineers and Technicians

Okay, back to that interview.

There’s an important piece of information that I left out earlier: this was a rapidly-growing company, and they’d adopted a strategy of hiring very junior devs with [Framework X] experience in droves.

What they’d created was a team of technicians. Employees who knew how to operate the machinery of [Framework X] — but had no context. They lacked a fundamental understanding of the underlying concepts. And as a result, they often weren’t able to make informed decisions when confronted with a problem that their chosen framework offered no clear opinion on.

Anyway, my point here isn’t that junior devs are stupid, or that frameworks are bad.

My point is that by exaggerating the importance of frameworks, we’re ending up with an army of technicians and no engineers. By pretending that Ember or Angular can solve all of our problems, we give the false impression that simply learning the “right” framework is all you need in order to be effective. But it’s not.

What’s the Solution?

I’m not sure that I know, really.

But I think it starts with a much more honest discussion around what these frameworks can and cannot do for us.

More importantly, we need to place a much stronger emphasis on learning fundamental JavaScript concepts and principles of good application design. Unlike memorizing the API of some trendy new framework, that knowledge never becomes obsolete.

— —

Follow me on Twitter or Medium for more posts. I’m trying to write once a day for the next 30 days.

And if you’re in the Boston area and want to come work on crazy, top-secret things with me at Project Decibel, shoot me an email. I’m hiring.