¿Es una práctica común minimizar el uso de JavaScript al crear un sitio web? [cerrado]

He sido desarrollador web durante casi 10 años y me he acostumbrado a tratar de no usar JavaScript siempre que sea posible. No estoy hablando de crear aplicaciones web aquí, sino de sitios web basados ​​en bases de datos.

¿Es este un enfoque bueno / respetado?

El instinto de la mayoría de los programadores es reducir todo tipo de código. Cuanto menos código, menos complejidades y menos puntos de posible error en dicho código. Esta regla se aplica tanto a Javascript como a otros idiomas. Solo estás manteniendo la tradición.

Use Javascript según sea necesario / deseado dentro de las páginas HTML ... pero no hay razón para usarlo cuando no es realmente necesario.

Hace 10 años, podría haber sido una buena idea. Hoy en día, la mayoría de las partes de Internet (al menos algunas partes muy populares) se han vuelto casi inutilizables, o solo proporcionan una funcionalidad muy restringida, al deshabilitar Javascript en el navegador. Entonces, en mi humilde opinión, hoy puede esperar que sus usuarios tengan habilitado Javascript.

Y hay muchos marcos como JQuery para sortear las incompatibilidades del navegador. En mi humilde opinión, no hay una razón real por la que deba restringirse al no usar Javascript para su sitio web; la única razón puede ser que no tiene ningún uso para ello.

EDITAR: una pregunta diferente es: si debe proporcionar alguna funcionalidad mínima de su sitio web cuando sus visitantes no tienen JS habilitado , esa es principalmente una buena idea, por las razones que algunos de los comentaristas han señalado.

EDIT2: seguramente para cada sitio web, uno tiene que encontrar un equilibrio entre facilidad de uso, facilidad de búsqueda y esfuerzo de desarrollo. En mi humilde opinión, Javascript puede ayudar a mejorar ese equilibrio, si se usa con prudencia. Dicho esto, creo que no hay necesidad de minimizar el uso de Javascript en la actualidad para mantener ese equilibrio. Úselo con cuidado y no lo demonice.

Tener un sitio que se pueda usar sin JavaScript significa que está disponible para la audiencia más amplia posible. Si bien es cierto que la mayoría de los navegadores admiten JavaScript y la mayoría de los usuarios lo dejan activado de forma predeterminada, no puede contar con eso con seguridad. No todo lo que accede a su sitio es un navegador después de todo; Si desea que su sitio sea indexado correctamente por motores de búsqueda como Google, GoogleBot debe poder navegar por su sitio sin JavaScript.

También hay piezas especializadas de software de navegación web donde JavaScript no está disponible o no funciona como se esperaba. Lectura de pantalla o software Braille utilizado por personas con discapacidad visual, por ejemplo. También hay entornos en los que la memoria es limitada y tener grandes cantidades de JavaScript puede hacer que la experiencia de navegación sea desagradable o incluso poco práctica, como los navegadores de teléfonos inteligentes.

Debería analizar el concepto de "mejora progresiva", donde crea un sitio para trabajar sin javascript, luego agrega una capa de javascript en la parte superior para mejorar la experiencia del usuario. De esa manera, tendrá un sitio que al menos sea utilizable para personas sin JavaScript.

No necesita esforzarse por proporcionar todas las funciones posibles que planea implementar con JavaScript en navegadores que no sean JavaScript, pero aún así es importante dejar al menos los casos de uso básicos disponibles sin JavaScript. Ser capaz de navegar por el sitio es obviamente el primero de la lista, pero si está creando un sitio de comercio electrónico, hacer que el proceso de pago dependa de JavaScript sería una tontería, ya que podría costarle ventas.

Las otras respuestas parecen centrarse en "si nunca uso JavaScript", por lo que creo que se están perdiendo el punto. No debe usar JavaScript si no lo necesita. Algunas personas usan JavaScript para todo :

• Efectos de desplazamiento (debe ser CSS)
• AJAX (debe tener hrefcuando sea razonable)
• Posicionamiento (debe ser CSS)

Los beneficios son cosas como:

