Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
[2] https://github.com/ReactTraining/history/issues/804
The "defacto" today is to use React on top of a nodejs/Elixir/Go backend in a monorepo deployed across microservices in a custom kubernetes infrastructure.
Hope you read enough of this comment to avoid going this way, and prevent your team from going with this "defacto" way of doing things.
The above stack, which is what many companies are doing, is a total mistake in my opinion. It creates a LOT of work which is not related to your business.
It also involves a TON of discussions about how to do things, what state management library you will use, what router library, what ORM (oh wait, we favour no ORM in this language because ORMs are bad blah blah), what validation library you will use in the backend, what validation library on the frontend, a bunch of different testing frameworks (some for the backend code, some for the frontend code), a way to do CSS-IN-JS or similar, etc.
Moreover, those decisions are not something you can decide and be done with it. Those decisions come back every X months to bite your ass, because they get deprecated or their developers just moved to something else and just ignore you when problems arises (it's ok, they're not paid after all..). So you end up with some part of your system that now are unmaintained[1] [2]. In this world, things get quickly out of fashion, such as using classes for React components. Now despite they say in their docs it is perfectly fine to still use classes, this community is driven mostly by fashion, so nobody will want to use classes and a lot of time will be invested in rewriting perfectly working code into whatever the new trend is.
Then you have the equivalent crazyness at the infrastructure level. Teams of engineers playing with Kubernetes (because it is the React of the infra folks), which is a very low level tool, upon which they will build an TON of custom tooling and scripting and processes, etc,etc and cross your fingers so that they never leave your company because if they do, you'll be in a very bad situation. If you're lucky, you will end up with something which is about 25% of what you get from AppEngine, or any other similar service, except that an order of magnitude more expensive (because of the salaries of the people building this).
Let's not talk about all the work required to coordinate different services, document APIs from Backends For Frontends (TM), gRPC for communication between services because, hey, REST is overkill and non-performant, GraphQL which is the current trend and might not be tomorrow, etc.
I'm not saying all of this is useless and wrong for every situation. Those tools are great and serve in the RIGHT context. If you're a big company, with tons of employes, it is better to have to do more work if that allows you to split the work across people.
In a startup, or a small/mid sized company, there is nothing that beats a full stack solution such as Ruby On Rails. The libraries are stable and maintained because they're being used by a lot of companies. You have almost every decision already made for you, you might like it or not, but the set of decisions included in it are guaranteed to work well together. It is a lot more unlikely that some part of it will go unmaintained, you don't need to build an API for a separate frontend, you will get frequent updates, you have clear patterns and recommendations for how to do things. Deploy this on Heroku until the price goes to the salary of one or two engineers. That's a LOT. Would be more expensive to have somebody building a half assed version of it in-house. If it gets expensive, move to AppEngine or any similar, managed service. As long as you keep it using SQL and Docker you can move anywhere.
You might have more difficulty hiring people which, nowadays, want to work with Rails and do templates, etc. But the benefit is that you will need a lot less people for building an equivalent product. And probably you will find yourself with less people hyped by building kubernetes microservices on React with Monorepos and RXjs redux on top of Rust because "that's the defacto" and "ruby doesn't scale".
Please, CTOs of the world, let's get back to sanity. I just can't stand anymore seeing the time we're wasting with all of this.
Of course, at some point you will be a big company and then it might make more sense to do some of this. But think twice about all the trade offs until you get there.
Hope it helps.
[1] https://github.com/vercel/styled-jsx/issues/688