Entre os casos que você apresentou, o único que não dá para substituir por view transitions e afins é ferramenta de colaboração em tempo real, mas a grande maioria dos sites não é uma ferramenta de colaboração em tempo real. Sites de marketing, dashboards e apps de comércio podem todos ser construídos excluindo frameworks SPA e seguindo as condições de renderização no servidor, páginas reais, animações baseadas em CSS, pré-carregamento intencional e adoção mínima de JS. Há também o Hotwire, da comunidade Rails, que busca essa direção, e existem casos em produção como Basecamp e HEY. Gerenciamento de estado? A menos que seja algo como ferramenta de colaboração em tempo real, métodos do lado do servidor como parâmetros de URL e sessão de servidor, ou então localStorage, já são suficientes. Também há claramente casos em que se adota SPA por causa das transições de página (como o site oficial da AGF, que poderia muito bem usar Astro, mas adotou React), e não dá para negar que transição de página é algo muito citado como uma das principais vantagens de SPA.
Há claramente casos em que se adota um framework SPA só por causa de uma única interação suave. Muitos dos sites que usam SPA nem precisam de interações complexas.
Nem tudo é endofunctor. Coisas com vários parâmetros de tipo, como Result<T, E>, não são 𝒞 → 𝒞, e sim Result : 𝒞 × 𝒞 → 𝒞, então esse tipo de coisa é um bifunctor.
Sua observação está absolutamente correta!
Acho que houve um mal-entendido no processo de aplicar ao contexto de Rust um conteúdo escrito com base em outra linguagem.
Como o sistema de tipos de Rust forma uma única categoria, parece que a distinção entre endofuntor e funtor geral perde o sentido.
É uma pena que o blog não tenha função de comentários; vou precisar perguntar se é possível solicitar uma correção.
Acho que essa pessoa está falando do custo da assinatura da IDE. O FLCC não é oferecido na versão gratuita.
Mas também não é como se as pessoas pagassem só esperando aquilo.
Interpreta de forma reduzida o verdadeiro propósito de uma SPA
A View Transitions API é realmente muito interessante, mas isso por si só não significa que uma SPA deixe de ser necessária.
Analisa todos os sites com o mesmo critério
Site de marketing ≠ dashboard ≠ app de comércio ≠ ferramenta de colaboração em tempo real
Cada um tem exigências estruturais diferentes.
Na prática, SPA + SSR + MPA coexistem
Frameworks híbridos como o Next.js mostram isso muito bem.
Recursos estáticos usam SSG, dashboards pós-login usam CSR/SPA, e compatibilidade com mecanismos de busca usa SSR; é necessária uma combinação flexível.
Acredito que a SPA está mais próxima de ser um produto de melhoria estrutural do que apenas de experiência do usuário.
Em páginas nas quais uma SPA é desnecessária, MPA + CSS moderno pode ser uma boa escolha, mas a SPA continua sendo essencial em termos de estrutura, estado, escalabilidade e manutenção. Acho que o CSS moderno pode "complementar" a SPA, mas não "substituí-la".
Embora seja verdade que os frameworks SPA atuais e a tendência de frontend baseada neles exijam vigilância constante contra a não padronização, além de tenderem a provocar overengineering e consumo desnecessário de recursos...
Acho também que a própria ideia de SPA está sendo vista de forma estreita, mas, mais do que isso, fico em dúvida se se entende que impacto os frameworks SPA exercem sobre o desenvolvimento como um todo.
Dizer que, com apenas a View Transition API, tendo CSS, já está tudo resolvido significa, em outras palavras, que todos os recursos não relacionados a isso, bem como o paradigma necessário para alcançá-los, seriam completamente sem sentido — e isso me parece uma visão arrogante demais.
Isso é uma questão diferente do overengineering de usar React para criar um site que mal passa de um substituto de folheto institucional.
Concordo que, na maioria dos projetos pequenos, não há necessidade de um framework SPA, mas, em serviços cujos requisitos envolvem interações complexas, experiência contínua do usuário, manutenção e melhorias constantes, penso que isso não deixa de ser necessário, apesar da evolução do CSS.
Pelo que sei, ao tentar usar isso em Kotlin, tipos primitivos acabam sendo encapsulados em wrappers, o que pode causar um problema de desempenho porque são armazenados no heap em vez da stack. Claro que, na maioria dos casos de uso, a manutenibilidade vem em primeiro lugar. Além disso, é possível minimizar o problema de desempenho usando value class.
Entre os casos que você apresentou, o único que não dá para substituir por view transitions e afins é ferramenta de colaboração em tempo real, mas a grande maioria dos sites não é uma ferramenta de colaboração em tempo real. Sites de marketing, dashboards e apps de comércio podem todos ser construídos excluindo frameworks SPA e seguindo as condições de renderização no servidor, páginas reais, animações baseadas em CSS, pré-carregamento intencional e adoção mínima de JS. Há também o Hotwire, da comunidade Rails, que busca essa direção, e existem casos em produção como Basecamp e HEY. Gerenciamento de estado? A menos que seja algo como ferramenta de colaboração em tempo real, métodos do lado do servidor como parâmetros de URL e sessão de servidor, ou então localStorage, já são suficientes. Também há claramente casos em que se adota SPA por causa das transições de página (como o site oficial da AGF, que poderia muito bem usar Astro, mas adotou React), e não dá para negar que transição de página é algo muito citado como uma das principais vantagens de SPA.
Há claramente casos em que se adota um framework SPA só por causa de uma única interação suave. Muitos dos sites que usam SPA nem precisam de interações complexas.
Nem tudo é endofunctor. Coisas com vários parâmetros de tipo, como
Result<T, E>, não são 𝒞 → 𝒞, e simResult : 𝒞 × 𝒞 → 𝒞, então esse tipo de coisa é um bifunctor.Sua observação está absolutamente correta!
Acho que houve um mal-entendido no processo de aplicar ao contexto de Rust um conteúdo escrito com base em outra linguagem.
Como o sistema de tipos de Rust forma uma única categoria, parece que a distinção entre endofuntor e funtor geral perde o sentido.
É uma pena que o blog não tenha função de comentários; vou precisar perguntar se é possível solicitar uma correção.
Bom texto! Só que a explicação relacionada ao endofunctor tem um erro, então seria bom corrigir isso: https://x.com/simnalamburt/status/1950074970647761168?s=46
king - man + woman = queen
Tem todos os recursos que você pensa "seria ótimo se tivesse". Esse cara sozinho faz o papel de um NAS inteiro.
Só de ver o site de demonstração já é algo bem impressionante. É incrível como tantos recursos são suportados com um código realmente tão curto.
Fui pego pela Komoot
NamuWiki...
Não entendo muito bem como verificação de idade e proteção de privacidade podem andar juntas..
No momento em que você faz a verificação, não é praticamente o mesmo que deixar sua assinatura ali pelo menos uma vez?
Se a ideia é realmente proteger a privacidade, então deveria ser possível usar de forma anônima
Excelente. Gosto muito desse tipo de abordagem.
Que bom ver uma metodologia de otimização não baseada em ML.
Acho que essa pessoa está falando do custo da assinatura da IDE. O FLCC não é oferecido na versão gratuita.
Mas também não é como se as pessoas pagassem só esperando aquilo.
O ponto fraco deste texto
Interpreta de forma reduzida o verdadeiro propósito de uma SPA
A View Transitions API é realmente muito interessante, mas isso por si só não significa que uma SPA deixe de ser necessária.
Analisa todos os sites com o mesmo critério
Site de marketing ≠ dashboard ≠ app de comércio ≠ ferramenta de colaboração em tempo real
Cada um tem exigências estruturais diferentes.
Na prática, SPA + SSR + MPA coexistem
Frameworks híbridos como o Next.js mostram isso muito bem.
Recursos estáticos usam SSG, dashboards pós-login usam CSR/SPA, e compatibilidade com mecanismos de busca usa SSR; é necessária uma combinação flexível.
Acredito que a SPA está mais próxima de ser um produto de melhoria estrutural do que apenas de experiência do usuário.
Em páginas nas quais uma SPA é desnecessária, MPA + CSS moderno pode ser uma boa escolha, mas a SPA continua sendo essencial em termos de estrutura, estado, escalabilidade e manutenção. Acho que o CSS moderno pode "complementar" a SPA, mas não "substituí-la".
Sinceramente, parece quando alguém fala de Rust ou Haskell sem nem ter encostado nelas e diz: "isso aí hoje em dia dá para fazer tudo com C++".
Embora seja verdade que os frameworks SPA atuais e a tendência de frontend baseada neles exijam vigilância constante contra a não padronização, além de tenderem a provocar overengineering e consumo desnecessário de recursos...
Acho também que a própria ideia de SPA está sendo vista de forma estreita, mas, mais do que isso, fico em dúvida se se entende que impacto os frameworks SPA exercem sobre o desenvolvimento como um todo.
Dizer que, com apenas a View Transition API, tendo CSS, já está tudo resolvido significa, em outras palavras, que todos os recursos não relacionados a isso, bem como o paradigma necessário para alcançá-los, seriam completamente sem sentido — e isso me parece uma visão arrogante demais.
Isso é uma questão diferente do overengineering de usar React para criar um site que mal passa de um substituto de folheto institucional.
Concordo que, na maioria dos projetos pequenos, não há necessidade de um framework SPA, mas, em serviços cujos requisitos envolvem interações complexas, experiência contínua do usuário, manutenção e melhorias constantes, penso que isso não deixa de ser necessário, apesar da evolução do CSS.
É bom ver tantas reflexões sobre trabalhar com busca vetorial.
Pelo que sei, ao tentar usar isso em Kotlin, tipos primitivos acabam sendo encapsulados em wrappers, o que pode causar um problema de desempenho porque são armazenados no heap em vez da stack. Claro que, na maioria dos casos de uso, a manutenibilidade vem em primeiro lugar. Além disso, é possível minimizar o problema de desempenho usando
value class.Como referência, o ticket de suporte ao Rust: https://github.com/android/ndk/issues/1742
Seria bom se algo assim surgisse também para C++!