> I wouldn't recommend this approach for actual businesses, mostly because devs will already know React and thus be more productive. But I think it's genuinely a viable approach for building web apps.
That's just the thing. Businesses chose a specific stack because the campaigning for that stack won out amongst any competing stack, not because that stack most closely aligned with their requirements and needs.
Boring Anecdote Time:
I do contract work. All current frameworks have a velocity for new API/endpoint creation (with DB schema modification) of between 4hrs - 8hrs (spread out over 3 - 4 PRs)[1], assuming all the PRs come back with LGTM.
My home-grown b/end framework cuts this down to between 5min - 20min (one PR only) for the same API/endpoint addition.
However, I only use my home-grown b/end stack for full webapp development, when a client wants a new system, and only when that client is not a technology company, or doesn't have an in-house development team.
That's because most businesses are using what their tech teams mandate, which IME is either Java, C# or (not as common around here) a Python or Node b/end.
Once(!) I had a dev manager agree that velocity for MVP and velocity for maintenance is a higher priority than conforming to any of the current b/end languages, which included but was not limited to C++, Java, Kotlin, Python, Node, React, Ruby, MSSQL, MySQL ... etc.
A few months later, on a call with him he expressed how fast his dev team was iterating on my stack when extending the system. Currently they are stuck on a lot of legacy that has to be extended, but they are definitely thinking about b/end in a new way now.
[1] Assuming the usual workflow of PR for ORM changes, then PR for data object layer + unit tests, then PR for domain object layer + unit tests, then PR for business logic + unit tests.
That's just the thing. Businesses chose a specific stack because the campaigning for that stack won out amongst any competing stack, not because that stack most closely aligned with their requirements and needs.
Boring Anecdote Time:
I do contract work. All current frameworks have a velocity for new API/endpoint creation (with DB schema modification) of between 4hrs - 8hrs (spread out over 3 - 4 PRs)[1], assuming all the PRs come back with LGTM.
My home-grown b/end framework cuts this down to between 5min - 20min (one PR only) for the same API/endpoint addition.
However, I only use my home-grown b/end stack for full webapp development, when a client wants a new system, and only when that client is not a technology company, or doesn't have an in-house development team.
That's because most businesses are using what their tech teams mandate, which IME is either Java, C# or (not as common around here) a Python or Node b/end.
Once(!) I had a dev manager agree that velocity for MVP and velocity for maintenance is a higher priority than conforming to any of the current b/end languages, which included but was not limited to C++, Java, Kotlin, Python, Node, React, Ruby, MSSQL, MySQL ... etc.
A few months later, on a call with him he expressed how fast his dev team was iterating on my stack when extending the system. Currently they are stuck on a lot of legacy that has to be extended, but they are definitely thinking about b/end in a new way now.
[1] Assuming the usual workflow of PR for ORM changes, then PR for data object layer + unit tests, then PR for domain object layer + unit tests, then PR for business logic + unit tests.