Mark Zuckerberg habla sobre el pasado, presente y futuro de Facebook: "Apostar por HTML5 fue nuestro gran error"

Si yo fuera el tío ese, por respeto al consorcio y por educación, habría dicho que fue un error no haber desarrollado desde el principio una aplicación 100% nativa para cada dispositivo. 

O simplemente reconocer que la empresa no supo lidiar con las limitaciones del uso de la tecnología (HTML) y el entorno en la que la aplicaron (dentro de una App).

Eso fue lo que hizo pero con unas palabras mucho más abiertas y que admiten confusión. Pero tampoco va a admitir que la ha cagado bien. Es Mark, un jodido orgulloso.

De poder pueden que no deberían es otra historia, pero al igual que todo el mundo siempre odiamos lo que no sabemos usar o lo que nos cuesta usar, como mucha gente odia las matemáticas por ejemplo.

No, no eres el único. Yo tampoco le veo la gracia a los juegos de fb >_

Yo he jugado una vez, y era muy curioso, porque te pedían dinero para seguir jugando.

Yo también prefiero pasármelo en grande con la consola (no entro en debate de qué es mejor, si consola o PC), antes que desperdiciar el tiempo con jueguecitos que enganchan, pero sin técnicamente muy inferiores.

¿Renderizar en el servidor? ¿A qué te refieres?

Se refiere a generar el contenido en HTML5 de forma dinámica en PHP lo que supone un claro error de arquitectura, los datos a descargar son mayores, es un pequeño coladero y muchas mas cagadas que ya hemos visto, la gente de la w3c sabe que no hay grandes front-developers en facebook, podrian haberse ahorrado disgustos usando un REST y punto.

No les encuentro el sentido al primer comentario ni al tuyo, lo siento.

El contenido que muestra la aplicación se obtendrá (y generará) necesariamente de forma dinámica porque es de naturaleza dinámica (dando por sentado que lo cachearán/pregenerarán a varios niveles), así que no veo el error de arquitectura que comentas. Cliente servidor tradicional.

Lo que me ha sorprendido es lo de "renderizar los elementos en el servidor" del OP. Renderizar qué, ¿el formato intermedio de transferencia? ¿Qué más da (salvo por la verbosidad) que la info se transmita en XML/HTML o en JSON? De hecho si la transmites en HTML la puedes inyectar directamente en la aplicación y te ahorras un paso en el cliente.

Si lo he entendido bien, el único error que han cometido al apostar por HTML5 ha sido que el rendimiento no se puede comparar con el de las aplicaciones nativas.

Releyendo vuestros comentarios, ¿os referís a que descargaba cada vez no solo los datos a mostrar sino también los elementos de la interfaz? (botones, estilos, etc.)

Te hablo desde la experiencia y en mi humilde opinión generar contenido HTML en servidor y luego inyectarlo en el DOM de entrada es un pequeño coladero y no suele funcionar demasiado bien.

Cuando hablamos de miles de conexiones concurrentes cada byte cuenta y mas con conexiones 3G de por medio, una de las cuestiones mas criticadas era la lentitud de actualización no el rendimiento en si (aunque tambien y dependiendiendo de cada caso), que el cliente genere el DOM con JSON no supone demasiada carga para el terminal y distribuye la carga de procesamiento del servidor al cliente, comprimiendo muuuucho los datos a descargar (especialmente si lo comparas con HTML vs JSON).

Ahora, hay una realidad, el rendimiento de Javascript y CSS3 no es la panacea en terminales anteriores a 2011-12, si hubiesen empezado hoy la aplicacion probablemente les hubiese ido mejor, ademas que duda cabe de que nativo siempre sera mas rapido que HTML5 por que hay un interprete de por medio (aunque poco a poco la diferencia se acorta).

Hay esfuerzos en ese sentido (acercar el rendimiento HTML5 al nativo) como el de Ludei, de momento solo para juegos. No estoy muy de acuerdo con el peligro adicional que le ves a inyectar HTML frente a parsear JSON (el escape y filtrado lo habrá hecho el servidor igual para uno que para otro, salvo que filtres de nuevo la info cuando evalues el JSON), y tampoco sé yo hasta que punto reduces los datos a transferir cuando el contenido se servirá normalmente gzippeado (eso sí, personalmente odio XML y prefiero JSON).

Me gustan este tipo de debates con gente que también sabe del tema :)

Buen apunte, Ludei ha avanzado un montón con CocoonJS, pero sobre todo en canvas, han conseguido acelerar mediante OpenGL ES funciones de dibujado tirando directamente de la aceleracion por hardware, estuve en DevUp de este año y las demos mostraban juegos en canvas a la misma velocidad que nativo (teneis Disaster Lab de ejemplo).

Sobre lo que comentas te pongo un ejemplo (no escapado), en HTML: <article><h1>titulo</h1><p><descripcion></p></article>

Y en JSON: {articulo:{tit:'titulo',desc:'descripcion'}}

Multiplica esto por cientos de registros, la compresion se aplica a texto igualmente.

Sobre el tema de servidor, teniendo en cuenta que facebook usa una NoSQL como Cassandra cuyo output es directamente JSON, al renderizar HTML en servidor estas perdiendo un porcentaje de rendimiento que puede ser importante si te entran miles de peticiones concurrentes, por ejemplo, es mas rápido parsear un objeto con json_encode (en PHP) que servirlo con un motor de plantillas o un bucle de dibujo de HTML.

Me puedo equivocar, pero hemos hecho benchmarks para respaldar esto ya que en produccion la puedes cagar, que conste que no es que sea la solucion para todo pero creo que para este tipo de aplicaciones con alta concurrencia y conexiones virtualmente lentas es un error servir directamente HTML.

Un placer si sirve de algo mi experiencia ;)

Muy interesante que Cassandra escupa JSON, no tenía ni idea. En ese caso pasar a HTML en el servidor en lugar de en el cliente es claramente un overhead evitable.

En cuanto a las ventajas de JSON no hace falta que las enumeremos, yo ofrezco mi API en JSON exclusivamente ;)

Yo también estuve en el DevUP, de hecho Eneko me mencionó en la apertura porque es inversor en mi startup :)

Un placer también divagar sobre desarrollo web contigo, nos vemos seguro en el futuro que este sector es muy pequeño

Mucha suerte con Workcomunity Joel, me han contado cosas muy buenas y enhorabuena, si Eneko esta detrás es por que tenéis un diamante en bruto y los que andais detras sabeis lo que haceis.

Ya decía yo que me sonaba tu cara jejeje.

Un abrazo ;)