Shopify está saindo do React Native de volta para o Nativo (Swift e Kotlin) · rafael

A Shopify usa o React Native desde 2020, e muita coisa mudou desde então. Conforme a declaração no blog deles: "agentes de codificação mudaram o custo de desenvolvimento de aplicativos móveis em dobro", e resolveram sair do React Native para usar diretamente Swift e Kotlin.

O post tem vários detalhes, e a declaração acima não foi uma surpresa pra mim (na verdade é óbvio, já vimos outros casos como o Bun reescrito em Rust), mas tem algumas coisas que chamaram minha atenção, como o que a Shopify chamou de Helix.

O desenvolvedor aponta o Helix para uma tela. O Helix lê o código React Native e propõe uma sequência de checkpoints (pequenos segmentos ordenados do trabalho) que podem ser revisadosem minutos. Em seguida, avança checkpoint a checkpoint: cada um deve comprovar seu comportamento por meio de testes, corresponder ao aplicativo em execução em uma revisão visual, passar pelo crivo de dois revisores de código (atuando de forma crítica) e receber a aprovação humana antes de ser consolidado (commit) e de o próximo passo começar. O feedback de cada revisão é armazenado, tornando o processo mais autônomo à medida que a migração avança.

Desenvolvimento com o Helix: duas telas de celular lado a lado

Tem outros pontos interessantes no artigo.

Assim como uma grande empresa usar um framework/biblioteca é bom para essa ferramenta, deixar de usá-la pode ser ruim. No post tem três exemplos de bibliotecas que a Shopify desenvolvia/apoiava e o que vai acontecer com elas. Talvez outras empresas sigam o sinal e saíam de React Native e Flutter também.

Vale destacar, a IA ainda não roubou todos os empregos:

Se você quer ajudar a construir a próxima geração de aplicativos móveis da Shopify, estamos contratando engenheiros mobile, engenheiros de infraestrutura e desenvolvedores que atuam na intersecção entre IA e engenharia de software.

Com a chegada de modelos de inteligência artificial mais potentes, a maioria das ferramentas perderam seu propósito.

Quem é dev sabe que existe uma quantidade massiva de "glue" no código apenas porquê era chato de lidar, ou porquê era/é popular. Enfim, dependência sem uma necessidade real...

Eu penso que nativo é sempre melhor, e acrescentar uma dependência apenas em casos exepcionais. Por exemplo o serde é uma dependência essencial para o ecossistema Rust, bem como tokio projetos assíncronos, porém no caso de tokio, ainda vale considerar de threads não é o suficiente mesmo que custe um pouco (custo esse que pode ser reduzidos de 8 megabyte ~ 3 megabyte dependendo do context).