• El sitio se muestra más rápido
• CSS es significativamente menos complejo que JavaScript la mayor parte del tiempo
• Tener hrefenlaces de respaldo ayuda a los motores de búsqueda, a los usuarios que desean abrir enlaces en otras pestañas y a los usuarios que odian JavaScript

Por supuesto, AJAX es bastante bueno, y también lo son las páginas dinámicas, así que no tires esas cosas solo porque algunas personas no las necesitan.

Mi punto es que aprender a hacer cosas sin JavaScript es bueno, minimizar JavaScript es bueno y tener una copia de seguridad para cuando JavaScript no funciona es bueno, pero no hay razón para evitar funciones porque requieren JavaScript.

Es una buena idea evitar funcionalidades innecesarias, punto. Los marcos como jQuery hacen que sea increíblemente fácil agregar adornos que pueden tener sentido agregar, pero a veces no. Por ejemplo:

¿Realmente necesitas animar eso?

... o ...

¿Es realmente necesario recorrer todo el DOM para un selector tan trivial? ¿Podría limitarlo usando el contexto, y necesitamos eso en primer lugar?

No evitaría usar JS, pero me aseguro de no ser desagradable, mientras busco máquinas más lentas. Lo mismo ocurre con algunas de las cosas nuevas y elegantes que obtenemos en CSS3, como sombras paralelas ... si se usan en exceso, pueden hacer que alguien en una máquina de menor potencia tenga una experiencia realmente mala.

La excepción a esto podría ser escribir controles frontales para varios tipos de dispositivos, donde deben trabajar absolutamente con JS deshabilitado (tal vez una estricta política de seguridad en una red de administración del centro de datos no dicta JS). Por lo tanto, lo anterior debe tomarse en contexto con los requisitos que tenga.

Creo que siendo un desarrollador web relativamente nuevo y joven (aproximadamente 4 años), tuve que investigar mucho sobre esto ya que javascript está en todas partes.

Lo que intento hacer en mis proyectos es asegurarme de que el sitio funcione sin javascript, luego agregar javascript donde tenga sentido (validación del lado del cliente, mejora de la interfaz de usuario, etc.). Es una especie de mejora progresiva y se encarga de SEO, JavaScript deshabilitado e incompatibilidades de navegador anteriores.

Esta misma pregunta se ha hecho en SO, pero no puedo por mi amor recordar dónde.

El uso de JavaScript puede estar limitado en varios casos:

• Validación. Tiene que hacerse en el lado del servidor. A veces, en las aplicaciones web hay una validación rápida del lado del cliente, pero por sí sola no es suficiente.
• Tareas extremadamente importantes. Los usuarios pueden optar por desactivar las secuencias de comandos de sus navegadores, por lo que el código JS no funcionará en absoluto. Si desea estar seguro de que algo funcionará en cualquier caso en cualquier navegador, no confíe en JS.
• Velocidad. El código JS debe enviarse al cliente, y cuanto más código escriba, más tardará. Aunque pequeñas cantidades de código no tendrán efecto práctico.

JS tiene una gran cantidad de características, que no pueden ser reemplazadas por código del lado del servidor. Aparte de los anteriores, no creo que haya ningún argumento razonable para limitar el uso de JS.

" Sitios web basados ​​en bases de datos " es la clave de la respuesta. Hay dos formas de crear sitios web, y la cantidad de Javascript permitido depende de cuál esté usando, realmente. Puedes construir:

1. Sitios web centrados en el contenido . En el primer caso, las palabras mágicas son "mejora progresiva"; limite javascript a funciones redundantes que se pueden suministrar con accesos clásicos al contenido a través de HTTP simple.

2. Aplicaciones web . Para las aplicaciones, estás usando la web como una plataforma de software. Las aplicaciones se basan en algunas suposiciones sobre el software disponible: navegadores modernos, versiones más recientes de bibliotecas javascript populares, accesos de escritorio con mouse y / o tabletas con multitáctil.

La web como plataforma de software

