Hace 5 años | Por oraculus_reload... a logrocket.com
Publicado hace 5 años por oraculus_reloaded a logrocket.com

En este artículo, explicaremos por qué debes dejar de crear sitios web con un desplazamiento infinito.

Comentarios

S

#14 eso está calculado...

montaycabe

#19 no esta calculado porque no saben cuando vas a hacer clic. Es una mala implementación del código, que hasta que no carga una imagen no sabe que tamaño tiene, y se ve obligado a reajustar todo lo demas. Es evitable pero no se hace

I

#24 Esta calculado. Yo lo he hecho, son técnicas de masketing online.

D

#43 Pues entonces son MALAS técnicas. Hacen que me vaya y no vuelva.

S

#24 ... a ver era una coña no coña... pero venga va ya que alguien ha contestado...

Era una coña pq a todos nos ha pasado y suele ser azar... pero no era una coña porque yo mismo lo he montado y mil personas como yo... usando mapas de calor y tiempos medio de reaccion, teniendo 4 visitas no sacas nada teniendo cientos de miles si, y pasar de un 2.4% de ctr de a un 4 o a un 5 (tengo webs con un 6 o 7% sin hacer cosas raras y no google no dice nada siempre y cuando les cuadren las cosas) hace que merezca la pena estas mierdas con la diferencia mensual.

Ahora recuerdo incluso un sitio conocido que tira las imagenes de un CDN que no es un CDN realmente y que todas las imagenes tardan 1.8segundos en cargar siempre... que puede ser mala implementacion, pues si, pero que resulta curioso cuanto menos que con conexiones con latencias grandes o minimas y 100, 300 o 600 megas sea igual siempre los tiempos...

S

#52 Por cierto... aclaro que estas mierdas las hacia hace años... la ultima fue hace 2 o 3 por encargo... a dia de hoy te rentan mas otras cosas

D

#52 haciendo del mundo un lugar mejor... 😂 😂

P

#14 pica sobre el logotipo de AdChoices y denuncia la página. Eso está penalizado.

D

#38 Hombre, si hiciera un clic en un sitio y marcara en otro sí. Si tuviera una mega fibra óptica cuántica de 30Gbps no pasaría eso, pero con mi ADSL de 10Mbps (que no llegan) y soliendo tener el emule en segundo plano..., pues me sucede.

Jakeukalane

#14 adblock

D

#1 REDDITT !!

D

#20 Si te va lenta en ese pepino, algo tienes mal. Por otro lado, la culpa del mal rendimiento en algunos sitios (sobre todo periódicos) es la publi.

pip

#27 no tengo nada mal, lo que hay son chorrocientosmil javascript y mierdas diversas cargadas.

MacMagic

#20 Creo que ninguna web me va lenta y tengo tu mismo PC, quizas estas exagerando.

Lo que si veo cada vez más preocupante es el alto consumo de recursos de aplicaciones nativas en ordenadores, tabletas y móviles.

Parece que se ha perdido la cultura de la optimización de código y recursos.

pip

#31 todas las de Atlassian por ejemplo, van lentas, sobre todo Jira. El propio GMail cada vez más lento lo que es el correo en sí.
Los periódicos y eso ya ni hablamos y aunque sea por publicidad ahí está.

Y casi todas las demás, porque como decían en un artículo el otro día con los ordenadores que tenemos menos de 60fps no debería de ser aceptable en nada.

La cultura de optimizar se ha perdido hace 20 años por lo menos.

MacMagic

#33 Pues a mi no me va nada de eso lento ¿que SO usas?

Porque ya te digo, he estado en trastos como Core 2 Duo y 2GB con XP y eso iba bien.

¿No estarán usando tu fabuloso ordenador para minar bitcoins?

pip

#35 en casa Debian, en el curro Ubuntu o Windows 10. Máquinas parecidas. Con Chrome o con Firefox (con ese más lento), o la cosa esa de Microsoft, da igual, va lento.

Si me dices que Jira no te va lento es que tienes una percepción distinta de la velocidad, porque Jira va lento en cualquier ordenador.

JohnSmith_

#36 Pues el jira a mi me va bastante bien. El login no, eso se lo piensa bastante, pero una vez logueado se menea bastante bien. Vamos, que nunca me ha dado esa sensacion de querer tirar el ordenador por la ventana mientras espero que cargue la puta incidencia.

MacMagic

