Before we dive in to the reasoning behind this title, let's set up some base definitions for the discussion:

Startups - The startups I'm referring to are small startups. If you will, up to 8 persons in the tech team. My claims might be valid for bigger teams, or even big companies depending on their organizational structure. This will be better explained on the reasoning.

Startups kind - There are many kinds of startups, and my claim can't possibly be relevant to all of them. I think my claims are more relevant for the B2B startups that provide some dashboard to users, rather than B2C startups that might need to have higher priority on user experience that SPA methodology might provide.

JS frameworks - The important distinction here is for front-end frameworks that are fundamentally disconnected from the backend such that it requires providing the overhead of writing specific APIs to serve it. React, Vue, Angular and others are complying with this definition.

With those definitions out of the way, we have a common language to talk about my claims.

To be honest, I'm not having any "revolutionary" idea here. The basic principles against using an JS frameworks for front-end have been laid out by many others before me, just with different reasoning and perspectives.
One of my favorites in this regard, is a talk by Sam Stephenson from basecamp on Turbolinks 5, which is basecamp's antidote to the JS frameworks craze. I highly recommend watching this:

My reasoning in this post will be, as mentioned, from a perspective of a small startup and why as a startup you shouldn't go with React or any JS framework for front end.

If not JS framework, what then?

This is the important stuff to begin with, that puts my reasons below into context. I'm not advocating to use vanilla JS as your framework, or any framework at all.
What I'm advocating for is a unified tool that will reduce friction between working on your backend and your frontend, and by that empower your so precious full stack developers to make their best work of delivering value for the business.

Examples for such unified tools are:

• Ruby on Rails with its integrated template system
• Django
• Phoenix
• Spring

The basic idea is to keep the mechanisms of backend and frontend closer together in a way that will reduce overhead and personnel involved in feature delivery for communication efficiency.

Eliminate friction for feature delivery

When you are small, time to market is everything. Validating your ideas, their feasibility and their utility in the real world is important.
When you are dealing with providing to businesses, especially at initial phases of your company, you need to focus on business value given more than anything else.

To do so continuously, your need to lower the friction of providing business value quickly. And not using a JS framework might be just that.

Let's take react as an example.
To master react and be able to deliver on that platform a developer have to master:

• The JS environment (npm/yarn, node, etc')
  • Which might be an extra load if the backend is in non-js environment.
• Functional programming concepts (for pure components, why redux reducers are like they are)
  • Which I'm all for, I love functional. But if the developer works on Rails or Spring, he needs to now be functional and OOP at the same time.
• React crazes (OMG what are those hooks things? the last library I need only demo in hooks so I have to learn either way)
• React ecosystem (redux or mobx? react-router)

A developer have so much focus and attention. Expecting him to be good with react comes at the cost of other things:

• His mastery in backend engineering
• His mastery in frontend by itself, you know, the actual front CSS & JS
• And basically everything else he does not spend time with

That's alot to pay for. Just for potentially having smoother transition between routes by having a SPA. Or put on other words - too much payment for UX in a B2B environment where business value delivery matters more.

P.S - even worse proposition is to not to have fullstacks on the company, and resort to Backend developer and Frontend developer separately. Thus, introducing the overhead of personnel communication for every feature when you are a small startup. Yicks.

Not committing to APIs internally

When you are separating frontend and backend, you must provide APIs for the frontend to use.
Doing so early on in a startup life might be problematic. It is another point of friction, and you might find yourself committing to APIs that should die.

People also tend to use the APIs where they are not fitting, to "save" extra work.
And don't let me get started about the API design. Even if you are an expert in this field, designing an API when you are not yet sure where your business value really is? When you are still iterating with customers? This is the fast route to legacy code and code debt where you have APIs giving you a banana attached to a gorilla and a whole jungle, while you only needed the banana but some other part on the system depends on having the gorilla in this API too.

What is the long-term plan?

As a CTO, I spend alot of time thinking about this kind of stuff specifically, creating strategies for the company.

In short, what I would do in a B2B environment would be:

1. Start with a unified framework such as rails/django/phoenix.
2. Iterate quickly on business value features, usually that one developer can take full responsibility for. MVP style.
3. Keep iterating until something is a clear winner in the market.
4. Grow it as much as possible.
5. Be aware when you outgrew the environment - either that frontend is so important by now that you need a specialist in this field alone anyway, or that the engineering is too messy in the unified framework.
6. Use the Strangler pattern to move modules to an adequate JS framework.