1
obrenoalvim
1 min de leitura ·

React em 2026: ainda faz sentido para novos projetos ou estamos seguindo inércia?

React tem 12 anos. É a biblioteca mais usada no frontend. E talvez seja por isso que vale a pena questionar: se ela não existisse, você a escolheria hoje?

O que React ainda faz bem

Ecossistema. Não tem comparação. Qualquer biblioteca, componente, padrão: existe para React primeiro.

Mercado de trabalho. React no currículo ainda abre mais portas do que qualquer alternativa.

Server Components (RSC). A aposta em renderização no servidor foi uma mudança arquitetural real, não só cosmética.

O que ficou para trás

Verbosidade. Vue e Svelte reduziram drasticamente o boilerplate. Um componente simples em Svelte é a metade de linhas do equivalente em React.

Performance out-of-the-box. Svelte compila para JS vanilla sem runtime. Solid tem reatividade granular sem re-render de árvore. React ainda depende de memoização manual para casos críticos.

O modelo mental do useEffect ainda confunde desenvolvedores experientes. Isso não é problema do dev: é design da API.

O que me faz ficar

Reusabilidade de conhecimento. Aprender React profundamente ainda é um investimento com retorno claro. Aprender Svelte profundamente é uma aposta.

A pergunta real

Se você começasse um projeto hoje sem pressão de mercado ou time, o que escolheria? React por convicção ou por default?

Carregando publicação patrocinada...
5
1

A pergunta é um exercício mental: imaginar que você não tem inércia de ecossistema, mercado ou comunidade, e precisa escolher do zero. É uma forma de separar o que você valoriza tecnicamente do que usa por conveniência. A resposta pode ser React mesmo, mas o raciocínio que chega lá muda. Partindo do zero sem nenhuma pressão externa, qual seria a sua escolha?

3

Deixando a brincadeira de lado, sim, ainda escolheria react.

Nos ultimos 2 anos eu criei dezenas de projetos. Sozinho, poderia escolher a stack que eu quisesse.

Testei um projeto com vue, ele é excelente para MVPs e coisas pequenas, vira um inferno em projetos grandes, a proposta é boa mas pessoalmente não gosto de como fica o resultado.

Testei angular e me senti sendo arrastado por uma correnteza, é um framework DESNECESSARIAMENTE burocrático. Para fazer qualquer coisisnha é uma tortura.

Não me interessei por svelte ou frameworks menores, achei o código feio (e eu levo isso em consideração)

Então sim, react continua sendo a minha opção final. Mas um react mais limpo, simplificado, programado de verdade, sem a salada de frutas que é gerada por uma pessoa menos inexperiente.

React bem feito continua sendo o melhor framework.

Agora, código de pessoas inexperientes, com dezenas de hooks e arquivos gigantescos que fazem tudo? com certeza react te da a liberdade para ser um pior dele, mas na minha opinião depende mais da tua capacidade que do framework em si

3

O cara que fala que o código do svelte é feio nao programou em svelte, manda o link de algum projeto que vc fez, svelte tem uma sintaxe muito próxima da do javascript, não faz sentido ele te4 código feio

3
-2

Concordo que Svelte tem elegância, especialmente no sistema de reatividade sem boilerplate. O ponto do post não era sobre a documentação em si, mas sobre como a sintaxe .svelte é um paradigma diferente: mistura template, script e estilos de um jeito que parte dos devs acha mais simples, outra parte acha confuso. Não é crítica de qualidade, é sobre familiaridade e curva de adoção. Você migrou de React para Svelte em algum projeto real? Como foi a adaptação da equipe?

1

Concedo o ponto: a sintaxe básica do Svelte é clean, bem mais próxima do HTML/JS puro do que JSX. O que me incomoda mais é a reatividade implícita com $: e a forma como os arquivos .svelte misturam tudo num único lugar sem uma separação clara de responsabilidades. Não é necessariamente feio, mas exige um jeito diferente de pensar. No BloodLink usei Next.js pelo ecossistema e pela familiaridade, mas Svelte tá na lista pra experimentar no próximo projeto pessoal. Você usa Svelte em produção hoje?

1

Concordo no diagnóstico, especialmente sobre Angular. A burocracia dele não vem de complexidade necessária, é só camada sobre camada de abstração para casos que a maioria dos projetos nunca vai ter. Vue em projetos grandes também sinto isso: escala bem até um ponto, depois o two-way binding começa a cobrar. React te deixa errar feio, mas pelo menos os erros são seus e você entende o que aconteceu. Como você estrutura os projetos React pra evitar a salada de frutas? Pastas por feature, atomic design, ou algo diferente?

3

Estilo NextJS, pastas seguindo rotas, rotas seguindo VerticalSlices

pra mim react é: Fazer get na api e renderizar, só. não tem nenhum tipo de cálculo, regra de negócio.

1

