Javascript framework: mootools, prototype, jquery
Desde finales de los noventa a la actualidad ha evolucionado la web a pasos agigantados. E incluso han aparecido nombres como web 2.0 , ajax , internet 2 , … pero realmente no representan de por sí ni una tecnología, ni un lenguaje de programación, si no más bien una tendencia, una moda, una exclusividad e incluso no se quien utilizaba el termino 3.0, que a mi me sigue sonando la versiones del software que compilo.
Pero si me voy a quedar con javascript no intrusivo y gracias a los framework cada vez es más sencillo lograrlo.
Todavía son muchos los desarrollos web en los que me encuentro un onclick, onload, onchage, onsubmit que son válidos aunque no tendríamos unas capas bien organizadas y por supuesto tendríamos javascript intrusivo.
Muchos debates he tenido en los desarrollos sobre mi exceso de validaciones de formularios, si ya has validado en javascript para qué validar en el lado del servidor. Por mucho que me traten de convencer yo valido siempre en el lado del servidor, ya que las palabras de Alexander Hristov nunca se me olvidarán: Siempre se valida en el lado del servidor, en el lado del cliente no sabes si realmente estará habilitado el javascript.
Actualmente hasta mi móvil interpreta javascript, no suelo navegar mucho con lynx pero si que suelo hacer muchas peticiones web con curl y con éstos no hay javascript que valga.
Con ajax podemos aprovechar la validación del servidor para mostrarle directamente al usuario los errores o campos incompletos, enviando el formulario al servidor sin hacer un submit completo de página y recogiendo el error del response.
Pero vamos aún más allá, con javascript no intrusivo, parece que tenemos más trabajo de desarrollo, pero no es cierto, logramos tener separado el html del javascript, ya que con los framework de javascript añadir eventos y peticiones con ajax a cualquier elemento html es la mar de fácil, yo suelo usar mootools, aunque me he comprometido a no hacer técnicas monopolistas y también estoy desarrollando cosas con jquery , las prototype me las dejé por el camino...
Volviendo al javascript no intrusivo, primero desarrollo el form como una petición normal, completa de página y me devuelve el resultado , errores o correcto proceso. Una vez que la pantalla hace su funcionalidad completa, a la vieja usanza, le añadimos el javascript, pero no con onclick o onsubmit si no con un addEvent al form html ya sea por id o por selectors , cambio el submit para que sea por ajax y en el lado del servidor, sea servlet, struts, php, Django, … no redirijo a la página, vista, si no tan solo devuelve el mensaje de error u ok del servidor, a veces es mejor enviar una cabecera de error 501 yo prefiero un 400 Bad Request y así en ajax podemos utilizar el response status code, para saber si el servidor ha dado error o ha realizado el proceso correctamente.
El usar javascript NO intrusivo va a dejar un html más limpio para SEO, los rastreadores que navegan como el lynx, al tener la funcionalidad válida para petición http como para petición ajax nos convertirá en más versatil el desarrollo en el lado del servidor.
Me quedo con las ganas de insistir en el MVC Modelo Vista Controlador y en separar las css y el html, pero me lo guardo para otro POST
Pero si me voy a quedar con javascript no intrusivo y gracias a los framework cada vez es más sencillo lograrlo.
Todavía son muchos los desarrollos web en los que me encuentro un onclick, onload, onchage, onsubmit que son válidos aunque no tendríamos unas capas bien organizadas y por supuesto tendríamos javascript intrusivo.
Muchos debates he tenido en los desarrollos sobre mi exceso de validaciones de formularios, si ya has validado en javascript para qué validar en el lado del servidor. Por mucho que me traten de convencer yo valido siempre en el lado del servidor, ya que las palabras de Alexander Hristov nunca se me olvidarán: Siempre se valida en el lado del servidor, en el lado del cliente no sabes si realmente estará habilitado el javascript.
Actualmente hasta mi móvil interpreta javascript, no suelo navegar mucho con lynx pero si que suelo hacer muchas peticiones web con curl y con éstos no hay javascript que valga.
Con ajax podemos aprovechar la validación del servidor para mostrarle directamente al usuario los errores o campos incompletos, enviando el formulario al servidor sin hacer un submit completo de página y recogiendo el error del response.
Pero vamos aún más allá, con javascript no intrusivo, parece que tenemos más trabajo de desarrollo, pero no es cierto, logramos tener separado el html del javascript, ya que con los framework de javascript añadir eventos y peticiones con ajax a cualquier elemento html es la mar de fácil, yo suelo usar mootools, aunque me he comprometido a no hacer técnicas monopolistas y también estoy desarrollando cosas con jquery , las prototype me las dejé por el camino...
Volviendo al javascript no intrusivo, primero desarrollo el form como una petición normal, completa de página y me devuelve el resultado , errores o correcto proceso. Una vez que la pantalla hace su funcionalidad completa, a la vieja usanza, le añadimos el javascript, pero no con onclick o onsubmit si no con un addEvent al form html ya sea por id o por selectors , cambio el submit para que sea por ajax y en el lado del servidor, sea servlet, struts, php, Django, … no redirijo a la página, vista, si no tan solo devuelve el mensaje de error u ok del servidor, a veces es mejor enviar una cabecera de error 501 yo prefiero un 400 Bad Request y así en ajax podemos utilizar el response status code, para saber si el servidor ha dado error o ha realizado el proceso correctamente.
El usar javascript NO intrusivo va a dejar un html más limpio para SEO, los rastreadores que navegan como el lynx, al tener la funcionalidad válida para petición http como para petición ajax nos convertirá en más versatil el desarrollo en el lado del servidor.
Me quedo con las ganas de insistir en el MVC Modelo Vista Controlador y en separar las css y el html, pero me lo guardo para otro POST
Comentarios
Publicar un comentario