Tenets

Artigo original ↗ Discussão no Hacker News ↗

Os recém-articulados “tenets” do Svelte — priorizando “good vibes”, design centrado em HTML e uma experiência de programador “magical, not magic” — provocam fortes reações sobre o que uma framework frontend deve otimizar. Os apoiantes elogiam o Svelte (e frequentemente o SvelteKit) por reacender o prazer no desenvolvimento web, por resultados rápidos e por um modelo mental acessível em comparação com React/Next, enquanto os críticos questionam objetivos vagos, não gostam da DSL e do modelo de reatividade do Svelte e receiam mudanças de sintaxe no Svelte 5. A discussão alarga-se para um debate mais amplo sobre a adequação do HTML como linguagem fundamental de UI, os tradeoffs entre magia e explicitude, e o valor de ecossistemas estreitamente integrados versus toolchains de peças escolhidas à medida.

Reação Geral aos Tenets

  • Muitos apreciam ver a filosofia da framework escrita; isso esclarece por que gostam (ou não gostam) de usá-la.
  • Alguns acham que o documento é demasiado vago ou com tom de marketing e que não acrescenta perceção prática, mesmo concordando com muitas das escolhas subjacentes.
  • Uns poucos leem-no quase como uma admissão de que a framework não está a tentar ser “objetivamente melhor”, apenas alinhada com o seu próprio gosto.

“Best Vibes” e a Experiência do Programador

  • Os apoiantes interpretam “best vibes” como: padrões intuitivos, APIs minimalistas, poucas otimizações manuais e uma comunidade útil, orientada por exemplos.
  • Os críticos chamam “good vibes” a algo sem conteúdo: poderia justificar qualquer troca, toda a framework afirma ter boa DX, e isso arrisca silenciar críticas concretas.

HTML, Templates e Filosofia de UI

  • Um grupo vê o HTML como a forma natural, nativa do navegador, de descrever UI; frameworks que permanecem próximos do HTML (templates, JSX, sintaxe Svelte) são vistos como mais fáceis de raciocinar e depurar.
  • Outro grupo acha que o HTML/DOM é um substrato de UI profundamente falho, especialmente para apps complexas e altamente interativas, e compara-o desfavoravelmente a toolkits de desktop, sistemas de restrições, canvas/WebGL ou UIs imperativas.
  • O desacordo também surge em torno de “lógica no HTML vs HTML no JS”, separação de responsabilidades e o valor de linguagens de templates minimalistas face a linguagens de programação completas.

Magia vs Explicitude; Reatividade

  • A frase “magical, not magic” ressoa com pessoas que querem que as coisas pareçam fáceis, mas ainda compreensíveis.
  • Outros queixam-se de que a reatividade anterior do Svelte (por exemplo, labels $:) já parecia demasiado mágica e confusa.
  • Alguns argumentam que a maioria dos utilizadores de React também não entende os seus internos, pelo que as queixas sobre a “magia” do Svelte são inconsistentes.

Svelte 5 e Runes

  • O novo sistema de runes e a sintaxe $props são polarizadores:
    • Os fãs veem-nos como uma redução do comportamento implícito, alinhando a reatividade mais de perto com padrões padrão de JS.
    • Os detratores não gostam dos novos identificadores mágicos, sentem que isso se afasta de “apenas JavaScript”, aumenta a carga cognitiva e tornará o Svelte mais difícil de ensinar; alguns dizem que talvez não adotem o Svelte 5.

Comparações: React, Vue, Next.js, Outros

  • Muitos relatam que Svelte (e frequentemente SvelteKit) parece mais leve, mais produtivo e “divertido”, especialmente em comparação com a complexidade percebida do React/Next.js e a expansão do ecossistema.
  • Alguns preferem o ecossistema e a documentação mais unificados do Vue; outros acham Svelte superior ao Vue.
  • Há críticas duras às direções recentes do Next.js (App Router, RSC, comportamento de cache).
  • Alternativas como Astro+Svelte, HTMX mais HTML renderizado no servidor, e sistemas clássicos de templates são mencionadas como caminhos agradáveis e de menor complexidade.

SvelteKit, Ferramentas e Praticidades

  • SvelteKit recebe avaliações mistas: alguns gostam dele profissionalmente; outros não gostam das suas convenções de routing (+page files), limitações de backend e acoplamento à estrutura de ficheiros.
  • Surgem preocupações sobre boilerplate para projetos simples e sobre o site oficial não funcionar em versões mais antigas do Safari.
  • O Lighthouse é discutido como uma métrica útil, mas imperfeita, que pode ser manipulada e não deve ser tratada como medida definitiva de desempenho ou acessibilidade.