poste-mais
poste-mais copied to clipboard
frontendbr
[JavaScript] React FTW!
O que vocês acham do futuro promissor dele? Que tal alguns posts da mesma linha de "Iniciando Estudos com JS"
@jugoncalves postou um link sobre Netflix likes react @hugobessaa mandou no crew.js sobre React Native
(está tendo/tem) uma conferência só para falar dele. http://conf.reactjs.com/
Ontem eu comecei a fazer uns experimentos com React e Riot e (se minha intuição estiver correta) vou escrever um artigo sobre como não dá pra ter perf em processamento e ter bibliotecas extremamente pequenas com os browsers/apis que a gente tem hoje em dia.
Não dá pra ter performance de execução? Caramba, fiquei curioso.
Tem o Começando com React no meu blog (tradução de um post em inglês).
@hugobessaa não sei, vamos ver o que vai dar. :) mas o que eu testei ontem parece que o Riot não aguenta se dar lag depois de X components. Claro que foi um experimento intermediário (i.e. quick and dirty), estou planejadno um experimento compreensivo agora.
Ah, entendi. A questão é sobre a falta de performance do Riot.
Eu achei ele muito acoplado à ideia ultra minimalista do criador. Por um lado é legal, por outro pode trazer problemas. Bom, não testei para ter certeza. Esperando suas considerações :smile:
A conclusão que eu quero chegar é: as specs/implementações/apis do DOM não estão prontas para in-browser apps de larga escala (ou seja, Real World TM apps). Entretanto, não sei se React vs Riot é o suficiente para provar isso. É um longo caminho ainda, talvez isso demore um pouco pra sair.
@jugoncalves muito me interessa sua pesquisa sobre esse assunto. o que entendi, resumidamente, da discussão sobre fazer marcação pelo browser é que é mais facil e mais divertido para dev, mas tem um preço alto em performance. to pensando em escrever algo sobre client-side X server-side rendering em breve.
@bernardodiasc a ideia é de que se vc não usar outras formas para evitar usar o DOM ao máximo, vc inevitavelmente vai ter problema de performance ao longo prazo (i.e., se não usar Virtual DOM e outros approaches parecidos OU proporem uma api melhor para o DOM). e isso é especialmente grave quando vc tá lidando com observers + DOM, sem contar que fica bem difícil de lidar com concorrência quando vc tem shared mutable state.
certamente server-side rendering vai te dar uma perf melhor, porém, nem tudo vc pode mandar para o server resolver. animações, gráficos e outras visualizações dinâmicas não rola.
Interessante. Seria o virtual DOM a solução do React em relação a performance?
@bernardodiasc Acredito que o problema maior nesse sentido é ponte que vc deve percorrer entre a engine de JavaScript e a engine de renderização (V8 <-> Blink, por exemplo). Se vc ficar atravessando de um lado para o outro (que basicamente o que 2way data binding faz), você vai acabar tendo sérios problemas de performance. O React, entretanto, mantem o grosso do processamento na engine de JavaScript (que é o correto, já que é pra isso), atravessando para a engine de renderização somente quando necessário. Mas isso viria em algum momento, já que é uma estratégia comum em CG (batching).
Fiz uma pequena coleção de referencias e recursos sobre React enquanto estudava sobre o assunto, pode ser acessado aqui https://x-team.github.io/x-labs/react/