Los requisitos mínimos de acceso están bien si realmente está construyendo una aplicación: se dirige a alguna plataforma específica para obtener funciones avanzadas que de otro modo no se podrían construir. Es como desarrollar para Python o Java o .Net. No deje que palabras de moda como HTML5 y la promesa de "ejecutar en cualquier lugar" lo engañen; puede tener código portátil entre dispositivos solo mientras toda la plataforma sea compatible con ellos. Cualquier cambio en la pila de desarrollo, y el software se romperá.

Por lo tanto, el precio a pagar es que está siguiendo un objetivo en movimiento, a medida que se lanzan nuevas versiones de la plataforma; Tendrá que ponerse al día para mantener su aplicación funcionando a medida que evoluciona la plataforma. El único beneficio que obtiene es un mecanismo de entrega semiuniversal para su aplicación que no depende de paquetes ni de tiendas de aplicaciones; pero pierde la característica principal que diferencia la web de los sistemas informáticos en red anteriores.

La web como entrega de contenido

Los sitios web centrados en el contenido son una bestia diferente; están en la tradición de la clásica World Wide Web. El contenido es interpretado libremente por el cliente, que puede realizar cualquier transformación deseada antes de la presentación. Se espera que el sitio sea accedido por un ecosistema de diferentes plataformas que pueden o no admitir los estándares actuales:

• Dispositivos móviles que admiten menos que las últimas y más caras campanas y silbatos
• Antiguos usuarios del navegador que no pueden (en la empresa) o no saben (en casa) cómo actualizar
• Versiones futuras de motores populares que desaconsejan sus antiguas API

Los perderá a todos si necesita la generación actual de javascript, que siempre está evolucionando. En este contexto, un JavaScript roto que impide acceder al contenido es un pecado.

Todos los que dicen que "se debe minimizar el uso de javascript" defienden este estilo. Está bien incluir algunos JS, claro, pero todas las funciones deberían ser redundantes con accesos básicos al contenido que podría lograrse en el lado del servidor:

• Validación de entrada de datos
• Actualizaciones de contenido AJAX para una navegación más rápida (que sin embargo funciona sin JS)

El beneficio de este enfoque es que se requieren menos pruebas y actualizaciones, y más vida útil. Las primeras páginas web estáticas de hace 20 años todavía se pueden navegar en cualquier cliente web, pero las primeras aplicaciones web están para siempre rotas. Si su sitio tiene algún valor de archivo, se beneficiará a largo plazo del uso de la web como un sistema de entrega de contenido, no como una plataforma de aplicación.

Trabajo para mi gobierno estatal y, como resultado, la mayor parte de mi desarrollo involucra sitios web interactivos basados ​​en datos. Consultas contra datos históricos, envíos de formularios, cosas por el estilo. Mantenemos nuestro Javascript al mínimo absoluto, por las siguientes razones:

1) La validación de las entradas de formulario siempre debe realizarse en el lado del servidor, nunca en el lado del cliente. Si intenta validar sus entradas en el lado del cliente, todo lo que tiene que hacer un hacker es crear una copia local de su página web y volver a escribir el Javascript para permitir lo que quiere enviarle (inyección SQL, etc.). Su validación debe realizarse en algún lugar bajo su control exclusivo, es decir, en el servidor.

2) Muchos usuarios desactivan Javascript o usan un navegador que puede no implementarlo correctamente. Siendo el gobierno, tenemos que apoyar a todos, incluso si están utilizando equipos realmente REALES. HTML funciona en todas partes; Javascript, no tanto. Al no usar Javascript en sus páginas web, les da una huella muy pequeña en la máquina del cliente, utilizando pocos recursos. Esto maximiza la cantidad de personas que pueden acceder a su contenido. Por la misma razón, no deberías ponerte demasiado loco con tu CSS. Manténgalo simple, manténgalo limpio y deje que las ancianas vean su sitio incluso si su computadora fue comprada en 1999 (Incidentalmente, recibimos llamadas de soporte técnico de personas como esta).