Vertical slices com pastas por rota é o approach que mais escala sem criar acoplamento horizontal. Quando React fica só com get e renderizar, o debug fica direto: ou o dado está errado, ou a renderização está errada, e as duas coisas ficam isoladas. O problema que vejo em times é a pressão pra colocar lógica no componente por prazo ou preguiça. Você usa alguma convenção pra deixar claro no código onde termina a UI e começa a regra de negócio, ou é mais por disciplina do time?

4
4

"Paga as contas" é o critério mais honesto para escolha de framework. Svelte nos pessoais faz sentido, ergonomia melhor e bundle menor. O problema é que mercado de trabalho ainda não acompanhou.

O interessante é que essa tensão entre o que você usa por gosto e o que usa por trabalho tende a diminuir. Svelte foi de nicho para ter suporte em Cloudflare, Vercel e agora tem casos reais de produção em escala. Você acha que em 3 anos a conversa muda, ou React mantém o domínio por inércia mesmo?

3

Na minha rotina de trabalho hoje basicamente só uso Cloudflare pro DNS e R2, eu prefiro pegar um VPS seco e usar um Coolify ou Portainer, me dá mais liberdade, é mais barato pra empresa, e entrega super bem (com um custo de know how maior). Mas quando você tem que trabalhar com equipes ou preparar um projeto que será gerenciado por uma equipe que já trabalha de um jeito, tem que pesar na balança o custo técnico de tudo isso, aí você tem que fazer aquele system design pavoroso com Next.js tendo mais trabalho pra deixar ele "limpo" do que preparando o projeto em si. A Vercel consegue otimizar muita coisa mesmo, fazem um ótimo trabalho nisso, e obviamente cobram caro pra fazer.

Eu sinceramente acho que o React vai continuar, principalmente com o avanço da IA, ela já tem muito contexto do React, o cenário só mudaria se um player muito grande no mercado falasse: 'olha gente, agora estamos usando apenas o framework Y e é incrível', ao mesmo tempo que para atender a demanda de "canivete suíço" que a Vercel traz ele teria o mesmo bloat que o Next tem.

Nos meus projetos pessoais, quando a empresa aceita, e alguns saas próprios o front-end com Svelte para o admin e Astro para sites me enchem os olhos, é realmente incrível... É só não olhar pra onde a manada tá correndo. Eu faço o que precisa ser feito, mas sei das vantagens e desvantagens de cada um, e saber disso (pra mim) é infinitamente melhor que "dominar" um framework, dominar a lógica de negócios me traz mais vantagens. Frameworks podem mudar de uma hora para a outra, a lógica do negócio nunca vai mudar.

1

O ponto sobre lógica de negócio ser mais duradoura que framework é o mais importante e o menos falado. Eu uso Next.js no BloodLink mas as decisões arquiteturais que importam não dependem do framework, dependem de como você modela o domínio. Sobre React com IA: faz sentido, os modelos têm contexto gigantesco de React e isso vira vantagem prática no dia a dia. Minha dúvida com Astro e Svelte é sempre essa: quando o projeto escala e o time cresce, o custo de contratar e onboarding compensa a qualidade técnica? Você já teve que defender essa escolha pra um time maior?

5

Engenheiro de IA aqui: Apesar da base de treino ser gigante, React muda mais rápido que a base de treinamento das IAs. Na verdade isso vale para front-end em geral.

Se o front-end fugir dos componentes padrão, IA grátis não acompanha não.

Tive essa experiência no fim do ano passado: Meu dev junior vibe codeou uma interface para uma tela gigante de propaganda interativa e foi lindo, ficou genial. A diretoria do cliente enlouqueceu, o designer de UX, largou tudo pra abraçar o projeto.

Na hora de ir a produção, a tela tinha um formato exótico e precisávamos ajustar os componentes a esse formato.

Só que o Copilot falhava silenciosamente. Kiro falhava. Claudr tinha estouro de contexto. A gente ia precisar analisar antes de modificar o código.

Foram duas semanas para entender as milhares de funções de manipulação de viewport que a IA tinha feito e como elas conversavam com o React. O Copilot e Antigravity tinham estouro de contexto tentando analisar o código.

Enfim: Foi mais fácil abandonar e refazer. Uma dev refez em Angular, o outro em Svelte para comparar. Svelte ficou muito is eficiente, apesar do código terrivelmente feio e com algumas redundâncias. Foi pra prod.

1

Essa história resume bem o problema: IA gera código que funciona, mas que só ela entende. Manipulação de viewport em escala, sem contexto claro de como as funções se relacionam, é receita pra refatoração impossível. O desfecho pro Svelte faz sentido, código mais legível sobrevive melhor quando a IA não consegue mais ajudar. Você acha que o problema teria sido o mesmo com qualquer framework, ou React especificamente incentivou esse tipo de abstração excessiva?

3

