mejora progresiva de JavaScript?

Question

La mayoría de la gente habla de la mejora progresiva en este momento de servir los navegadores con javascript (versión mejorada) y navegadores sin javascript (versión simple).

Pero hay una gran diferencia en el rendimiento entre los navegadores JavaScript que puede ser útil aplicar ese término a apoyar para elegir entre Javascript características basadas entre los navegadores.

En una aplicación web compleja con numerosas características no absolutamente esenciales (y animaciones), es que vale la pena empezar a pensar en una barra de separación para la opinión, estos conjuntos de características deben trabajar en todos los navegadores, y estos conjuntos de características sólo en Chrome y Safari, y éstas en Firefox y Chrome y Safari y Opera, y así sucesivamente, ya que permite a ciertas características en algunos navegadores sería demasiado lento.

A veces siento que la experiencia del usuario mejoraría si no tienen acceso a ciertas funciones no esenciales. Por ejemplo no permitir a los usuarios de IE de cambiar el tamaño de ciertos paneles que los usuarios de Chrome serían capaces de cambiar el tamaño.

Answer 1

Eso suena como una pesadilla de mantenimiento.

Me doy cuenta de que hay algunas aplicaciones web en la que simplemente no tiene sentido tener una versión HTML. Dicho esto, si es posible, me gustaría empezar por la construcción de una versión HTML de cada página en primer lugar, a continuación, utilizar JavaScript para mejorar la experiencia del usuario.

IE es menos eficiente que Safari, Chrome y FF cuando se trata de JS - pero ¿realmente desarrollado una página que no se puede utilizar en el IE con JS encendido? Yo no lo he visto -. En la naturaleza Creo que las diversas implementaciones JS son lo suficientemente rápido

Answer 2

No he hecho esto por mí mismo, pero puedo ver que tiene mucho sentido si su presupuesto lo permite (y que no puede controlar la elección del navegador del usuario)

Al final del día, los usuarios de IE pueden estar utilizando un navegador lento, pero siguen siendo sus usuarios. Así que si usted quiere dar a todos sus usuarios la mejor experiencia posible al usuario, que puede valer la pena gastar algún tiempo dando a los usuarios de IE una versión diferente de la aplicación para darles un mayor nivel de rendimiento.

Una aplicación que es rápido para el 99% de sus usuarios es indudablemente mejor que una aplicación que es rápido de sólo el 30% de sus usuarios. La única pregunta es ¿qué es más importante - la experiencia del usuario, o el tiempo de desarrollo (y tener en cuenta que dentro de unos años, el usuario promedio va a correr los navegadores más rápidos en equipos más rápidos)

Cualquier tipo de trabajo debe ser impulsada por los puntos de referencia, sin embargo, ya que mi experiencia es que a menudo se sorprenderá por lo que parte del código es lenta y qué parte del código es rápido.

Como acotación al margen, Lombardi Blueprint tiene un enfoque muy interesante, aunque probablemente poco práctico fuera de GWT. Tienen diseño de algoritmos escritos en Java, escrita de tal manera que se pueden ejecutar tanto en el lado del cliente (a través de GWT) y el lado del servidor (a través de una JVM estándar). En consecuencia, con base en el desempeño Benchmarked de su navegador, que son capaces de cambiar dinámicamente entre hacer el diseño en el lado del cliente (para los navegadores rápidos) vs hace la disposición en el lado del servidor (para los navegadores más lentos).

Answer 3

Hay dos cuestiones diferentes con los navegadores en estos días:

1. Velocidad. Mi experiencia ha sido que IE 7 funciona bien, sólo mucho más lento que el resto. Mi solución es dar actualizaciones de progreso interfaz de usuario más frecuentes a los usuarios. Desde la actualización de interfaz de usuario lleva su tiempo, puedo minimizar los cambios en los navegadores más rápidos. Por ejemplo, en IE que actualizar la pantalla con más retroalimentación después de procesar otros 50 eventos. Para otros navegadores, después de procesar 200 eventos.

2. La falta de función. lienzo por ejemplo. Pero es gran gasto para construir múltiples sitios. Y prueba de ellos también. Así que me paso el presupuesto el 1 de versión para todos los navegadores de escritorio actuales. Y hacer que los sitios adicionales para móviles iPhone esp.

HTH,

Larry

Answer 4

Lo que hago es escribir un archivo javascript básica que tiene la funcionalidad común, yendo al denominador más bajo (Javascript 1.5). entonces tengo otros archivos para las versiones más recientes de Javascript, y aquellos a reemplazar las funciones en mis objetos JavaScript, por lo que puedo añadir progresivamente más apoyo.

Si quiero usar la etiqueta canvas, entonces puedo añadir que en un archivo diferente, ya que el IE y Firefox / Opera / Safari difieren en la forma de crear el elemento canvas.

Esto no es una alegría en el mantenimiento, pero si quiero usar el nuevo html / javascript cuenta entonces esto parecía ser el mejor modelo.

Answer 5

Estoy de acuerdo con Andy. Proporcionar versión diferente de una aplicación a diferentes navegadores es un problema de mantenimiento potencial en el futuro. Siempre he encontrado que es una mejor apuesta para proporcionar una versión de una aplicación, que funciona en todos los navegadores. Por ejemplo, trato de evitar los sniffers navegador. La aplicación podría no ser el más fresco uno, pero funciona para todo el mundo y es más fácil de mantener.

Este tipo de cosas es más fácil ahora con todas las librerías Javascript ingeniosas que resumen algunas de las diferencias de distancia del navegador. Además, se puede hacer un montón de cosas en los navegadores antiguos. Se acaba de hacer "diferente";)

Answer 6

Así que digamos que usted construye una aplicación decente de tamaño. Tiene abundancia navegador detectores para determinar qué características estará encendido y que estará fuera. Usted olió para Opera 9.x, y ahora (hoy en realidad) Opera 10 que sale. Tienes que ir y actualizar cada sniffer en cada página. Y luego otro navegador salga pronto ... y otro. Lo que vas a pasar todo el tiempo, la determinación de lo que los navegadores apoyo y qué características para apoyar en ellos.

Yo uso varios navegadores en un día. Así que cuando voy a su sitio, voy a ver tres interfaces diferentes. Voy a estar confundido, ya que las características que espera que sea allí, o los comportamientos que esperaba no estaré allí. Con el tiempo, voy a frustro y nunca ir a su sitio de nuevo.

Además, hay más a la rapidez con alguna pieza de JavaScript se ejecuta de sólo el navegador. Todavía tengo un viejo Pentium con Firefox 3.5. A veces, puede ser muy lento.

Answer 7

Creo que la respuesta es que se necesita para categorizar su código en categorías de velocidad, no sólo en categorizar capacidades del navegador.

En otras palabras, dar a sus niveles del sitio de características, primer nivel es el HTML básico, segundo nivel es javascript mejoras de usabilidad, tercer nivel es javascript ojos dulces animación.

A continuación, hacer una combinación de permitir a sus usuarios a abandonar un nivel cada vez que quieran, "Haga clic para desactivar las animaciones!", "Haga clic para activar las animaciones!", "Haga clic para ver en HTML básico", y la elección por defecto a ciertas categorías de velocidad basado en navegador por razones de velocidad (por ejemplo, si IE7 parece evidenciar los problemas de velocidad con las animaciones de lleno, que sea por defecto a la segunda división "javascript usabilidad mejoras").