¿El botón de actualización en los navegadores alguna vez quedará obsoleto, y si es así, cuándo?

Answer 1

El botón de actualización o Comando / Control + R hace que el navegador verifique la frescura de sus activos en caché, que es una habilidad importante que un usuario necesita.

1. Abra una nueva ventana de incógnito de Chrome y el Inspector
2. Visite https://github.com [1] y observe los encabezados en los principales archivos CSS y JavaScript, cada uno tiene “Cache-Control: public, max-age = 31536000”. Su navegador almacena en caché esos archivos durante 1 año sin enviar otra solicitud. Esta es una práctica buena y común para todos los sitios web.
3. Visite https://github.com nuevamente enfocando la barra de direcciones y presionando “Enter”. Las solicitudes de esos activos muestran “Estado: 200 (de caché)”. Chrome no envió una solicitud para obtener esos activos. Usó los de la visita anterior y continuará durante todo un año. Puede enfocar la barra de direcciones y presionar “Enter” tantas veces como lo desee, y los activos vendrán del caché hasta 1 año después de la primera descarga.
4. Haga clic en el botón Actualizar o presione Comando / Control + R y observe esos mismos activos. Chrome envió una solicitud y obtuvo un “304: No modificado”. El botón Actualizar ignora la configuración de caché para sus activos y verifica con la fuente que tiene los activos más recientes.

La capacidad que obtiene un usuario en el paso 4., probablemente sin que la mayoría de los usuarios se dé cuenta, le permite recuperarse de errores en versiones malas de archivos en caché.

1. http://awesomestsiteever.com carga /application.js con un error de sintaxis
2. Un usuario visita el sitio mientras el error JS está activo y se le sirve el archivo con “Cache-Control: max-age = 31536000”. El navegador de ese usuario no buscará una nueva versión de ese archivo durante 1 año.
3. Un desarrollador carga la corrección al mismo nombre de archivo, /application.js
4. Ese usuario nota un problema con el sitio y frustrantemente aprieta el botón de actualización, y listo: obtienen el archivo actualizado a pesar de que el desarrollador le dice al navegador del usuario que no solicite ese archivo durante todo un año.

En esa situación, el usuario estaría hundido sin el botón de actualización. Tendrían una versión defectuosa y potencialmente inutilizable del sitio durante todo un año.

Rails previene esta situación al garantizar que cada versión de un archivo tenga un nombre único mediante el uso de huellas digitales [2], pero no todos los desarrolladores web lo hacen. En el caso de un problema en el sitio, el usuario debería poder obtener por la fuerza la versión más reciente del sitio. Tal vez no exista como un botón real en el futuro, pero presionar Comando / Control + R varias veces en rápida sucesión, apretar la cara en el teclado, o como quiera llamarlo, es una característica que debe permanecer. .

[1] Usé Github como ejemplo porque sus activos están bien nombrados como github.js y frameworks.js. No hay otra razón realmente.
[2] http://guides.rubyonrails.org/as…

Answer 2

Greg tiene una gran respuesta, aunque creo que la respuesta es un poco más gris.

Aquí hay una pequeña expansión:

• El software tiene muchos más errores de los que crees. Los usuarios tienden a culparse a sí mismos (“Rompí mi correo electrónico”) cuando, de hecho, realmente tropezaron con un error. Los errores son solo parte de la vida; Los sitios web de primer nivel regularmente reinician sus servidores web para combatir las pérdidas de memoria. El plan nunca es no tener errores, sino solo poder tratarlos rápidamente.
• Los reinicios son realmente geniales para manejar errores. Los usuarios a menudo lo consideran una solución “estúpida” (“No sabía cómo solucionarlo, así que lo apagué y lo volví a encender”), pero de hecho es la forma más inteligente de hacerlo la mayor parte del tiempo . La belleza es que no tienes que saber qué está mal para arreglar algo. Los errores son esencialmente, por definición, inesperados, por lo que cualquier solución personalizada puede perder un caso. (Los reinicios no ayudarán a errores deterministas fácilmente reproducibles, pero es de esperar que sean fáciles de detectar y, por lo tanto, se solucionen rápidamente).
• Los programadores solo arreglan las cosas si es necesario. Esto no es pereza acerca de la optimización de recursos; está optimizando el meta recurso del tiempo del programador. Una de las mejores cosas de las aplicaciones web es que los errores no son tan importantes. Insertar un nuevo código en un servidor es trivial en comparación con lanzar un nuevo binario, por lo que si realmente lo arruinas puedes recuperarte. La pila del navegador / SO lo protege de hacer algo súper perjudicial en el cliente; Esto es aún más cierto con la separación de procesos estilo Chrome. Básicamente, el costo de un error en una aplicación web es bajo en comparación con un error en OS X. Con el costo de tales errores bajo, el incentivo para solucionarlos también es bajo, por lo que puede esperar aplicaciones web en tiempo real con errores en El futuro a medio plazo. Nuevamente, eso no es algo malo, significa que los programadores están ocupados haciendo otras cosas de mayor influencia, como desarrollar funciones. Por supuesto, hay una compensación aquí: cualquier producto utilizable tiene que funcionar la mayor parte del tiempo, pero trabajar todo el tiempo no vale la pena.
• ¿Qué podría cambiar esto? Capas de abstracción que de una vez por todas resuelven (algunos) problemas básicos de aplicaciones web. La resolución de cualquier error determinado de aplicación web no determinista es un apalancamiento bastante bajo, pero la resolución de TODOS estos errores es un apalancamiento extremadamente alto. Así como ya no tenemos que reiniciar nuestras máquinas físicas, y estamos reiniciando nuestros navegadores cada vez menos, sí, también tendremos que actualizar nuestras páginas web cada vez menos. Pero eso solo sucederá una vez que tengamos una nueva noción, incluso más liviana, de “reinicio” que nos da un marco que se encuentra en la parte superior del navegador.

Divulgación completa: Tengo el presentimiento de que el marco podría ser Luna.
Divulgación más completa: Honestamente, no me di cuenta de que esto era una pieza de evangelismo hasta que comencé a escribir la última viñeta.