Cara, os dois são defensáveis. Dá pra viver bem com qualquer uma dessas, até com Vue. Como disse antes, se já é algo estabelecido, mantém, eu manteria o Nextjs em uma equipe que já usa ele diversas vezes mesmo não gostando, mas isso vale até para Svelte, Vue, e etc. É aí que separamos o gosto pessoal do profissionalismo, mas eu garanto que independente do ecossistema há trabalho disponível, seja Go, Python, Rust, Ruby, PHP, JS com Svelte/React/Astro... Tudo vai ter seu pró e contra, ano passado eu comecei a estudar Go pq uma empresa que eu conheço não conseguia achar profissional, e pagava bem.

1

O ponto sobre profissionalismo é exato. Manter o que a equipe já usa faz mais sentido do que reescrever por preferência. E estudar Go por causa de uma vaga específica é uma jogada honesta: você aprende algo com demanda real, não só curiosidade técnica. Eu fiz parecido ao escolher Next pro BloodLink, foi mais sobre o que ia funcionar do que sobre explorar algo novo.

3

Análise Comparativa — Frameworks SPA

ANÁLISE COMPARATIVA

Frameworks SPA — Qual escolher para seu projeto?

Critérios avaliados: Performance · Curva de Aprendizado · Comunidade & Ecossistema

Março de 2026

1. Performance

Baseado no js-framework-benchmark, os frameworks foram avaliados pela velocidade de renderização, atualização de DOM e uso de memória. Frameworks que eliminam o virtual DOM ou compilam para operações nativas alcançam os melhores resultados.

PosiçãoFrameworkPontuação
🥇 1ºSolid.js98 / 100
🥈 2ºSvelte94 / 100
🥉 3ºVue 387 / 100
4ºPreact83 / 100
5ºReact78 / 100
6ºAngular72 / 100
7ºEmber58 / 100

Observação: Solid.js e Svelte só fazem diferença significativa em UIs com centenas de atualizações por segundo.

2. Curva de Aprendizado

A curva de aprendizado mede o tempo e esforço necessários para que um desenvolvedor fique produtivo no framework, considerando familiaridade com conceitos web padrão — HTML, CSS e JS.

PosiçãoFrameworkDificuldadePrincipal obstáculo
🥇 1ºVue 32/10Praticamente nenhum
🥈 2ºSvelte3/10Compilador e reatividade implícita
🥉 3ºPreact5/10JSX e modelo mental do React
🥉 3ºReact5/10Hooks, closures e JSX
5ºSolid.js7/10Parece React, mas tem armadilhas sérias
6ºAngular8/10TypeScript + RxJS + DI + Decorators
7ºEmber9/10Convenções rígidas e exclusivas

3. Comunidade & Ecossistema

Avalia tamanho da comunidade — Stack Overflow, GitHub, fóruns —, maturidade das libs de terceiros e oferta de componentes prontos.

PosiçãoFrameworkComunidadeLibsDestaques
🥇 1ºReact10/1010/10MUI, Shadcn, Zustand, TanStack
🥈 2ºVue 38/108/10Nuxt, Pinia, Vuetify, VueUse
🥉 3ºAngular7/107/10Angular Material, NgRx, RxJS
4ºSvelte6/105/10SvelteKit oficial e maduro
5ºPreact5/107/10Herda ecossistema do React
6ºSolid.js4/103/10Comunidade jovem e técnica
7ºEmber3/104/10Em declínio visível

4. Ranking Geral Consolidado

Visão consolidada dos três critérios para facilitar a tomada de decisão:

FrameworkPerformanceCurva de AprendizadoComunidade & Libs
Vue 3🥈 2º🥇 1º🥈 2º
React🥉 3º🥉 3º🥇 1º
Angular6º6º🥉 3º
Svelte🥈 2º🥈 2º4º
Preact4º🥉 3º5º
Solid.js🥇 1º5º6º
Ember7º7º7º

5. Veredito Final

Vue 3

Para a maioria dos projetos, Vue 3 é a escolha mais equilibrada do mercado.

Ele conquista o 1º lugar em facilidade de aprendizado, o 2º em performance e o 2º em comunidade & ecossistema — nenhum outro framework mantém esse nível de consistência nos três pilares.

Você chega em produção mais rápido, sofre menos com a curva de aprendizado e tem acesso a um ecossistema maduro com Nuxt, Pinia, VueUse, Vuetify e muito mais.

Por que não os outros?

React — use se:

  • O projeto já usa React.
  • Você precisa de uma lib de UI muito específica que só existe no ecossistema React.

Svelte — use se:

  • Performance é prioridade absoluta e o time aceita um ecossistema menor.
  • O projeto é relativamente simples e não depende de muitas libs de terceiros.
  • O time prefere uma sintaxe mais próxima do HTML puro.

Solid.js — use se:

  • Performance de nível nativo é um requisito inegociável, como jogos, dashboards em tempo real ou visualizações com milhares de atualizações por segundo.
  • O time tem experiência avançada e está disposto a construir boa parte das soluções do zero.

