Interessante. O que você disse, de forma geral, é bem parecido com o que meu colega mencionado no post me disse. Consegue lembrar de exemplos de projetos feitos assim que mostrem como isso de fato acontece? Uma das coisas que sustentou minha descrença com o que meu colega dizia é que ele não conseguia mencionar nenhum projeto grande que teve êxito com essa estratégia, mas apenas UIs simples que serviam como interface pra CRUD. Obrigado!
Respondendo a "SPA + REST já morreu, só esqueceram de avisar o..." dentro da publicação Como defender o fim do padrão SPA + REST?
1
0
tabnews?!
1
Sim, o tabnews é feito em Next com SSR. Isto só é possível justamente porque é um projeto simples do tipo blog que existe há decadas. A UI não passa de forms e tables, como mencionei no meu post.
No final do meu post, inclusive, escrevo:
De qualquer modo, para defender que o JS é apenas um adicional irrelevante para um sistema e que o REST mais prejudica do que beneficia num projeto é preciso antes provar que não existe nenhum caso onde um projeto SPA poderia ser completamente reescrito desta forma sem aumentar sua complexidade e preservando todos seus comportamentos.
Até onde entendo, não é possível ter uma UI reativa apenas com SSR. O Next é o que mais se aproxima disso, mas justamente porque permite fazer um projeto híbrido. Hoje mantenho 3 web apps B2B em Next e afirmo que 90% dos componentes que escrevemos são forçados a serem client-side.
1
Talvez seja apenas uma questão de definição.
Ninguém está defendendo o fim do client-side, o que se discute é o fim do padrão "enviar JSON por REST e renderizar tudo em JS".
O que muita gente (eu incluso) defende é justamente o oposto: clientes cada vez mais ricos, autônomos e inteligentes, que não dependam de REST para existir. Aplicações inteiras podem (e devem) ser empacotadas com Service Workers, usando SQLite e o Canvas via wasm para persistência e renderização de verdade..
Isso é client-first, não SPA..