SvelteKit 3

Artigo original ↗ Discussão no Hacker News ↗

O lançamento do SvelteKit 3 está a reavivar o debate sobre o papel dos frameworks frontend numa era em que muitos programadores recorrem a agentes de IA para escrever código. Os comentadores elogiam o Svelte/SvelteKit pelo desempenho, pela ergonomia próxima de HTML e pela forte história de rendering do lado do servidor, muitas vezes preferindo-o a React, Vue/Nuxt ou Next.js, apesar de um ecossistema menor e de alguma rotatividade na sintaxe e no tooling. Um tema recorrente é que, mesmo com LLMs a tratar de grande parte da programação, as escolhas de framework continuam a importar para o tamanho do bundle, fiabilidade, acessibilidade e para a eficiência com que os agentes conseguem gerar e manter aplicações de alta qualidade.

Receção geral do SvelteKit 3

  • Muitos comentários são fortemente positivos sobre Svelte/SvelteKit, chamando-o de rápido, intuitivo e com excelente experiência de desenvolvimento.
  • Vários utilizadores relatam atualizações sem problemas, especialmente de SvelteKit 2 → 3, dizendo que este lançamento se concentra em refinamento em vez de grandes novas funcionalidades.
  • Alguns mostram-se indiferentes ou céticos, argumentando que, num mundo de IA/agentes, a ergonomia dos frameworks importa menos.

Funções remotas, carregamento de dados e novas funcionalidades

  • As remote functions ainda estão marcadas como experimentais, mas vários utilizadores dizem que as usam em produção com poucos problemas e que esperam uma migração fácil.
  • As funções load tradicionais continuam a ser o idiomático “estável”, mas funcionam ao nível de rota/layout, enquanto as remote functions permitem obtenção de dados mais granular, ao nível do componente.
  • Alguns utilizadores não gostam de novos padrões de acoplamento como as remote functions, prevendo que possam sair de moda.

Svelte vs React (e o contexto LLM/agentes)

  • Muitos comentadores preferem Svelte a React por: modelo mental mais simples, templates mais próximos de HTML, menos “armadilhas” e melhor desempenho por defeito e tamanho de bundle.
  • Outros dizem que os LLMs historicamente funcionavam melhor com React devido a mais dados de treino e um ecossistema mais rico, tornando React+agentes muito produtivo.
  • Vários contrapõem que os modelos modernos já lidam bem com Svelte/SvelteKit, por vezes com menos tokens, e que o código Svelte é mais fácil para humanos lerem e manterem após a geração.
  • Alguns veem apps React como inchadas e pesadas em recursos do ponto de vista do utilizador.

Svelte vs Vue/Nuxt e outros frameworks

  • Uma comparação detalhada: a DX central do Vue é descrita como mais polida do que a do Svelte, mas o Nuxt (a principal solução SSR do Vue) é chamado de doloroso; o SvelteKit é elogiado pela clareza do SSR e pela separação “à la MVC”.
  • Outros relatam ter migrado do Nuxt para o SvelteKit e não terem olhado para trás.
  • Solid e Astro são mencionados como alternativas com melhor tooling (Solid) ou foco mais forte em SSG (Astro).

Tooling, ecossistema e preocupações com estabilidade

  • Queixas recorrentes: a sintaxe personalizada do Svelte exige tooling próprio; integrações com Storybook, ESLint, IDEs e algumas bibliotecas JS podem ser mais fracas do que nos ecossistemas baseados em JSX.
  • Alguns notam mudanças repetidas de sintaxe e APIs entre versões do Svelte (especialmente nas primeiras, além dos runes do Svelte 5), o que prejudica a fiabilidade dos LLMs e a confiança dos programadores.
  • Outros argumentam que as grandes mudanças disruptivas têm sido limitadas desde o Svelte 3 e que o tooling de migração é forte.

Frameworks vs vanilla na era da IA

  • Uma minoria visível argumenta que, com LLMs fortes, muitas aplicações podem ser construídas em HTML/CSS/JS puro sem frameworks, evitando a rotatividade de dependências.
  • Outros respondem que os frameworks ainda acrescentam valor ao gerir complexidade, desempenho, segurança de tipos e SSR, beneficiando tanto humanos como agentes.