Twitter sigue siendo una aplicación de una sola página, ahora está construida correctamente (uno de los resultados es que no se puede ver fácilmente).
Cuando Twitter fue por primera vez a una sola página, la única forma de hacerlo mientras se mantenían los hipervínculos en funcionamiento y un botón de retroceso funcional era utilizar un truco vil que involucraba URL de fragmentos, cosas como https://twitter.com/#!simonw/sta…
Esto funciona, pero viene con una bolsa completa de desventajas:
- ¿Cuáles son los marcos utilizados para el desarrollo de sitios web PHP?
- Cómo hacer un sitio web de recomendación dinámica con WordPress
- ¿Cuál es la anatomía de una aplicación web moderna?
- Cómo hacer un portal web
- ¿Qué servidor web utiliza HostGator para el alojamiento compartido?
- Cualquiera que haga clic en un enlace a Twitter tiene que descargar varios megabytes de JavaScript antes de que el sitio pueda averiguar qué información debe mostrar. ¡En el caso de un enlace permanente de tweet que se descargan varios megabytes solo para mostrar un tweet de 140 caracteres!
- Las páginas no funcionan en absoluto sin JavaScript.
- Un solo error de JavaScript en un oscuro navegador de teléfono móvil solo disponible en teléfonos chinos puede evitar que el sitio cargue cualquier contenido.
- Los lectores de pantalla pueden no entender lo que está sucediendo.
- Solo algunos motores de búsqueda pueden indexar las páginas, nuevamente utilizando un truco desagradable.
- Estas no son URL de hipertexto “reales”. Si realiza una operación GET contra ellos, no obtiene el contenido al que se refiere la URL, solo obtiene la página de inicio de Twitter. Esto es malo para la salud de la web.
- Un ejemplo relevante: la característica de Quora donde una URL pegada se convierte automáticamente al título de esa página no puede funcionar si la URL no apunta a HTML real, en lugar de una página de inicio y una gran porción de JavaScript.
- Estos enlaces comienzan a extenderse. Otros sitios tienen que usarlos en enlaces a Twitter, lo que significa que incluso si Twitter se deshace de ellos, necesitarán mantener algo de JavaScript en su página de inicio que sepa cómo manejarlos para siempre .
Estas URL de hashbang son hacks desagradables y desagradables.
Afortunadamente, el hackeo de hashbang ya no es necesario, gracias a una buena parte de HTML5 llamada History API. Esto permite que JavaScript actualice la URL visible en la barra de URL del navegador sin tener que navegar a una página completamente nueva; esencialmente, permite que una aplicación de una sola página pretenda que es un sitio web real.
¿Cómo soluciona esto los problemas anteriores? Significa que Twitter puede comenzar a servir páginas web reales nuevamente. Intenta ejecutar este comando:
curl "https://twitter.com/simonw/status/419261896957505536"
¡Devuelve HTML! De hecho, devuelve el HTML exacto necesario para mostrar una página que muestra el contenido de ese tweet. Luego, en la parte inferior de ese HTML, incluye una sola etiqueta de secuencia de comandos (cargada después de que la página se haya mostrado en el navegador) que carga una gran cantidad de JavaScript y convierte esa hermosa y ligera página HTML en una aplicación web gigante de una sola página .
Ahora, cuando hace clic en un enlace de la página, Twitter puede recuperar el contenido de la nueva página usando JavaScript y mostrárselo sin realizar una recarga completa de toda la interfaz de usuario, pero pueden usar la API de historial HTML5 para actualizar la URL en el página para que, por lo que puedes ver, hayas navegado a otro lugar. Es una aplicación web de página de inicio oculta a simple vista.
Pero, ¿qué pasa con los navegadores que no admiten el historial HTML5, como las versiones anteriores de IE? Aquí está la parte inteligente: no obtienen el nuevo y elegante JavaScript, solo obtienen enlaces que, cuando se hace clic, los navega a una página completamente nueva. Esto significa que incluso los navegadores que no admiten JavaScript pueden acceder y navegar en Twitter, pero los navegadores con JavaScript obtienen una experiencia mucho mejor.
Dan Webb, un ingeniero en Twitter, escribió algunas piezas muy interesantes sobre este tema. En It’s About The Hashbangs (mayo de 2011) explicó por qué creía que la implementación de hashbang de Twitter era el camino equivocado. Un año después, en mayo de 2012, publicó Mejorando el rendimiento en twitter.com en el blog oficial de Twitter explicando la nueva técnica de historia que estaban utilizando y cómo había mejorado drásticamente el rendimiento del sitio.
Para ser justos con Twitter, debo señalar que cuando lanzaron su aplicación hashbang de una sola página en 2010, la API de historial HTML5 no estaba ampliamente disponible: IE no lo admitía en absoluto, y creo recordar que Safari 2.0 tenía un error lo que hizo que su implementación fuera inutilizable. Afortunadamente, este ya no es el caso hoy.