Angular — use se:

  • O projeto é enterprise de grande porte, com times grandes e necessidade de padronização rígida.
  • A empresa já tem investimento consolidado em Angular e TypeScript.
  • O contrato exige um framework com suporte corporativo de longo prazo, como o Google.

Evite Preact e Ember

Preact

Só faz sentido quando bundle size é crítico, por exemplo, widgets embarcados em sites de terceiros.

Para projetos completos, prefira Vue 3 ou React.

Ember

Comunidade em declínio, dificuldade crescente de encontrar profissionais e recursos atualizados.

6. Conclusão

Para a maioria dos novos projetos — startups, aplicações corporativas de médio porte, sistemas internos, projetos freelance e MVPs —, Vue 3 entrega a melhor relação custo-benefício entre velocidade de desenvolvimento, performance e suporte da comunidade.

Não existe framework “certo” universalmente.

A melhor escolha é sempre aquela que se alinha ao contexto do time, às necessidades do projeto e ao prazo disponível para aprendizado.

1

Análise bem montada. O ponto sobre Solid.js e Svelte só fazerem diferença com centenas de atualizações por segundo é o que mais gente ignora quando vai de benchmark direto pra decisão de arquitetura. Vue 3 como vencedor geral faz sentido em papel, mas meu palpite é que o mercado ainda vai demorar pra refletir isso em vagas e projetos novos. Inércia de ecossistema é difícil de vencer mesmo quando os números são claros.

3

Eu nunca curti React, acho vue mais tranquilo, mas eu sou back-end, nao sei se tenho lugar de fala aqui, uso vue nos meus projetos, temos uma plataforma gigante com vue que na minha opiniao se fosse em react seria insalubre dar manutenção.

1

Vue tendo opinião mais forte sobre como organizar o código ajuda muito em times. O problema do React não é técnico, é cultural: como ele não impõe nada, cada projeto vira uma arquitetura diferente. Dois projetos React podem ser completamente irreconhecíveis um para o outro. Dois projetos Vue tendem a se parecer mais.

Para back-end que precisa de um frontend funcional, Vue faz mais sentido. A curva é menor e o framework toma as decisões que você não quer tomar. Você tem preferência por Vue com Nuxt ou prefere Vue standalone?

3

Tenho a curiosidade de usar Svelt ou Vue, o que vou descobrir e aprender? Ou mesmo aprender Angular. E não esquecer que tendo o conhecimento do React está bem próximo do Next JS ... mas é bom ter alternativas, então acho que optaria pelo Angular.

1

Svelte é a que mais muda o modelo mental: sem virtual DOM, compilação em build time, código bem mais conciso. Boa pedida pra entender o que React abstrai. Vue é uma transição mais suave, especialmente para quem vem de templates HTML. Angular é o extremo oposto: framework opinado, DI, decorators, estrutura rígida. Se o objetivo é aprendizado, Svelte primeiro para ver um modelo diferente, Angular depois para ver o extremo. O equivalente de Next.js nos outros ecossistemas seria SvelteKit ou Nuxt. Você tem algum projeto pequeno em mente para testar, ou é mais curiosidade teórica por enquanto?

3

Sendo eu alguem bem suspeito pra falar sobre frontend já que sou backend e me da raiva ter que usar js, se eu tivesse que escolher alguma lib frontend js eu iria de react por ser fácil, em pouco tempo você já entendeu como funciona. Mas como eu não gosto de js quando faço frontend eu uso um framework muito parecido com o SolidJS na ideia que é o Leptos que é um framework para criar frontend reativo em Rust com tudo que tem direito: server functions, reatividade granular sem vDOM e SSR + Hidratação.

1

Leptos é uma das apostas mais interessantes no espaço de frontend alternativo. A reatividade granular sem vDOM é exatamente o que chama atenção, no papel é o que SolidJS entrega mas em Rust. O problema real que vejo pra adoção é o ecossistema de libs UI: você acaba reescrevendo coisas que em React ou Svelte já estão prontas. Como está o suporte a bibliotecas de componentes no Leptos? Você constrói tudo do zero ou já tem alternativas razoáveis no ecossistema?

3

Existem algumas libs UI mas nada realmente maduro e relevante, o que é de se esperar já que rust não é a primeira coisa que vem na cabeça quando pensa em frontend, mas para não dizer que não existem essas libs existe o Thaw que é um UI kit completo com CSS proprio e é o mais maduro atualmente, o Leptodon que é um kit inspirado no Flowbite e usa tailwind para o CSS e o Rust/UI que é um registry tipo o shadcn/ui. Sendo esses dois últimos projetos bem novos com menos de 1 mês de vida, então não, ainda não tem um ecossistema de libs é necessário construir tudo do zero na maior parte das vezes. Se você quer produtividade não é muito possivel de se recomendar o leptos, primeiro que rust não é exemplo de produtividade e compilar um frontend com o compilador mais chato de todos não ajuda muito e juntando isso com a falta de bibliotecas é uma escolha altamente questionavel.

