[JavaScript] React FTW!

[gpedro]

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/

[cyberglot]

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.

[hugooliveirad]

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).

[cyberglot]

@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.

[hugooliveirad]

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 😄

[cyberglot]

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.

[bernardodiasc]

@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.

[cyberglot]

@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.

[bernardodiasc]

Interessante. Seria o virtual DOM a solução do React em relação a performance?

[hugooliveirad]

Com certeza! Olha só essa explicação.

[cyberglot]

@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).

[bernardodiasc]

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/