Micaela 4 de Febrero de 2010 a las 08.00
   Imprimir artículo
elWebmaster.com

Javascript: ¬ŅCu√°ndo usarlo y cu√°ndo no?


javascript_125x125Javascript es tan flexible y permite llevar a cabo una cantidad de tareas tal que es f√°cil pecar utiliz√°ndolo para cosas que, originalmente, no fue concebido.

Esto implica un problema cuando hay otros lenguajes que harían mejor una tarea determinada. Repasemos en qué casos resulta mejor usar Javascript y en cuáles no.

Cu√°ndo NO usar javascript

Validación de formularios

Con Javascript puedes validar formularios. Puedes crear una gran experiencia del usuario utilizando este método, pero sería tonto no validar todas las entradas nuevamente con un lenguaje de lado del servidor antes de procesarlas. Si deseas elegir uno o el otro, utiliza el del lado de servidor. Si puede hacerse con otro lenguaje, usa el otro lenguaje.

Insertando contenido

Si necesitas cargar un bloque de navegación dinámico y no lo puedes crear en un archivo que puede ser incluido en el lado del servidor de la página de inicio; puedes utilizar la función load de jQuery para llamar al bloque. Funciona genial a menos que no puedas o quieras utilizar JavaScript. Si puede hacerse con otro lenguaje, usa el otro lenguaje.

De forma similar, el concepto completo de AJAX es generalmente considerado un hack. Es una manera de simular la comunicación bidireccional en una tecnología construida para una entrega de un solo lado. Cuando surge algo nuevo que acomoda con más naturalidad la comunicación bidireccional de navegador-servidor, AJAX se marcha. Si puede hacerse con otro lenguaje, usa el otro lenguaje.

Dando estilo

JavaScript es capaz de aplicar estilo a los elementos de una página. Ese también es el trabajo de CSS. Tener mucha información de estilo hace que el Javascript sea más difícil de leer, y las actualizaciones de estilo más difíciles de rastrear. Si puede hacerse con otro lenguaje, usa el otro lenguaje.

Una de las mayores razones por la cu√°l las librer√≠as JavaScript son populares es porque abren la puerta a una gran cantidad de posibilidades de dise√Īo. Puedes realizar fades in y out, animar los tama√Īos y posiciones y m√°s. Pero estas cosas est√°n, por lo general, relacionadas con el dise√Īo y no con la funcionalidad. Por lo que CSS es m√°s apropiado para estas cosas. Si puede hacerse con otro lenguaje, usa el otro lenguaje.

Cu√°ndo usarlo

Suficientes casos de cu√°ndo no usarlo. Existen muchas circunstancias en las que utilizar Javascript es la √ļnica opci√≥n. Por ejemplo, en los eventos. Javascript es el √ļnico lenguaje disponible para hacer que tu sitio web se comunique con el navegador y observar eventos como clics, doble clics, focos de mouse, teclas presionadas… y la lista sigue. Si necesitas acceso a dichos eventos, Javascript es tu territorio.

Fuente: CSS-Tricks


Enviar a Del.icio.us Enviar a Meneame Enviar a Digg Enviar a Fresqui Enviar a Enchilame

