É bem possível fazer um app bom em React Native, só olhar o Discord por exemplo. O app deles roda bem, nunca tive problemas nem lag. Mas eles também tem 700+ funcionários, eu não sei quantos são engenheiros. Eles tem recursos pra gastar e fazer o app ficar bom. Mesma coisa o Spotify, eles tem 300+ devs só pro app de Android, mas o deles é nativo (Java/Kotlin). Normalmente quem tem grana pra gastar vai ter um app bom apesar da tecnologia escolhida.
Mas também olha a quantidade de lixo que aparece, tem muita página web disfarçada de app que dá nojo de usar. Nada funciona direito. Tive que instalar um aqui pro porteiro eletrônico que ao clicar nos botões não existe feedback nenhum (nem do toque, e nem que a página está carregando). E o serviço bosta deles só retorna 500 sem falar qual é o problema.......
E esses apps, tanto ReactNative como Electron só rodam bem hoje porque o hardware evoluiu MUITO pra aguentar esse tranco. Não é a toa que alguns apps precisam de uma versão 'lite' pra rodar em dispostivos mais fracos. Facebook mesmo tem uma versão lite.
Pra app mobile eu sou suspeito pra falar porque sou dev mobile há 10 anos. Mas eu ficaria entre Flutter ou Kotlin Multiplatform.
--
Só pra ilustrar, eu li um artigo uma vez (posso até procurar a fonte se quiser) mas a pessoa tava dizendo que a empresa dela refatorou o código de Node.JS no backend pra Rust.
Antes, pra aguentar o tranco eles precisavam de 5 t3.large (ou xlarge) na EC2 (AWS) e depois do refactor, eles conseguem a mesma performance com 1 t3.nano.
Tabela que eu acabei de tirar do site da AWS:
https://aws.amazon.com/ec2/instance-types/t3/
| Name | vCPUs | Memory (GiB) | Baseline Performance/vCPU | CPU Credits earned/hr | Network burst bandwidth (Gbps) | EBS burst bandwidth (Mbps) | On-Demand Price/hr* | 1-yr Reserved Instance Effective Hourly* | 3-yr Reserved Instance Effective Hourly* |
|---|
| t3.nano | 2 | 0.5 | 5% | 6 | 5 | Up to 2,085 | $0.0052 | $0.003 | $0.002 |
| t3.micro | 2 | 1.0 | 10% | 12 | 5 | Up to 2,085 | $0.0104 | $0.006 | $0.005 |
| t3.small | 2 | 2.0 | 20% | 24 | 5 | Up to 2,085 | $0.0209 | $0.012 | $0.008 |
| t3.medium | 2 | 4.0 | 20% | 24 | 5 | Up to 2,085 | $0.0418 | $0.025 | $0.017 |
| t3.large | 2 | 8.0 | 30% | 36 | 5 | Up to 2,780 | $0.0835 | $0.05 | $0.036 |
| t3.xlarge | 4 | 16.0 | 40% | 96 | 5 | Up to 2,780 | $0.1670 | $0.099 | $0.067 |
| t3.2xlarge | 8 | 32.0 | 40% | 192 | 5 | Up to 2,780 | $0.3341 | $0.199 | $0.133 |
uma t3.large custa
16 vezes mais que uma t3.nano, então o custo deles foi de $0.4175 pra $0.0052, uma queda de mais 90% nos custos.
(Posso estar fazendo cálculo errado, eu não sou backend e não sei se é assim que calcula o custo de uma máquina na EC2)
--
No fim eu entendo o porque muita empresa adota JS ou Python... são linguagens mais fáceis, tem mais desenvolvedores (e naturalmente tem mais desenvolvedores ruins também), então é mais fácil contratar. São mais dinâmicas e permitem que elas "movam rápido" pra entregar o MVP logo. Mas no fim do ciclo esses produtos deveriam ser reescritos em linguagens mais performáticas.
E quando falamos de linguagens performáticas isso
não quer dizer escovar bit. Só de sair de uma linguagem interpretada pra uma compilada já faz uma diferença boa.
Golang é tão fácil quanto JS, mas é fortemente tipada e é muito mais performático.
Rust é mais rápido ainda, e apesar de ter ainda mais controle sobre os dados, não é necessário ficar escovando bit pra ter performance.