#36 Jira va bien, el problema creo que es con los dashboard que se crean, si tienes mucha complejidad se vuelve lento y pesado.

Lo se porque tengo en el curro varios boards en Kanban y le cuesta, pero si haces búsquedas y demás va rápido.

Pero estoy con #76, nunca he sentido la necesidad de preparar un café mientras cargaba, eso con el XP core 2 duo, eran 10 minutos de inicio.

squanchy

#33 Gmail cambió su web hace un par de semanas, y desde entonces la experiencia de usuario con una conexión lenta, es pésima. De marcar correos, darle al botón de eliminar, y tener que esperar 5-10 segundos a ver si los borra o no.

pawer13

#61 y con una conexion rápida sigue igual, la han cagado bien con la última versión

D

#15 SI una web no se puede utilizar (leer, reproducir, navegar, comprar, contactar) con el Javascript desactivado, está mal hecha.

¡Amén!

#20 A lo mejor deberías probar a bloquear contenido.
Desde que instalé uBlock Origin soy un poco más feliz cuando navego. Lo tengo configurado de tal manera que bloquee todo JS y demás porquería. Es flipante ver cómo algunas Webs se quedan bloqueadas al 70%, otras ni las veo directamente. En esos casos me pregunto si el contenido me va a aportar algo realmente. Casi siempre es no y entonces cierro y a seguir navegando.

Ahorro tiempo y no lleno mi cerebro de tanta basura.

squanchy

#41 Yo también lo uso, junto con privacy badger.

Jakeukalane

#20 a mi cuando una web va lenta primero suelo pensar (y acierto normalmente ) que la culpa es del sistema operativo.
Pero habiendo visto lo que pasa cuando intentas cargar un dominio grande de más de 10.000 elementos o algunas muy mal implementadas pues no descarto que tengas toda la razón.

pingON

#15 tus deseos son ordenes....

en una raspberry pi:
http://cineando.plus (cartelera de cine de Zaragoza, Huesca y Teruel)

http://transbordoszgz.es (tiempos de espera y hora de llegada a tu destino de una línea de autobús urbano de Zaragoza)

D

#47 Obviamente decir "Sin Javascript" es una exageración para que se entre en razón respecto al abuso de JS para la más mínima funcionalidad.

- AJAX es de los 90.
- En cualquier api RESTful se puede devolver información en el formato que se quiera: JSON, YAML... y XML / HMTL: existen los formularios y su propiedad method.
- Las validaciones del lado de cliente, deben está siempre también controladas del lado del servidor. En caso contrario es mala práctica.
- ¿Y eso es malo? Otra moda sin sentido https://adamsilver.io/articles/the-disadvantages-of-single-page-applications/
- ¿Y la respuesta de las API's no se tienen que "renderizar" del lado del servidor?
- Si erradicas el JS por completo claro que no, pero es algo que no tiene nada en dar un paso atrás por el abuso actual.

Toma, igual te sirve está guía de IBM: https://www.ibm.com/developerworks/library/wa-aj-unobtrusive/

Lo que ocurre es que los script kiddies han tomado el mundo.

squanchy

#57 Las validaciones del lado de cliente, deben estar siempre también controladas del lado del servidor. En caso contrario es mala práctica.
¿Mande? Yo hago las validaciones en cliente, y conecto con un servicio WCF para escribir esos datos en la base de datos, y punto. No sé por qué motivo voy a tener que hacer un paso extra totalmente innecesario.
Respecto a las SPA, llevo más de una década trabajando con ellas, y nos ha ido de fábula. Simplemente el usuario se acostumbra a trabajar en el navegador como si tuviese abierta una aplicación de escritorio. No espera el comportamiento convencional del navegador (que son las "desventajas" que cita tu enlace).

squanchy

#66 En mi caso, todo el código susceptible de ser manipulado está en el cliente. El servidor es una DLL. La aplicación cliente sólo puede solicitar al servidor datos de la base de datos, o enviar datos para guardar. Las consultas son predefinidas y están en una tabla, de manera que la aplicación cliente sólo puede decir "dame los datos de la consulta con id=PROVEEDORES12", pero en ningún caso puede inyectar sql en esas consultas. Y lo mismo para guardar datos.