1

Valeu por trazer os nomes, não conhecia o Leptodon. O ponto que você levantou resume bem: falta de libs não é só inconveniência, é custo real de projeto. Rust no frontend ainda parece mais experimento do que opção séria pra quem precisa entregar. A pergunta que fica: você acha que o ecossistema vai amadurecer o suficiente nos próximos 2-3 anos pra virar alternativa real, ou vai continuar como nicho de performance crítica?

3

Acredito que vai ficar como nicho e não é nem de performance critica, uma pagina leptos é tão eficiente quanto uma pagina escrita em solidJS a diferença maior é que o runtime em vez de ser js é wasm. Vale lembrar que WASM tende a gerar bundles maiores que JS equivalente e o browser precisa baixar e compilar o WASM antes de renderizar, além disso toda chamada que cruza a boundary WASM/JS tem um custo, o que pode anular parte do ganho em casos de manipulação intensa de DOM. A maior vantagem do leptos é que a carga cognitiva em casos de que só tem 1 dev é menor pois você usa a mesma linguagem no backend e no frontend, além de que você garante segurança de tipos em tempo de compilação tanto no frontend quanto no backend reduzindo erros em payloads. Não vejo isso saindo de algo nichado até porquê Rust em si é uma linguagem nichada em desenvolvimento web nem pra backend ela é a escolha óbvia imagina para frontend.

1

Concordo que o custo da boundary WASM/JS é o ponto mais ignorado quando alguém cita Leptos. As demos de benchmark sempre mostram código que mal toca o DOM, que é exatamente onde WASM brilha. Numa aplicação real com formulários, drag-and-drop, animações, o custo aparece.

A vantagem de carga cognitiva pra dev solo é real, mas acho que só justifica em projetos onde o backend Rust já existe. Adotar Rust só pelo frontend seria escolher a ferramenta mais trabalhosa disponível.

Tem uma coisa que me interessa: você acha que Leptos tem espaço como alternativa pra aplicações de alto desempenho muito específicas, tipo visualização de dados em tempo real, ou mesmo nesses casos o tradeoff não compensa?

3

Atualmente ele brilha em aplicações com necessidade de processamento do lado do cliente, WASM consegue usar melhor os recursos da maquina do que o V8, em uma aplicação web padrão o desempenho do leptos tende a ser igual a seus pares em JS pois no ganho que ele tem de performance parte é perdida no boundary WASM -> JS + DOM. Mas quanto mais processamento você fizer no lado do cliente mais a balança tende a pender pra rust, vamos supor que você quer carregar um arquivo parquet no lado do cliente e plotar gráficos com base nesses arquivos sem enviar nada para o servidor seria extremamente mais rápido e performático em WASM, mas em um fluxo normal como um blog só se justifica em qual o usuario prefere trabalhar pois no final vai ser o mesmo, como eu disse acima os bundles WASM geralmente são maiores que os js porem isso é valido considerando o mesmo uso porém até na sua pergunta anterior sobre UI libs já mostra quase ninguem faz uma aplicação com react puro, se vai trabalhar com graficos vai entrar um chartJS, vai entrar outras libs então no final acaba empatando.

EU como dev backend e que não gosta da sintaxe de js/ts prefiro utilizar leptos até mesmo em aplicações 100% front mesmo sem backend, mas tambem sei que sou um esquisito por fazer isso e que não é a melhor ferramenta pra isso, com certeza seria infinitamente mais rapido eu fazer um front em react e teria a mesma performance mas ainda assim eu escolho o fazer em rust.

Vou deixar até um exemplo aqui: https://coffee.lukakuuhaku.dev
Essa aplicação é 100% client side o backend é 4 linhas no nginx que respondem a chamada com o index.html o js base, o css e o wasm nada mais e nada menos, levei 3h pra fazer em react levaria 30 minutos mas ainda assim faria em rust de novo e de novo.

1

Faz sentido: o overhead do boundary WASM/JS equilibra o jogo em fluxos comuns, mas processamento intensivo client-side é onde WASM realmente se destaca. O exemplo do parquet é exatamente o tipo de caso que qualquer framework JS vai sofrer, sem volta. Mas fora esse nicho de processamento pesado, Leptos tem alguma vantagem real ou é basicamente preferência de sintaxe e conforto com Rust mesmo?

3

Fora o processamento pesado e a coerência de projeto a unica vantagem real é a segurança de tipos em Rust a type safety não é opcional nem negociável, você não consegue fazer um as any quando estiver com pressa. Em TypeScript isso é disciplina, e disciplina desaparece quando o prazo encurta. O compilador do Leptos é chato exatamente por isso. Inclusive as server functions dele eu acho muito superiores às server functions do React e do Next apesar da sintaxe até lembrar um pouco.

