El podcast de JS Party acaba de tener un episodio divertido en el que debatieron esta pregunta clásica dividiéndose en dos grupos de dos. A cada grupo se le asignó un “lado” de este debate y luego se le permitió debatirlo. ¡No creo que nadie pueda escuchar un programa como este sin estar totalmente inundado de pensamientos! Aquí están los míos.
- Este es uno de esos argumentos de la guerra santa que se ha prolongado durante años. Quizás sea porque la gente busca una respuesta que se aplica a toda la weby la web es demasiado grande para fijar esta amplia respuesta a.
- La pregunta en sí misma merece una mirada. ¿Por qué estamos hablando de paralizar nuestros sitios de esta manera particular? ¿Deberían nuestros sitios web funcionar sin HTML? ¿Deben funcionar nuestros sitios web sin bases de datos? Quizás nos centramos más en JavaScript porque JavaScript se ha convertido en el cuello de botella más grande del rendimiento web (¡incluso más que la red!) Y nosotros experiencia JavaScript falló más que cualquier otro tipo de falla web (excepto, quizás, sitios completos que no se cargan) (o fuentes de iconos, cielos).
- Disfruté de todos los tropiezos con la terminología de “aplicaciones web” y “sitios web” (¡cosas web!). Este es tan extraño. Es tan fácil imaginarse la diferencia en tu cabeza: ¡es como Facebook versus un blog! Pero cuando empiezas a tratar de definirlo con exactitud, se vuelve realmente turbio muy rápido y la distinción pierde cualquier valor, si es que tenía alguno para empezar. Aquí hay más sobre eso.
- La accesibilidad ciertamente está involucrada en todas las conversaciones sobre la web, pero probablemente no se pueda aplicar ampliamente aquí. Existe la idea de que la tecnología de asistencia no ejecuta JavaScript, por lo que un sitio que requiere JavaScript para usarlo es un error del 100% para esos usuarios. Lo mejor que sé es que ese ya no es el caso. Podemos debatir a muerte el papel de JavaScript en los problemas de accesibilidad, pero el hecho de que un sitio en particular requiera JavaScript para ejecutarse no hace que el sitio sea inaccesible.
- Es bastante fácil desactivar JavaScript, navegar por la web, encontrar cosas rotas y hacer un chinflip para detectar este aparente error. La falla es que este sitio, o una característica en el sitio, podría haber sido diseñado para funcionar sin JavaScript. Regla de menor poder. Esto es complicado. Es fácil no preocuparse por una persona que ha deshabilitado intencionalmente una parte de su navegador web y aún quiere que todo funcione. De verdad, no me importa eso. Pero el resistencia parte es más interesante. Si crea una parte de un sitio para que funcione sin JavaScript, funcionará tanto antes como después de que se ejecute JavaScript, lo cual es bastante bueno.
- El concepto de crear contenido funcional y características sin JavaScript y mejorar la experiencia con JavaScript se llama mejora progresiva. Soy tanto fanático como cuidadoso de no insistir en que todo en la tierra siempre debe construirse de esa manera (ver el punto superior). Hay situaciones en las que la mejora progresiva aumenta y reduce la deuda técnica. El único pincel amplio que usaría aquí es decir que vale la pena hacerlo hasta que la deuda sea demasiado alta.
- Hay un momento intermedio con realce progresivo. Si una característica es funcional sin JavaScript, eso significa que es probable que esté postergando la carga de ese JavaScript por el beneficio de rendimiento. Pero eventualmente necesita ser descargado y ejecutado. ¿Qué pasa durante ese tiempo? Hay un costo de rendimiento y UX allí. En el mejor de los casos, es insignificante. En el peor de los casos, rompe la función durante este tiempo intermedio.
- Me parece más interesante debatir este tipo de cosas sitio por sitio y función por función. Los holotipos de aplicación pueden ser una forma interesante de determinar su alcance. A menudo recurrieron a Slack como ejemplo, que es una elección perfecta. ¿Cómo construirías un sitio de reseñas de películas de 20 autores? ¿Cómo diseñaría un sitio con muchas redes sociales y medios como Dribbble? ¿Cómo se construye la navegación desplegable? ¿Qué tal un sitio de folletos de una página donde el cliente quiere paralaje? ¿Qué tal una aplicación de aerolínea que también necesita una aplicación móvil nativa? Y, por supuesto, te hace pensar en los sitios en los que trabajas. ¿CodePen se ejecuta en el conjunto correcto de tecnologías? ¿CSS-Tricks?
- Si un sitio es “renderizado del lado del cliente” (CSR), eso significa que JavaScript está haciendo la búsqueda de datos y creando el DOM y todo eso. Si hablamos de sitios web que “funcionan” o no con o sin JavaScript, un sitio que se procesa en el lado del cliente fallará al 100% sin JavaScript. Es lo opuesto a “renderizado del lado del servidor” (SSR) en el que el documento se descarga como HTML directamente desde el servidor. Es casi seguro que SSR sea más rápido para una experiencia de primera carga. CSR, por lo general, es más rápido para moverse por el sitio después de la carga (piense en “aplicación de una sola página” o SPA).
- No se trata solo de SSR frente a CSR, hay todo un espectro. Es cada vez más común ver que los sitios intentan aprovechar lo mejor de ambos mundos. Por ejemplo, Next / Nuxt / Gatsby o fastboot de Ember.
- Los trabajadores del servicio son JavaScript. Los trabajadores web son JavaScript. Algunas de las características sofisticadas de resistencia y rendimiento de la web están impulsadas por la misma tecnología que causa el dolor sobre el que debatimos.