#77 En el servidor se valida que el cliente tenga abierta una sesión (ha tenido que hacer login). También se hace un hash de los datos enviados, y se valida en el servidor para comprobar que no han sido alterados. No tengo que validar cada campo de un formulario, si no solamente el hash, y en caso de no coincidir, rechazar esa petición.

p

#79 Suena interesante lo que dices de la validación mediante hash pero no me queda claro.
Generas un hash con los datos una vez validados, haces el submit y ¿con qué lo comparas en el servidor? ¿O es que pones un input hidden con un hash asociado a una session del usuario y compruebas ese hash enviado con el del servidor?

squanchy

#81 En el cliente, genero un hash que depende de los datos que voy a enviar y que incluye algunos datos de la sesión abierta. P.e., puedo enviar un id de sesión, para que el servidor sepa qué usuario está realizando la petición, y en el hash puedo incluir el timestamp del momento del login. Ese timestamp es un dato que no viaja, si no que lo tiene por un lado la aplicación cliente, y por otro lo tiene guardado el servidor desde que se hizo dicho login.
El propio hash también se envía. En el servidor recalculo el hash con los datos que me han llegado y los datos de sesión que tengo almacenados (y que no han viajado), y lo comparo con el recibido. Si no coincide, es que me han hecho una inyección, y la petición es rechazada.

p

#84 Entiendo. Pero entonces podría simular ese POST, pongo datos que no validan, genero el hash y te hago el submit, cuando tu recibas los datos, generas el hash con esos datos que no validan pero coincidirá el hash y por lo tanto lo tomarías como válido.

D

#84 Si ese hash no está firmado criptográficamente, sirve para limpiarse el culo.

Y la inyección no es solamente que alguien intercepte los datos y los modifique, si no que un cliente malicioso te envíe datos incorrectos. Siempre, siempre hay que validar en el lado del servidor.

p

#63 ¿No validas en servidor? ¿Y cómo te aseguras que un usuario no modifica el JS y te envía datos que no son válidos por ejemplo?
No tengo ni idea que es eso de WCF, pero si tu no lo haces, me imagino que WCF lo hará por tí bajo unas premisas que hallas indicado en la base de datos, sino es un agujero de seguridad enorme.

P

#63 eres un loco temerario. En el cliente por usabilidad, en el servidor por seguridad.

P

#63 No sé cómo funcionan los WCF porque nunca los he usado, pero si no validas en el servidor, ¿cómo evitas que se manipulen los datos en el lado de cliente y te envíen datos sin validar?

P

#57

- AJAX no es de los 90 y menos en web. A finales de los 90 había iframes y era lo más parecido. Hasta inicios del 2000 en las webs no se podía cargar contenido parcial sin recargar.

- Una llamada de un API Restful no puede devolver una página web completa, bueno, no debería porque desarrollar un API para renderizar webs completas es absurdo.

- Las validaciones se deben hacer en ambos lados, ¿yo he dicho lo contrario?. En el lado del cliente por usabilidad y evitar llamadas al servidor inútiles y en el lado del servidor por seguridad y porque no siempre es una web la que consume un API, puede ser cualquier otro dispositivo.

- Las SPA una moda sin sentido..., apúntatelo y vuelve a leerlo dentro de 20 años.

- La respuesta de un API, por ejemplo si es JSON, se crea en el servidor pero es infinitamente más liviano que renderizar html e insertar los datos donde se deba hacer. Además te permite que esa API sea consumida por dispositivos móviles o integrar con sistemas de terceros.

P

#86

AJAX = Asynchronous JavaScript And XML

¿Que tiene que ver ActiveX, Applets de Java o VBScript en esto?

Lo único que tiene que ver es XMLHttpRequest y se creó en el 2000 para Outlook Web Access.

D

#88 Cansas mucho.

Dices que "Hasta inicios del 2000 en las webs no se podía cargar contenido parcial sin recargar" y eso es falso.
Después que "¿Que tiene que ver ActiveX, Applets de Java o VBScript en esto?" y tiene que ver mucho.

A finales de los 90 ya se utilizaba en muchísimas webs tecnologías como los objetos ActiveX, applets JAVA, VBScript y JavaScript, e incluso objetos Flash para la carga dinámica de información sin recargar de nuevo la página completa.

Siguiente cosa. Paso de escribir, te pego los párrafo y lees:

The second version of the MSXML library was shipped with Internet Explorer 5.0 in March 1999, allowing access, via ActiveX, to the IXMLHTTPRequest interface using the XMLHTTP wrapper of the MSXML library.

