Turbo Links

[Luis Mendes]

Sou só eu ou também vós parece que o turbo links é uma ideia meia parva?

https://github.com/rails/turbolinks

Podem ver uma explicação mais detalhada e um exemplo aqui:

http://vimeo.com/51181496 (minute 9:30)

Basicamente o que o turbo links vai buscar por Ajax o conteúdo da página, extrai o conteúdo do BODY da página de resposta e substitui pelo BODY da página que está a ser exibida, evitando o reload de javascript e css do HEAD.

Luís Mendes

[Ivo Jesus]

Luis,

  Muito longe de uma ideia "meia parva", eu diria uma ideia excelente! Não sei se já tiveste oportunidade de brincar com coisas como o pjax, que é onde esta ideia de turbolinks vai buscar inspiração (segundo o próprio DHH), mas isto efectivamente ajuda num numero de coisas:
1) Mais rápido,
2) menos "payload"
3) menos "compiling" de javascript no browser..

Claro que tem implicações na qualidade do javascript que vais colocar no browser, mas são implicações positivas na medida em que vão obrigar a fazer código menos "leaky"..

Eu tenho uma app onde faço algo semelhante ao que os turbolinks fazem e efectivamente nota-se a diferença, agora, isto vai depender um pouco de caso pra caso. Seja como for, sempre podes optar por não usar..

link_to ....., :"data-no-turbolink" => true


Ivo Jesus

--
You received this message because you are subscribed to the Google Groups "ruby << portuguese" group.
To post to this group, send email to rub...@googlegroups.com
To unsubscribe from this group, send email to ruby-pt-u...@googlegroups.com
For more options, visit this group at http://groups-beta.google.com/group/ruby-pt , or it's site : http://www.ruby-pt.org

[José Mota]

Acho que isto tem o mesmo caráter que teve o Coffeescript: opcional. Pelo menos para mim :)

Para já o que estou a ver que pode acontecer é que a malta vai ter de começar a pensar duas vezes na forma como regista eventos com jQuery… o que disse o Ivo mas em termos práticos.

Eu pessoalmente estou a investir no Ember já para não estar a depender tanto do Rails para construir o front-end. Inclusivamente, se for caso disso, tenho possibilidade de trocar para outro back-end. Imagine-se um cenário em que se usava Java e troca-se para JRuby ou Python… já me aconteceu ter de pensar em algo assim há pouco tempo.

--
José Mota
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

> --
> You received this message because you are subscribed to the Google Groups "ruby << portuguese" group.

> To post to this group, send email to rub...@googlegroups.com (mailto:rub...@googlegroups.com)
> To unsubscribe from this group, send email to ruby-pt-u...@googlegroups.com (mailto:ruby-pt-u...@googlegroups.com)

[Nuno Fernandes]

Pergunta de quem não leu tudo e não procurou uma resposta:

E a nivel de SEO? Um google que passe pela pagina continua a conseguir
ver o resto do site?

2012/10/19 José Mota <josemo...@gmail.com>:

[Ricardo Mendes]

É uma ideia parva.

2012/10/19 Nuno Fernandes <nf.ria...@gmail.com>:

[Manuel Silva]

Na realidade também me parece um pouco parvo.

Acho mais piada ao pjax ou ao que o twitter faz que é ir buscar fragmentos. Tem mais lógica acho eu.

[Luis Mendes]

Ivo,

Acho que o teu ponto 1 e 2 não são assim bem como dizes, estive a brincar com aquilo ontem e pelo que vi no que toca ao payload, é gerada e enviada via "wire" a página por completo, o turbo links como disse descarta tudo que não esteja no BODY, por isso não é por ai, o que a meu ver diminui são os pedidos HTTP pelos assets (javascripts e afins que estejam no HEAD) se bem que o overhead deles é insignificate porque na maioria das vezes são devolvidos HTTP 304 Not modified (ok, aqui concordo que estes requests deixem de existir o que é sempe bom case se use o turbolinks).

Já o ponto dois é um dado adquirido, tens menos compile time do lado do browser, mas para um site "standard" onde o frontend não esteja dominado por algo com o Backbone.js ou  com o Ember como refere o José parece-me que as vantagens são imperceptíveis. 

Já o código leaky vai ser ela por ela... o pessoal já descobriu o live e algo me diz caso usem turbo links vai ser por ai onde todos se vão agarrar, para o bem ou para o mal...

José Mota, só true, para mim vai ser mesmo opcional até encontrar um "use case" em que me faça sentido, até lá fico-me pelo mal que conheço.

