1 min de leitura ·

Svelte On-Demand: Hot-reload em Produção

Hi guys,

Criei um pequeno mecanismo Node.js que compila e renderiza componentes Svelte sob demanda, diretamente em tempo de execução.

Sem etapa de build, sem Vite, sem pacotes pré-compilados.

A ideia é tratar os componentes Svelte como templates:

cache baseado em hash
compilar somente quando o arquivo for alterado
SSR + hidratação do DOM
recarregamento a quente em produção

Isso não se destina a substituir o SvelteKit.

É voltado principalmente para CMS, ferramentas internas e ambientes dinâmicos.

Estou curioso sobre:

possíveis problemas óbvios que eu possa estar ignorando
compensações de desempenho em comparação com o SSR tradicional
se esse modelo faz sentido a longo prazo

Código: https://www.npmjs.com/package/svelte-on-demand

jlucfarias

2 dias atrás

Espero ter entendido bem o projeto, mas acredito que a única coisa que faria sentido para o caso que você fala seria na alteração de componentes específicos que se alteram para não precisar buildar todo o projeto e fazer a alteração em produção de tudo, mas apenas da parte alterada. Seria isso? Se não, então não entendi um caso de uso para esse projeto

VictorPubh

Autor

2 dias atrás

É mais simples do que parece, a ideia aqui é servir Svelte sob demanda afim de evitar build anteriores.

Basta eu adicionar um .svelte e ele será compilado e servido em tempo de execução, isto é útil para casos onde você tem esses ".svelte" que mudam periodicamente.

No meu caso, a LLM é responsável por reescrever meus .svelte's e eu uso isso para servir sem build prévio.

Pilati

2 dias atrás

Hot-reload em Produção

Isso aqui não faz nenhum sentido!

Produção requere scripts estáveis, pré buildados e servidos da forma mais rápida possível.

Só o fato de verificar se precisa alterar o script já gera um gargalo ENORME.

Sem falar que essa abordagem impede completamente o uso de caches na borda (como cloudflare, akamai)

Nenhum projeto grande cogitaria usar uma abordagem assim.

Agora se você alterar para uma ferramenta que faz um "build sob demanda" a abordagem muda completamente.

VictorPubh

Autor

2 dias atrás

Exatamente, é um build sob demanda (o que também permite hot-reload nativo).

O fluxo funciona assim:

O usuário solicita um recurso (por exemplo, acessando uma página).
O sistema verifica se existe um cache baseado na hash do conteúdo. Se existir, retorna o recurso imediatamente.
Se não houver cache, ele compila o recurso sob demanda, armazena em cache e retorna.

Além disso, os recursos são servidos de forma inteligente, combinando SSR + DOM Hydration, garantindo uso eficiente do cache de borda. Isso oferece um dinamismo maior que um SSR tradicional, porque o sistema compila e entrega simultaneamente os dois formatos, adaptando-se ao contexto do usuário e à performance necessária.

Pilati

2 dias atrás

Perfeito, então é um conceito um pouco diferente.

Hot Reload:

Usuário solicita o componente Home.js
O sistema envia o arquivo Home.js
O Home.js é alterado no servidor
O usuário recarrega a página
O sistema envia o novo Home.js

Isso aqui mata o desempenho das caches

Build sob demanda

Usuário solicita o componente Home-123.js
sistema serve ......
O Componente Home é alterado no servidor
O sistema compila para Home-124.js
Usuário recarrega a página e passa baixar Home-124.js

Isso aqui é extremamente eficiente

O de baixo não é hot-reload, pois ele precisa buildar o arquivo novamente, referencia com um novo "id" e passa a serevir um arquivo totalmente diferente.

VictorPubh

Autor

1 dia atrás

Então, a solução está no meio termo entre hot-reload e build sob demanda.

O nome como sugere "On Demand"...

Considere que:

Não é um hot-reload clássico (porquê ele realmente recompila na "borda")
O hot-reload clássico não faz o menor sentido aqui; A compilação do recurso é muitíssimo veloz (nesse caso em específico, podemos incluir)

Ou seja, é um hot-reload, mas não é um hot-reload clássico; Admito que eu me expressei mal, você tem razão.