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:
- Start with a unified framework such as rails/django/phoenix.
- Iterate quickly on business value features, usually that one developer can take full responsibility for. MVP style.
- Keep iterating until something is a clear winner in the market.
- Grow it as much as possible.
- 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.
- Use the Strangler pattern to move modules to an adequate JS framework.
Top comments (8)
Thank you for the post. I entirely support this opinion. Working on several projects (Vue, React) often we spend more time generating tons of code for relatively simple functionality. Serverless web applications make development process more complex compared to classic web development.
Please, don't consider it a spam, but actually, I am trying to solve this issues for half a year now, check out Frontless.JS. At the time, this is my main tool for building MVPs and internal dashboards.
A team should use the tools they are the most productive with and for many that could be React, Angular, NodeJS, etc. I don't think microservices are a great way to start but productivity is determined by expertise, not frameworks.
In our startups we did exactly the opposites, and now we're paying for it with the high cognitive load of maintaining several subsystem with our limited number of developers. On the flip side, when we develop it with one person in the frontend and one in the backend it really helps with the speed (it may be because they were already experienced in working together).
And after reading your article I agree with your views, especially when we're starting out.
Btw I'm curious as to why you didn't list laravel with blade in your list?
This is exactly how we build ExamPro.
It wasn't because we didn't know how to use a javascript framework it just doesn't make business sense.
It's like playing SimCity and blowing your initial budget a superhighway.
Not really seeing why only B2B startups should not use a framework. Eventually a small team grows into a large team are you saying that they should rewrite software and adopt frameworks down the road?
Oh, it is not exclusive. It is just that my claims here and the perspective are more relevant to B2B startups. And even then, not to all of them but surely to most of them.
Other startups can use this strategy, but it depends more on the context. Usually when it is a B2C company, the UX might be the reason a product will success/fail. So it's harder to generalize there.
overgeneralization.
a) there are different requirements. For example, startup which was providing web client in the field (literally), they were forced to use web-workers, because people worked with it without internet from time to time
b) use whatever you know. If your team knows frontend framework and productive in it why not? Rails (REST API) or Hasura (GraphQL) as backend and some framework as frontend.
Maybe a beginner question - but wouldn’t using Node.js with EJS for templating be a unified framework? Or is there something you don’t like with the JS/node ecosystem?
I agree with your thinking since I’ve used a React front end and Node backend for a MVP since it is what I knew (I consider myself a junior dev tho) and it is a lot of work to make “simple” updates due to the complexity of having the front end and back end separate. Iteration isn’t as quick as I’d like as a solo dev/founder (esp with the non-coding work you have to do!). With hindsight I would’ve just went straight Node.