Comentarios (9)

  1. Jose dice:

    Pienso que el problema ya no está en cuándo usar o no usar javascript, sino en cómo usar javascript. AJAX es un excelente aliado que mejora notablemente la experiencia de usuario, siempre y cuando se desarrolle este código de forma correcta, es decir, creando código no obstrusivo para el navegador. Entonces sí tendríamos un site accesible aunque javascript estuviese deshabilitado en el navegador.

  2. José Galisteo dice:

    La idea final del post es buena, pero creo que está mal enfocada y no explicas apenas porqué hacerlo.

    Por ejemplo, la validación de formularios, a parte de poder hacerse en cliente con javascript para dar una experiencia de usuario más rica y fluida, es imprescindible hacerla en servidor pues con unos conocimientos mínimos los formularios se pueden modificar con oscuros propositos.

    El insertar bloques de código, de cara al seo y de la accesibilidad debería hacerse en el servidor para que cualquier programa sin necesidad de javascript pueda leer todo el contenido de la página.

    Eso de dar estilos con javascript me suena un poco raro, lo habitual es darle clases css a elementos mediate javascript para que el usuario reciba feedback de sus acciones sin tener que recargar la página. Por otro lado eso de animar elementos como dices sin javascript no se me ocurre como, a excepción de lo que han hecho algunos máquinas del CSS, pero lo que he visto suele ser experimental.

    Saludos.

  3. Eduardo dice:

    A mi criterio javascript es uno de los mejores inventos que hay. Y con la salida de Jquery todo se simplifico muchisimo. Se puede hacer practicamente lo que uno quiera, y todo de forma muy simple y cross-browser.

  4. Pablo Molina dice:

    Bueno… y ahora me surge la duda, ¬ŅPor qu√© no validar los formularios con JS en el cliente, y de esta manera, cuando los datos lleguen al servidor, al menos vas a tener la seguridad de que ya est√°n todos y bien validados?

  5. neojavan dice:

    Me gustaría que ahondaras un poco más en este artículo y expusieras los equivalentes para trabajarlos sin javascript, ya que sinceramente uno se vuelve dependiente de jscript y todas sus aplicaciones y frameworks

  6. Daniela dice:

    @Pablo Molina: Porque es muy f√°cil desactivar javascript y enviar datos no v√°lidos al server. Recuerden siempre, javascript est√° para mejorar la experiencia del usuario y nada m√°s. No hay nada que no se pueda hacer en una web sin javascript. No es imperioso utilizarlo.

    Cuando se desarrolla un sitio web hay que emplear la t√©cnica conocida como “mejoramiento progresivo” (progresive enhancement) o tambi√©n “degradaci√≥n elegante” (graceful degradation) que consiste en apoyarse en HTML puro, hacer que el sitio tenga toda la funcionalidad SIN javascript y reci√©n cuando est√© terminado aplicar javascript para mejorar la experiencia del usuario.

    En el caso de la validación esto implicaría, por ejemplo, empezar por un formulario simple, que se envía al servidor y se valida por backend. Se devuelven los mensajes de error en la recarga de la página y se muestran al usuario. Luego, se puede aplicar javascript para pre-validar el form y mostrar los mensajes mientras el usuario está llenando el formulario, evitando que cometa errores innecesarios y mejorando su experiencia con el sitio.

    Pero aunque cueste m√°s trabajo, desarrollando de esta manera se logra que el sitio siga funcionando correctamente en navegadores con javascript desactivado, en navegadores solo texto como Lynx, en celulares, en lectores de pantalla para ciegos y otros dispositivos fuera de lo com√ļn.

  7. Camilo dice:

    Me gustó bastante el artículo, pero debo hacer notar que tanto AJAX como jQuery son derivados de javascript, esto es, para la inserción de contenidos estarás ocupando javascript de igual manera.

    AJAX recordemos es una abreviatura para (Asynchronous Javascript And Xml).
    jQuery está creado sobre javascript, es una librería hecha a partir de la función jQuery o $, que no hace más que trabajar con closures dentro de si.

    Un saludo y sin afan de discutir, solo de dar mi opinión ^^.
    Greetings

  8. ivan mrsnik dice:

    EL autor del articulo pareciera facil decir eliminar javascript en formularios, pero no toma en cuenta que el usuario es flojo, por tanto si le dices que algo es obligatorio, no lo toma en cuenta, si le dices que es una fecha escribe letras, en sitios de poco transito, si lo quitas puede no afectar, pero sitios de alto transito y donde tengas reportes desde el servidor, movientos de archivos, un formulario para que sea valiodado puede tardar 30 o mas segundos desde el servidor, por tanto para que despues diga que no sirvio algo, se convierte en datos que suben que bajan saturando mas la conexion.
    Por tanto las validaciones son en javascriopt para desahogar el ancho de banda y el servidor, y en el servidor para revalidar y hacer validaciones que desde el cliente no son posibles.

  9. fcodiaz dice:

    Pues.. no es por invalidar a nadie.. pero los casos de No Uso termina recomendando JS as√≠ que no se que tan capacitado este el autor para hablar de este tema U.u….

    Validaci√≥n de formularios->.. si bien el tema de las “validaciones” de lado cliente es asunto delicado, lo que es verdad es que si se necesita hacer un sitio mucho mas din√°mico y amigable se debe de hacer uso de validaciones de con JS, ahora por seguridad estamos OBLIGADOS a realizar esta validaci√≥n de lado servidor ya que cualquiera y no exactamente desde una web/form se pueden hacer peticiones a nuestro recurso y enviar las variables con los valores que se nos pegue la gana.. pero no creo que este campo sea un campo donde se deba expulsar JS, al contrario este brinda de mucha mas interactividad a nuestro sitio y mejora la experiencia de usuario en conclusi√≥n NO podemos fiarnos de las validaciones en JS ya que este solo “valida” la SALIDA del form y brincarte esta validaci√≥n es un chiste, y se debe de validar la ENTRADA en nuestros procesos en el servidor que es una cosa y asunto completamente distintos y no podemos fiarnos a que la aplicaci√≥n que consuma o haga la petici√≥n nos valide los datos tenemos que volver a validar, son capas distintas e independientes..

    ->Cargando Contenido
    en la carga de contenidos.. jQuery === JS, jQuery en pocas palabras es una function jQuery(){mucho codigo aki}, con la que interactuamos, jQuery es termina siendo un Prototipo/Class de JS, solo es una librer√≠a que encapsula algunas de las situaciones mas comunes y un tanto complicadas de JS en funciones abstractas las cuales solo hay que usar, no es ni una nueva tecnolog√≠a ni un nuevo lenguaje $(”div”).load(”recurso.php”) esta escrito en JavaScript..

    AJAX===JavaScript, AJAX es una implementación de JavaScript, es el simple uso de XHR un Objeto nativo de JavaScript

    La carga din√°mica solo se puede hacer por JS.. si quitamos JS solo nos queda regresar al Post/Back de la antigua Web o bien regresar a los Frames..

    ->Dando estilo, CSS siempre ha sido el encargado de colocar el estilo en la web, JS se utiliza para modificar el DOM y con ello las CSS que conforman la pagina, JS en la web actual se usa para cambiar de clases y las propiedad CSS de forma dinámica, JS no remplaza CSS, antes en el DHTML se modificaba los atributos de los element del DOM, en la actualidad se ha visto que es mejor modificar los Styles y Clases CSS que definen el estilo del Element, para hacer esto de forma dinamica el encargado es JS para jugar con esto, pero CSS siempre es el que define.. digamos que CSS. si bien recomiendo que se los valores de los estilos sean mapeados en una class y js solo se use para agregar/retirar y cambiar Clases a un elementos, realmente es una mala practica definir los valores de estilos dentro de un JS es este si le doy al autor un poco de razón.

    Cu√°ndo usarlo-> los ejemplos que mencionas de donde usarlo y donde es el luegor el √ļnico que compite en esto es VBScript que solo funciona en los IE y con ello hace que este lenguaje sea descartado…

    los verdaderos parametros para saber si una interfaces NO debe de ser enriquecida con JS son:

    1 - Si tu web es enfocada para ser vista por exploradores MUUUUY viejos anteriores de IE6
    2 - Si tu web se desplegara en otras Dispositivos que no son una PC/Lap con un explorador
    3 - Si tu Web necesita Indexación en buscadores y/o navegación x exploradores de Texto y/o Roobots
    4 - Si solo te interesa que funcione en IE, puedes usar VBScript y olvidarte de JS
    5 - Si no sabes JS o no sabes usar una Tool que te facilite el “”programar”" en JS (jQuery)
    6 - Si tu web es enfocada a ser usada en los 90’s u 80’s

    Esos para mi serian los verdaderos motivos para no usar JS, que si vemos hay tecnicas para crear una web que sea amigable para distintos entornos y distintos dispositivos, as√≠ que para la web que se ejecutara en una PC con un explorador siempre se podr√° hacer una versi√≥n paralela con las caracter√≠sticas que requiera el dispositivo as√≠ que los √ļnicos motivos reales para no usar JS seria los puntos 4,5 y 6

    lo de la “nueva tecnolog√≠a” que facilite la tecnolog√≠a lado cliente/servidor, no creo que lleugue y mucho menos que JS y su objeto XHR(AJAX) desparescan, el ultimo esfuerzo que vi por tener una nueva via de comunicaci√≥n fueron los WebSockets de HTML5 que se manejaban con JavaScript U.u, se podra ir XHR pero no JS, pero estos WebSockets se cancelo su desarrollo e implementaci√≥n por que era muy f√°cil que se violentara la seguridad de los usuarios

    por lo que se en las ultimas implementaciones de CSS3 se esta manejando algunas cosas que podria suplir algunas animaciones de JS basadas en modificar CSS esto va a ser posible pero si temor a equivocarme pasara mucho tiempo(a√Īos) antes de que sea conveniente usar este tipo de animaciones en un √°mbito profesional y no de beta testers

    en conclusión los invito a aprender realmente JS, que es el presente y el futuro de la web asi como el lenguaje servidor de su preferencia, y una vez que conoscan JS conoscan algunas utilerias que le facilite la vida, hoy a cualquier desarrollador web que se digne de serlo deberia de saber JS

    aqui une enlace a unas conclusiones despues de jsConf de un blogero que suelo visitar http://www.pixelovers.com/pixelovers-jsconf-eu-2010-berlin-907530

    me gusto mucho esta conclusión:

    Learning Javascript used to mean you weren’t a “serious software developer”. Today, not learning Javascript means the same thing (James Governer)

Deja tu opinión

© 2007 - 2008 elWebmaster.com | Powered by Wordpress | Diseño CSS y XHTML válido. | Algunos íconos basados en FamFamFam Mini
Iniciar sesión