lmm

Luís Mendes

2012/10/19 José Mota <josemo...@gmail.com>

[Mário Lopes]

Eu pessoalmente estou a investir no Ember já para não estar a depender tanto do Rails para construir o front-end. Inclusivamente, se for caso disso, tenho possibilidade de trocar para outro back-end. Imagine-se um cenário em que se usava Java e troca-se para JRuby ou Python… já me aconteceu ter de pensar em algo assim há pouco tempo.

Eheh, é curioso que sempre que sai uma nova tecnologia, existem claramente dois grupos distintos:

A) Aqueles que saltam imediatamente para aquela tecnologia por ser o next holy grail e a tentam usar em tudo;

B) Os Velhos do Restêlo, geralmente barbudos mas conheço excepções, que recusam tudo o que seja novo e/ou esteja na moda;

Depois há uma espécie de Z, um omega, pelo qual eu me tento reger (mas só recentemente, porque dantes era claramente um tipo A): encontrar um problema e, na procura da solução para o problema, chegar à tecnologia. O que contrasta com escolher a tecnologia e encontrar o problema que tem como solução usar X ou Y.

Mário

[Ivo Jesus]

Luis,

  Se calhar não me expressei bem. A pagina sim, virá completa, agora, ao não teres de carregar os restantes assets o "payload final" da página é menor, e isso por si só já representa uma boa vantagem. Eu acho que é justamente naqueles sites "standard" non-backbone (e afins) que a vantagem se poderá ver (e enfatizo aqui o "poderá ver"). Backbone e afins em nada tiram vantagem dos turbolinks...

  O código "leaky" e o live é todo um outro universo, até porque o "live" do jQuery está deprecated e existem já formas melhores de fazer a coisa trabalhar... Quando falo em "leaky code", falo em DOM elements a ficarem pendurados em referências JS e situações dessas por causa de event handlers, state variables, etc.. Isto são problemas que normalmente não se notam em webapps tradicionais "cheias" de page loads e page unloads, mas que num caso como este começam a fazer mossa...
 
  Mais uma vez digo, os turbolinks não são obrigatórios, usa quem considerar que trazem vantagem. Eu acredito que podem trazer vantagem mas depende do caso, não acho que sejam a oitava maravilha... Claro que para a loja de batatas do tio manuel não vai trazer nada de novo a não ser potenciais dores de cabeça, mas eu vejo com bons olhos a introdução deste tipo de feature.

Ivo Jesus

[Luis Mendes]

Olá Ivo,

Quando falei em usar o live, foi mais porque toda a gente conhece o que faz, no sentido em que novos elementos adicionados ao DOM são "abençoados" com os eventos registados,  já imagino o pessoal a tentar usar live/delegate/on para tudo que é eventos por causa do turbo links.

Mário não me considero um velho do Restelo, gosto de trabalhar com as melhores ferramentas para cada um dos problemas que enfrento dai estar a por em causa o turbo links para perceber que problemas vem solucionar, pois não vejo nenhum "use case" prático para sua utilização onde a meu ver este não venha a causar é um pouco mais de complexidade ou mais um ponto de falha, enfim é capaz de ser é falta de imaginação do meu lado...

O lado bom é ser como vocês dizem opt-in por isso fica ao critério de cada um a sua utilização como o CoffeeScript, 

Luís Mendes

2012/10/19 Ivo Jesus <ivo....@gmail.com>

[Paulo Köch]

O nome é demasiado hype dos anos 90, sim. Não, não inspira confiança nenhuma. :P

Gostei do twist que deram ao pjax. Os turbolinks são pjaxs pelo
<body/>. That simple.

Acho que o aviso do DHH foi sincero mas infeliz no wording. O que ele
quer dizer é: os turbolinks não se dão à sloppyness de gestão de
memória em JS da mesma maneira que fazer sempre reload da página toda.
Mind your code, que podem estar a usar a muleta do reload sem saber.
Não se venham chorar dos vossos memory leaks a mim.

A nível de melhorias de reponsiveness, acho que nem sequer ter que
pedir o 304 ajuda sempre. Em algum casos, pode fazer a diferença
(tanto client side como server side).

Isto não substitui, nem quer, pedidos por partes de página, como
apontaram o Manuel Silva e o Luís Mendes. É mesmo só para dar um extra
boost de graça em aplicações "menos RIA", digamos. Se o podemos ter de
graça (ou por muito pouco, vá), porque não?