With the release of Internet Explorer 5.0, Microsoft released the first version of XMLHttpRequest (XHR), giving birth to Ajax (even though the term "Ajax" was not coined until years later.) XMLHttpRequest is an API that can be used by JavaScript, and other Web browser scripting languages to transfer XML and other text data between a page's client side and server side,[17] and was available since the introduction of Internet Explorer 5.0[18] and is accessible via JScript, VBScript and other scripting languages supported by IE browsers

P

#89 La que cansa eres tu que quieres hacer lo blanco negro.

Dices que AJAX es de los 90 y no es cierto. Que un objeto ActiveX te permitiera a partir de marzo de 1999 ,hacer lo que haría AJAX en el futuro, no significa que AJAX fuese de los 90. Tampoco era un estándar y ni muchísimo menos se adopto ActiveX como solución para cargar contenido parcial.

squanchy

#15 Estoy de acuerdo contigo, pero es que hay cosas que claman al cielo. Que tenga que importar la librería 'moment.js' porque en 2018 javascript todavía es una mierda con el tratamiento de fechas, tiene guasa, por poner un ejemplo.

D

#15 no estoy de acuerdo con lo último. El js permite aliviar la carga del servidor y utilizar una serie de cosas que hacen más cómoda la navegación como las peticiones asíncronas.

En lo que sí estoy de acuerdo es que la optimización se ha dejado de lado en muchos casos. La última actualización de gmail creo que es uno de los casos más sangrantes (al menos por la masividad del problema).

pawer13

#15 decenas de miles de programadores que usan Angular, React, Vue... no están de acuerdo contigo. Esa era la teoría hace 10 años, hoy día nadie espera que no uses JS.

marioquartz

#15 Intenta menear una noticia sin javascript. Intenta votar un comentario sin javascript.
Hay cosas que si estan si bien si hechas con javascript.

tdgwho

#17 estando de acuerdo contigo, y siendo de los que a la hora de programar trata de ocupar la menor cantidad de recursos posibles...

Cualquier movil con 2gb de ram sirve para navegar o jugar, tampoco es que tengas que comprar un movil cada año, uno de hace 3 años te vale lol

a

#37 2g es un derroche, uno de 512k y tropecientos años debería servir tambien y de sobrs, 512m es muuucha memoria, hablamos de 512 millones de bytes, es increible el derroche de recursos que se acepta hoy en dia, y esto ya sin hablar de los montones de cores que por alguna razon parecen hacer falta ahora.

h

#51 Pues en esto estoy en contra. Que sí, que es memoria. Pero los assets cada vez son de mayor calidad y para dar una mejor experiencia hay que cachear lo máximo posible (o te jodes porque la velocidad de acceso a disco físico sigue siendo una mierda). Cuanto más, mejor.

D

#51 el sistema operativo copa un buen resto, tu navegador y encima las aplicaciones que usas en paralelo. A que ya no parece tanto.

m

#17: A veces conviene recordar que un 486 a 66 mHz podía navegar por Inernet, leer foros con fotos, dibujitos, colorines... que alguno se piensa que Internet hace 15-20 años era en blanco y negro.

Parece mentira que con procesadores muchísimo más potentes sigamos haciendo... casi lo mismo y pensando que nuestro ordenador podría estar anticuado.

A

#87 Muy cierto, pero cada vez se van añadiendo más y más capas para facilitar que cualquiera pueda hacer sus chapuzas en la web sin aprender a programar. Y eso consume. Además, los textos predictivos y la recolección de datos en redes sociales también consume una barbaridad. Y siendo paranoica, no me extrañaría que los programas minen bitcoins con nustro idle y no tan idle.

pawer13

#87... usando mosaic o similares, que no admitían css, el Javascript apenas se usaba (porque era lentísimo y no existía Ajax) y el propio Html estaba aún muy limitado

m

#98: Interent Explorer 5 Ó 5.5, creo recordar. Eso si, de cabro RAM iban sobrados, como poco tenían 16 mb.

rcgarcia

#10 en As.com por ejemplo

p

#10 Más publicidad y visitas para el medio.

D

#7 Consumo de memoria en 2018? Navegas con un zapato?

D

#18 Tu dejales, si como ya se comento en otra noticia hace poco por aquí lo de derrochar recursos tiene los días contados. La ley de Moore es imposible de cumplir ya, tarde o temprano les tocará hacer programación de alto rendimiento.