3) Javascript, siendo una herramienta preferida por los "desarrolladores web" en lugar de los programadores del lado del servidor, tiende a ser bastante feo. Y los diseñadores (que es lo que suelen ser los desarrolladores web, si quieres ser honesto al respecto) tienden a no ver el problema con la descarga de "scripts" desde lugares aleatorios en la web. Dicen cosas como "¿por qué reinventar la rueda?" y "No inventado aquí". Entonces, en lugar de escribir su propio código, a menudo solo salen y toman algo de otro sitio, pensando que si está en Internet es un juego justo. Hay dos problemas con esto: A) pueden publicar involuntariamente algún Javascript malicioso que te lleve un tiempo detectar, y B) pueden entrar en conflicto con los derechos de autor de alguien y hacerte demandar. Ambas situaciones deben ser evitadas.

EN GENERAL, Javascript es una mala idea. El código del lado del cliente de CUALQUIER tipo es una mala idea. El lado del cliente solo debe contener lenguaje de marcado y CSS; deje que el lado del servidor maneje el trabajo pesado.

Depende.

Si bien se puede esperar que los agentes de usuario de escritorio admitan y ejecuten su javascript de manera significativa, no todos los agentes de usuario son navegadores gráficos de escritorio, y debe decidir si desea atenderlos.

Ejemplos incluyen:

• motores de búsqueda (Google ejecuta algunos javascript, pero ciertamente no todos, y si confía en javascript para la navegación, los bots de búsqueda podrían no encontrar todo su contenido)
• agregadores y rascadores
• navegadores basados ​​en texto (aunque no muchas personas los usan)
• lectores de pantalla y otras ayudas de lectura
• (algunos) navegadores móviles

Mi regla general es que si se trata de una aplicación web para usuarios habituales (internos, de la comunidad, ese tipo de cosas), entonces confiar en javascript está bien, pero si quieres ser accesible y localizable, entonces al menos lo vital la funcionalidad debería funcionar perfectamente sin javascript, y debería fallar con gracia cuando la necesite, en lugar de exhibir un comportamiento 'indefinido'.

El enfoque anticuado está totalmente desactualizado. Por ejemplo, hice una eliminación de ajax para moderador en uno de los sitios y está contento por el evidente aumento de la velocidad.

Por supuesto, el desarrollador puede hacer dos versiones tanto para JS como para usuarios que no lo son, pero en la mayoría de los casos es extremadamente costoso y no vale el 1-2% de la audiencia del sitio web (si no eres Google, por supuesto).

Entonces mi respuesta sería NO: JavaScript es la respuesta para muchas preguntas sobre la experiencia del usuario, ¿por qué no debería usarlo?

Según mi experiencia, hubo un momento en que las empresas desactivan JavaScript por política. Pero esta vez ya no existe. Actualmente, he creado algunas aplicaciones de intranet y aplicaciones web para grandes empresas globales. Para todas las aplicaciones, el uso de JavaScript y JQuery fue parte de las cosas que el cliente esperaba.

Crear aplicaciones para clientes ya no es solo velocidad y seguridad. El cliente desea centrarse en la usabilidad y el uso de la tecnología AJAX. Sin el uso de JavaScript no funcionaría tan bien. PostBacks todo el tiempo para algunas tareas muy pequeñas como el cálculo o algo así no es una opción para la mayoría de las empresas.

Cuando pensamos en las situaciones actuales en las empresas más grandes, hay otro indicador de por qué JavaScript es imprescindible. Mire los sistemas CMS que se están ejecutando actualmente en los negocios. La mayoría de ellos utilizan Microsoft SharePoint o Adobe CQ, algunos de ellos Drupal o cualquier otro, etc. Todos estos sistemas se basan en JavaScript. Sin javascript, la mayor parte de la aplicación no funcionaría, como lo espera el usuario.

En tiempos pasados, se usaba y abusaba JavaScript, y los scripts estaban (percibidos como) llenos de vulnerabilidades y una fuente de malware.

Muchas redes corporativas respondieron deshabilitando JS, una política que (correcta o incorrectamente) todavía existe en muchas organizaciones hoy en día.

En pocas palabras, sugiero que ningún sitio debe confiar en JS para operar

Como la mayoría de las respuestas aquí explican, usar javascriptno es perjudicial. Si desea guardar su codificación y el código fuente de aspecto desordenado, intente con coffee-scriptlo que ahorrará mucho esfuerzo al escribir javascript.

http://coffeescript.org/