#[server(SaveFavorites, "/api")]
pub async fn save_favorites(
    favorite_cookie_type: String,
    favorite_color: String,
) -> Result<(), ServerFnError> {
    let pool = get_pool()?;

    let query = "
        INSERT INTO COOKIES 
        (favorite_cookie_type, favorite_color)
        VALUES ($1, $2)
    ";

    sqlx::query(query)
        .bind(favorite_cookie_type)
        .bind(favorite_color)
        .execute(&pool)
        .await
        .map_err(|e| 
            ServerFnError::ServerError(e.to_string())?;

    Ok(format!("Here, have some {favorite_color} {favorite_cookie_type} cookies!"))
}

#[component]
pub fn FavoritesForm() -> impl IntoView {
    let favorites = create_server_action::<SaveFavorites>();
    let value = favorites.value();
    view! { 
        <ActionForm action=favorites>
            <label>
                "Favorite type of cookie"
                <input
                    type="text"
                    name="favorite_cookie_type"
                />
            </label>
            <label>
                "Favorite color"
                <input
                    type="text"
                    name="favorite_color"
                />
            </label>
            <input type="submit"/>
        </ActionForm>
        <Show when=favorites.pending()>
            <div>"Loading..."</div>
        </Show>
        <Show when=move || value.with(Option::is_some)>
            <div>{value}</div>
        </Show>
    }
}

(codigo acima é um exemplo da propria documentação do leptos)

Mas isso é apenas coisa de detalhe que não dá nenhuma vantagem em runtime, se a aplicação for bem escrita isso não importa em nenhuma delas, então sim é simplesmente preferencia de sintaxe e conforto com Rust.

1

O ponto do as any é real e bom. TypeScript te dá uma rede de segurança que você mesmo pode cortar quando o prazo aperta. Com Rust o compilador não negocia, você resolve o problema ou não compila.

As server functions do Leptos são interessantes exatamente por isso: o contrato entre cliente e servidor é verificado em tempo de compilação, não em runtime. No Next você descobre o erro quando o usuário já recebeu um 500.

O custo é a curva de aprendizado e o ecossistema ainda enxuto. Para projetos pessoais ou times que já conhecem Rust, vale muito. Para um time misto contratando devs no mercado, ainda é uma aposta arriscada.

Você usa Leptos em produção ou ainda é exploração?

3

Em produção ainda não, no meu trabalho raramente tenho que mexer com frontend e quando preciso é coisa basica e eu geralmente faço paginas estáticas, mas tô começando a migrar projetos pessoais meu que eu fiz o front com react (cheio de gambiarra do pra falar que tem front) pra leptos, como por exemplo o painel de admin da minha api para whatsapp que é escrita em go e fiz o front em react, esse sim tá em produção e uso em diversos projetos meus e daqui umas 4 ou 5 semanas devo finalizar essa migração.

1

Leptos é uma escolha bem corajosa pra painel em produção. Tem bem menos material disponível comparado ao React e o modelo de reatividade é diferente do que a maioria está acostumada. Curioso pra saber: a migração tá sendo mais difícil pela falta de ecossistema ou pela mudança de paradigma do Rust em si? E o que te motivou a migrar o painel de admin especificamente, em vez de deixar como estava?

3

A parte mais dificil da migração está sendo por causa da gambiarra que é o codigo react que fiz, a maior parte dos componentes nem sei por que existem e a que eu sei tá tudo feito do pior jeito possivel, a migração foi motivada justamente pela dificuldade que é dar manutenção nesse painel então eu já teria que reescrever então optei por trocar a stack inteira logo e fazer em uma linguagem que eu trabalhe melhor.

1

Faz todo sentido trocar a stack quando a reescrita já é inevitável de qualquer jeito. React mal estruturado é das piores heranças, porque a liberdade da biblioteca vira armadilha: cada dev fez do seu jeito, sem convenção nenhuma. Qual stack você foi?

3

A stack original era go + chi + whatsmeow pro backend, postgres de db e redis para as sessões ativas e React puro mesmo pro front, front não é muito minha praia então ficou bem basicão mesmo sem muita firula não fiquei usando libs nem nada só ficou cheio de gambiarra. Agora o backend se mantém até pensei em migrar pra rust e usar axum + whatsapp-rust mas a lib do whatsapp rust é bem nova e foi feita pensando em usar um sqlite por sessão para o whatsapp e pro meu objetivo que é pra colocar centenas de sessões simultâneas eu iria ter que reescrever a implementação do db então decidi manter e usar leptos CSR consumindo a api. A vantagem é que se depois eu quiser fazer um app desktop e mobile pra gerenciar fica fácil que leptos compila bem de boa no tauri.

1

A decisão de manter Go e migrar só o front pra leptos faz sentido dado o problema: refazer a implementação de DB da lib Rust do WhatsApp pra suportar centenas de sessões custaria mais do que vale. E já pensar em leptos CSR visando Tauri depois é uma jogada inteligente, a compilação pro desktop fica bem natural. Como você está gerenciando o ciclo de vida das sessões WhatsApp no Redis quando a sessão fica inativa por muito tempo?

3

Não gerencio, a não ser que desconecte do whatsapp ele fica lá enquanto o servidor estiver ativo, alem de subir junto com o boot. Apenas se o admin da sessão desconectar que ele realmente é tirado do redis e fica só com as credenciais em standby no postgres (criptografado claro) para o proximo start tentar reconexão sem qrcode. Esse é justamente o motivo de eu manter o backend go que já tá bem otimizado, o redis acaba mantendo todas as sessões em memoria, o que é +/- 50mb por sessão.

1

50mb por sessão no Redis é bem razoável considerando que você elimina a reconexão com QR code. A parte inteligente é manter as credenciais no Postgres como fallback: você perde a sessão em memória mas mantém a capacidade de reconexão automática. Esse padrão de Redis como cache mais banco relacional como fonte de verdade resolve bem o trade-off entre custo de memória e latência em sessões de longa duração.

3

Eu sinceramente motivado pelas postagens de um outro usuario aqui do tabnews tô pensando em testar uma unlogged table do postgres no lugar do redis pra ver se consigo reduzir o uso de memoria enquanto joga a porrada inteira no postgres (unlogged tem througput alto por não ter WAL) se a latência não for muito mais alta para o uso é uma boa troca mas claro que tem que testar pra ver se o tempo resposta ainda tá bom e não tem um atraso muito alto na entrega de webhooks (notify do postgres) a ideia é realmente passar toda a responsabilidade da stack pro postgres sem cache, sem filas só o elefante.

1

Fiz algo parecido para cache de sessão aqui no BloodLink. Unlogged table resolve bem o throughput, mas tem um detalhe crítico: em crash, o Postgres trunca a tabela no recovery. Para webhooks isso significa perder eventos não processados.

O NOTIFY também tem uma limitação não óbvia: se o listener não estiver conectado no momento, a mensagem some. Então a tabela funciona bem como fila, mas o NOTIFY serve melhor como sinal de 'vai buscar' do que como portador da mensagem em si.

Se o caso de uso aceita perder eventos em crash e o listener é estável, a troca por Redis faz sentido. Quanto de memória você está tentando economizar?

3

Interessante, no meu caso a unlogged table seria pra cache de instâncias e o notify para a entrega de webhooks, como o consumidor seria parte do meu serviço talvez faça sentido eu separar o notify do serviço principal pra ser mais estável, obrigado por esse dado. Quanto a economia de memoria pra esse caso quanto maior melhor as sessões no whatsmeow ativas se valem de websocket e para você enviar as mensagens tem que ser criptografadas com chaves especificas por contato (whatsmeow abstrai isso) então acaba que as chaves são necessarias o tempo inteiro e alguns dados da sessão também, criptografia é custosa tanto pra cpu quanto pra ram então quanto mais ram eu conseguir economizar no que tá em volta mais sessões ativas consigo sustentar, perda de eventos gerais é aceitavel, perda de mensagens não então um fluxo separado para esses eventos pode ser interessante se eu não conseguir colocar isso no postgres realmente seria necessario uma fila dedicada como rabbit ou bull pois nessa parte em específico a perda de webhook é inaceitável se fosse a perda de um webhook de qr code dá pra fazer o client pedir um status em caso de mensagem isso é irreal. Quanto ao uso do postgres pra cache de sessão, você consegue dar mais detalhes sobre?

1

Para cache de sessão, o que faço é serializar o estado da sessão (chaves, device info, o que o whatsmeow usa para reconectar) em JSONB numa tabela unlogged. Na inicialização você carrega do postgres, depois o que fica em memória é só o que está ativo naquele momento.

A vantagem de RAM vem de poder fazer lazy load: em vez de manter tudo em memória o tempo inteiro, você só carrega o que está sendo usado. Sessão inativa por X minutos pode ter estado descarregado da memória e recarregado na reconexão.

Para as chaves de criptografia por contato, é a mesma lógica: persiste no postgres, carrega sob demanda. A latência de um SELECT é aceitável comparado ao tempo de handshake que você já economizou.

3

No meu caso o lazy load da sessão não é possível já que receber mensagem é parte core do serviço o ganho é mais na criptografia por contato e manter a camada http bem leve, infelizmente nas sessões em si não tenho como economizar na ram, mas bom saber que a unlogged table é o suficiente, é literalmente dois serviços a menos já não vou usar redis e nem rabbitmq o que economiza algumas centenas de mb de ram.

1

Faz todo sentido, serviço de mensagens não tem como adiar as sessões. Mesmo que não dê pra economizar na RAM delas, eliminar Redis e RabbitMQ já é um ganho enorme em complexidade operacional, não só em memória. Dois serviços a menos pra monitorar, escalar e eventualmente falhar.

3

Sou engenheiro de IA faz uns bons 15 anos, e a maior parte do meu tempo é integração com front/back.

Tenho uma lista de tecnologias que encerram projeto:

  • React
  • Qualquer coisa com PHP
  • Encapsulamento de GenAI para Vídeo
  • IA clássica não-supervisionada
  • ...

Conto nos dedos as vezes que vi um projeto com essas techs entregar MVP em menos de um ano. Em geral a complexidade do framework sobrecarrega a equipe após a primeira versão alpha.

Eu sempre discuto essa lista com colegas e React tá no topo desde 2023. A não ser que você esteja clonando algum componente já pronto da Meta, é coisa demais.

O meu dev React atual (5 anos de experiência) tá tão puto com a performance do React que tá preferindo VanillaJS, os meus devs React anteriores (juniores com +- 1 ano de experiência) migraram para SvelteKit - o cargo dos caras é dev React e ainda assim eles entregam melhor desenvolvendo em outras coisas.

Na minha empresa anterior, a equipe de Data Science tinha um portal client-facing em React - foram 2 anos pra começar a estabilizar as funcionalidades básicas, teve nego que pediu demissão quando pediram que ele integrasse ferramenta com aquilo.

Meus projetos pessoais - a maioria vibe codeados - estão todos em Alpine.js ou em alguma template engine.

Me assusta a quantidade de cargo, BR e gringo, pedindo React, ça porra não tá compensando faz tempo.

1

Esse padrão que você descreveu é real. O ecossistema vira peso quando a equipe gerencia mais biblioteca do que produto.

Ironia é que uso Next.js no meu projeto atual, mas a escolha foi deliberada: mercado de contratação, RSC resolvendo hidratação client-side de forma que template engine não escala da mesma forma.

A questão que fico rodando: o problema é React em si, ou é a cultura de over-engineer que React atrai? Alpine e SvelteKit têm menos bagagem porque ainda não viraram padrão de mercado, então a pressão de 'fazer do jeito certo' é menor e a equipe foca no produto.

Seu dev sênior foi para VanillaJS por conta própria, ou virou decisão de equipe?

3

O ecossistema vira peso quando a equipe gerencia mais biblioteca do que produto.

Os front-ends produtivos que conheço atualmente não entendem de programação, entendem de organizar biblioteca pra funcionar com o React. Eu só olho e rio.

A questão que fico rodando: o problema é React em si, ou é a cultura de over-engineer que React atrai?

Rapaz, os primeiros evangelizadores React que vi propagandeavam ele por ter se originado na Meta, e insistiam que novos projetos fossem em React. Só que faltava features e não tinha muita opção de gambiarra, então partia pro over-engineering. Muito colega de faculdade meu foi evangelizador React, hoje nem encostam nele.

Alpine e SvelteKit têm menos bagagem porque ainda não viraram padrão de mercado, então a pressão de 'fazer do jeito certo' é menor e a equipe foca no produto.

O Alpine acho que não vai nunca ser popular e também nunca vai ter bloat, pois a vibe é ser minimalista. Vai ser sempre coisa de programador "revoltado".

O Svelte já tá mais bloat do que costumava ser, mas ainda tá muito mais leve e simples de programar que React.

Seu dev sênior foi para VanillaJS por conta própria, ou virou decisão de equipe?

Limitação do ambiente onde a aplicação ia rodar, ambiente governamental de alta segurança. React e Next simplesmente não eram opção por terem dúvidas com relação a segurança. A gente não tinha prazo pra aprender um framework novo, era mais rápido desenvolver Vanilla.

1

A parte dos colegas que evangelizavam React e hoje não tocam nele bate demais. Virou quase um rito de passagem: defende com unhas e dentes por 2 anos, depois descobre que existia mundo além e muda completamente.

Sobre o Alpine, acho que você acertou na vibe. Ele resolve um problema específico muito bem e vai ficar nesse espaço. Não é ruim ter ferramenta assim, mas o mercado não vai abraçar.

Interessante o caso do governo, não tinha pensado nessa perspectiva. Segurança como restrição que força Vanilla. No fundo, tirou o scaffolding e o time entregou de qualquer jeito, o que diz bastante sobre o overhead que a gente carrega nos projetos modernos.

Essa experiência mudou sua visão sobre quanto do ecossistema JS você usa de fato versus quanto você usa porque vem junto?

3

Tô no evento de lançamento do software agora.

O que aprendi foi que para cada tarefa tem uma ferramenta, mas que o mercado algumas vezes tem a ferramenta e fica procurando tarefa. React tá bem assim, muito dev e empresa procurando projeto onde encaixar React nem que seja na força bruta.

1

Essa definição é boa: framework virou identidade em vez de ferramenta. Tem muita empresa que aprende React e daí encaixa em tudo, até onde HTML com um pouco de JS resolveria mais rápido. O problema é que o mercado de trabalho reforça isso, React no currículo abre portas então ninguém questiona se faz sentido pro projeto. Você trabalha em projetos onde esse mau uso é explícito, ou é mais observação de mercado mesmo?