Y bueno, en mis tiempos cuando se estudiaba diseño y programación web una de las cosas a tener en cuenta eran los recursos de los que podía disponer la gente con menor poder adquisitivo, para que la web llegase al mayor número de posibles clientes. Hoy en día por lo visto lo que prima es tener en portada un slider de imagenes a full screen y tener que scrollear para poder ver algo de contenido. Y si tienes una mierda de aparato o conexión te jodes. Yo no quiero vender lo maximo posible si no poder decir "que megachula es mi web".

Creo que los unicos que se salvan son los grandes clientes que si suelen pedirte que la web sea compatible con versiones antiguas de navegador y cosas asi, y se fijan mucho en el tema de la usabilidad.

salsamalaga

#11 Deberías ver la de equipos antiquísimos que aún hay en muchos sitios.

Conde_Lito

#11 Con un zapatófono, el iShoe

Si Maxwell Smart hubiera tenido un smart shoe en su época... roll

p

#7 Pensaba que seguía siendo en único que usaba Gmail en versión HTML en 2018, pero no lo decía muy alto porque te dan collejas.

salsamalaga

#67 Hay ordenadores tan tiesos de ram, que sólo cargan gmail en HTML. Y ya te acostumbras y usas siempre la versión HTML.

p

#68 ¿Sólo cargan en versión HTML por defecto? Eso no lo he visto, pero me interesa, porque cada vez que entro me toca hacer click en el enlace inferior antes que termine de cargar. Al final me he pasado a Thunderbird definitivamente para ahorrarme las interfaces ajax de todo gmail y hotmail.

salsamalaga

#70 Al entrar por vez primera en HTML, arriba te da la opción de cargar HTML siempre por defecto.

pawer13

#67 yo uso la versión normal, pero desde la última versión va increíblemente lento incluso en un PC moderno. Estoy tentado de hacer lo mismo

m

#7 En la Edad Media hubieras sido muy feliz, te equivocaste de época

salsamalaga

#75 Si algo funciona, no lo toques.

Jakeukalane

#3 para archivarlas es mucho peor. Las webs que se hacen así cuando desaparezcan no van a poder ser recuperadas.

Observer

#3 en la de scroll infinito, intenta llegar a la información que está en la página 20 desplazando por ella. Ahora hazlo en una paginada y piensa cual es más cómoda.

Octabvious

La web en 2018: https://i.imgur.com/EoNd3ev.gifv

Visto en reddit.

paucazorla

#44 Eso, en las que no tienen publicidad!

D

#44 Pues precisamente el último rediseño de Reddit a mí me parece infumable, con lo bien que iba antes...

D

Pero la de páginas vistas que te da esa mierda...

No debe ser una decisión fácil el renunciar a ello. Solo que Google un dia diga que hasta aquí.

borteixo

#8 creo que era google images hace un mix, te hace scroll ampliable un par de pàginas pero después paginado.

p

#8 Tú mismo puedes forzar las estadísticas desde javascript. Hace ya bastantes años hice un sistema de galerias para un medio digital en me pidieron que en cada foto contara como otra página vista. Fue un bombazo, todos los redactores se dedicaron a hacer fotogalerías porque de cara a los jefes, las estadísticas de tus artículos se multiplicaban por 10 y era un autoengaño. Después empecé a ver que muchas páginas se dedicaban a hacer noticias, galerías de fotos y vídeos divididas en muchas partes, así tenían más impresiones de publicidad y de visitas.

D

#69 eso no es hacer trampas al solitario?

p

#90 No solo se trata de meter una ciudad inventada de un listado o de poner un nombre que supera el límite, puede ser un agujero de seguridad a explotar, como subir un ejecutable en lugar de una imagen jpg o subir un javascript en un campo que luego ejecuta cuanto pinte el html, a inyectar SQL, o meter algún valor que vuelva loco al servidor y freirtelo.... hay millones de personas por todo el mundo dispuestas a buscar la manera de encontrar un exploit, que no tiene porque pasar y más hoy en día que ya se suele utilizar algún framework que suele contemplar esas cosas, pero cuando se trata de seguridad que puede comprometer tu empresa y a tus usuarios cualquier medida me parece poca, cada dos por tres tenemos que a alguna web que la han crackeado. Yo al menos no he currado en ninguna empresa que no se verifique por lado del servidor, por eso me interesa conocer esa técnica del hash.

