Executando verificação de segurança...
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.

Carregando publicação patrocinada...
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?

1

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.