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...
For further actions, you may consider blocking this person and/or reporting abuse
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.