p

#110 Si iba dirigido a tí, tal vez interpreté mal tu comentario #90

r

Pensé que la moda estaba pasando...

Yo cuando veo una web de esas, me salgo al momento... me parece una estupidez eso del scroll infinito, lo mismo con duckduckgo (encima la mierda de cambios de google, tiene su versión sin paginar...)
Si quieres ver algo, tienes que ir hasta el final para que cargue más, y encima muchas páginas no puedes siquiera darle a la tecla "fin"...

Jokessoℝ

Los programadores web no son programadores.Son maquetistas.

MKitus

Ni así lo van a pillar.

m

Lo odio, veo que no soy el único.

D

#12 Vistoenlasredes. La gracia que te puede hacer lo que lees contrasta con la mala leche que se te pone del scroll infinito

D

Yo también era más feliz en los 90. Hasta que llegaba un Flash.

p

La mayoría de webs con scroll infinito han sido diseñados por gente que curra con Macs, donde les mola mucho hacer scroll, por eso sus ventanas no se maximizan nunca, es mejor tener un pantallón de 21" y aprovechar solo 1/6 parte para así tener scroll con el que disfrutar ese suave tacto del touchpad.

D

molaría que la propia web tuviese scroll infinito

D

Menuda panda de brontosaurios. Si quereis podemos volver a 56k para entrar a la web de Terra.
Nose si os habeis dado cuenta que en cuestion de diseño y programacion web, los que mandan son las grandes empresas.
Decir que una web esta mal hecha porque no funciona sin javascript, es una tonteria como una casa.

S

Podian ponerlo en meneame junto con el cambio de naranja...

musiquiatra

#21 no sabes lo que me sigue jodiendo hasta el infinito la barra naranja fija arriba.

squanchy

#25 Tampoco sería muy complicado que en perfil de usuario pudiésemos elegir un theme, o al menos unos cuantos colores (botones, barra superior, etc.). De hecho, deja hacerlo cuando creas un sub.

daphoene

#64 #21, también podéis usar greasemonkey o tampermonkey para 'reprogramar' tu menéame como hago yo, que no veo ese horrendo naranja. Eso sí, con js activado, claro.

Por cierto, #64, valida todo en el servidor, lo que se haga en cliente es sólo para ayudar al usuario, los procesos del servidor tienen que ser independientes de lo que hagas en cliente, y validar siempre correctamente los datos.

D

Y las listas en galerias? Cuando hablaremos de esa lacra?. Quien la tiene más grande?. Y cada posiblidad en una imagen que te lleva a otra página. Y luego dale para atrás para volver al principio...

Que gran verdad. No debería ser necesarionelnjavascript para leer el contenido, ni para que esté maquetado como es debido.

D

que aprendan de las webs de telecinco y cuatro que no se pueden scrolear.

D

Dejad las web infinitas de scrollearse finitamente!!!

vet

El otro día entré en la única página sobre el pueblo de mi abuelo buscando información sobre mi familia. El creador de la página no había puesto etiquetas ni categorías a nada y después de media hora no había pasado de septiembre de este año en las entradas.

squanchy

#58 No es que se haga larga o no, si no que hay páginas donde van añadiendo contenido y todo está en esa misma página. #49 te da un ejemplo de eso. A mí me ha pasado con galerías de imágenes, que he visto alguna que me ha gustado, dos semanas después he vuelto a entrar para ver esa foto, y me he hinchado de hacer scroll para abajo y para arriba, y al final dejarlo por imposible. Habían metido más fotos diariamente, y aquello era intratable. Es como un chat de whatsapp donde todos los días escriben 100 mensajes, que si buscas algo de hace 2 semanas, te vuelves loco (y eso que whatsapp pone la fecha de cada día).

vet

#65 whatsapp te deja al menos buscar

a

¿Se entiende por scroll infinito una página con más de 290 lineas?

wc pagina_de_meneame.txt
290 2502 13930

Creo sinceramente que todo depende de como se haga. Una página interesante y bien estructurada no se hace larga.

D

Pues a mi me gusta mucho, yo dejaría elegir como verla, en la mayoría de los casos prefiero el scroll infinito, sobretodo si estoy leyendo cosas rápido, como revisando el timeline de Twitter.

D

Nuncaaaaaaaaa

1 2