Usaria se não tivesse que investir mais de 5 minutos a mudar o meu
código actual ou se precisasse mesmo do boost (acho que se precisasse
mesmo do boost, haveria desafios com mais frutos, mas ok).
My 2 cents.

[Mário Lopes]

Mário não me considero um velho do Restelo, gosto de trabalhar com as melhores ferramentas para cada um dos problemas que enfrento dai estar a por em causa o turbo links para perceber que problemas vem solucionar, pois não vejo nenhum "use case" prático para sua utilização onde a meu ver este não venha a causar é um pouco mais de complexidade ou mais um ponto de falha, enfim é capaz de ser é falta de imaginação do meu lado...

Luis, concordo contigo. O comentário não foi direccionado a ti nem a ninguém. Foi apenas um pensar em voz alta, de algo que tem a sua piada.

Um abraço,

Mário 

[Rúben Fonseca]

Olá

2012/10/19 Paulo Köch <paulo...@gmail.com>:

> A nível de melhorias de reponsiveness, acho que nem sequer ter que
> pedir o 304 ajuda sempre. Em algum casos, pode fazer a diferença
> (tanto client side como server side).

Devo dizer que quando experimentei o turbolinks pela primeira vez
achei super fixe, super rápido, a "internet" parece que passou a ser
2x mais rapida UAU! E tão simples! Brutal!!

Depois fiz deploy do server para o heroku.......

Não sei se é do meu browser (Safari) ou whatnot, o simples facto de
teres 100-300ms de lag entre carregares num link com turbolinks e a
página "responder" é brutalmente estranho e incómodo. Basta um request
demorar um bocadinho mais e parece que o teu "click" na realidade não
clicou em nada, porque o browser (again, Safari) não te dá indicação
nenhuma do que está a acontecer.

Por isso turbolinks talvez seja fixe, mas não sozinho. Ou tem que
haver algo mais do lado do Frontend para te dar a indicação de loading
(bad, porque isso é trabalho do browser I guess), ou terá que haver
melhor integração com os browsers. Será que no Chrome o comportamento
é melhor?

Ruben

--
Will work for bandwidth

[Ivo Jesus]

Ruben,

Ainda não usei a feature a não ser no chrome...
Os turbolinks usam pushstate, portanto assumo que num browser mais antigo a coisa não funcione tão graciosamente.. mas é uma questão de testar...

Ivo Jesus

Em 2012/11/15 08:37, "Rúben Fonseca" <fon...@gmail.com> escreveu:

Olá

2012/10/19 Paulo Köch <paulo...@gmail.com>:

> A nível de melhorias de reponsiveness, acho que nem sequer ter que

> pedir o 304 ajuda sempre. Em ...

Devo dizer que quando experimentei o turbolinks pela primeira vez
achei super fixe, super rápido, a "internet" parece que passou a ser
2x mais rapida UAU! E tão simples! Brutal!!

Depois fiz deploy do server para o heroku.......

Não sei se é do meu browser (Safari) ou whatnot, o simples facto de
teres 100-300ms de lag entre carregares num link com turbolinks e a
página "responder" é brutalmente estranho e incómodo. Basta um request
demorar um bocadinho mais e parece que o teu "click" na realidade não
clicou em nada, porque o browser (again, Safari) não te dá indicação
nenhuma do que está a acontecer.

Por isso turbolinks talvez seja fixe, mas não sozinho. Ou tem que
haver algo mais do lado do Frontend para te dar a indicação de loading
(bad, porque isso é trabalho do browser I guess), ou terá que haver
melhor integração com os browsers. Será que no Chrome o comportamento
é melhor?

Ruben

--
Will work for bandwidth

--
You received this message because you are subscribed to the Google Groups "ruby << portuguese" ...

[Rúben Fonseca]

Olá,

2012/11/15 Ivo Jesus <ivo....@gmail.com>:

> Ruben,
>
> Ainda não usei a feature a não ser no chrome...
> Os turbolinks usam pushstate, portanto assumo que num browser mais antigo a
> coisa não funcione tão graciosamente.. mas é uma questão de testar...

Safari suporta mto bem pushstates, os URLs são bem alterados. Mas acho
que o pushState não pode fazer nada em relação ao loading state da
página (acho?)

Ruben

> "ruby << portuguese" group.
> To post to this group, send email to rub...@googlegroups.com
> To unsubscribe from this group, send email to
> ruby-pt-u...@googlegroups.com
> For more options, visit this group at
> http://groups-beta.google.com/group/ruby-pt , or it's site :
> http://www.ruby-pt.org