Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.
Saturday, July 02, 2005
Javascript no intrusivo
A pesar de que el lenguaje JavaScript ya se viene llamando oficialmente ECMAScript, el nombre antiguo es mucho más fácil de reconocer.
Aunque soy un programador al que le atraen mucho más las aplicaciones de escritorio y los lenguajes de servidor (especialmente los estáticamente tipados como C#), no puedo evitar entrometerme en temas sobre XHTML+CSS+JavaScript, máxime cuando mi trabajo lo requiere. Y de hecho, por esta razón, creo que me estoy convirtiendo en un pseudo-experto en la materia, modestias aparte :)
El caso es que en ocasiones uno empieza a profundizar mucho en un tema y se da cuenta de cómo optimizar una manera de programar, para hacerla más mantenible y robusta. Es entonces cuando entran ganas de escribir un artículo sobre ello. Pero antes de nada, intentas que no quede ningún agujero por tapar, y a mí sí que me quedaba alguno.
La cuestión es la forma de programar con javascript de manera no intrusiva, es decir, sin mezclar código XHTML con llamadas o instrucciones javascript (en eventos de tipo onclick, onchange, etc.).
El tema está en que yo conocía sólo *UN* argumento en contra de utilizar javascript no intrusivo, contra el cual tenía una solución, pero aún sin llevar a la práctica, así que me decidí a escribir en los grupos de noticias de javascript planteando la duda, antes de escribir un posible artículo. El resultado fue éste: Attaching functions to events, from external JS files.
Y no me puedo quejar, pues las respuestas me han ayudado bastante. Una de ellas me apuntó hacia un artículo sobre Unobtrusive JavaScript, lo cual puede ser una réplica sobre lo que yo exactamente quería hablar. Otra persona sin embargo se mostró totalmente contraria al uso de esta técnica, precisamente por el inconveniente que mostraba yo en mi comentario, del que escribía como sin tener absolutamente ninguna solución.
Aunque se puede leer detalladamente sobre el problema en el enlace que ya he proporcionado, haré un resumen: cuando se utiliza javascript no intrusivo, los comportamientos de los controles son adjudicados cuando se dispara el evento onload de la página, lo que puede traer problemas cuando el cliente (o el servidor) dispone de una conexión lenta o la página es muy grande.
La solución que había pensado yo (que no es perfecta) es utilizar un DIV transicional con el típico texto de "CARGANDO...", que desaparecería al cargar la página. Desgraciadamente aún no tengo la prueba de concepto, pero estoy en ello.
Más información en enlaces derivados del artículo anteriormente mencionado: Call of the wild (scripts) y Blog sobre Unobtrusive Javascript.
Actualización: La prueba de concepto ya está lista. Bueno, en realidad, lo que he preparado ha sido un módulo denominado PreContent, que se integra dentro de mi framework JavaScript AMUSE cuyo código he subido hace poco.
Aunque soy un programador al que le atraen mucho más las aplicaciones de escritorio y los lenguajes de servidor (especialmente los estáticamente tipados como C#), no puedo evitar entrometerme en temas sobre XHTML+CSS+JavaScript, máxime cuando mi trabajo lo requiere. Y de hecho, por esta razón, creo que me estoy convirtiendo en un pseudo-experto en la materia, modestias aparte :)
El caso es que en ocasiones uno empieza a profundizar mucho en un tema y se da cuenta de cómo optimizar una manera de programar, para hacerla más mantenible y robusta. Es entonces cuando entran ganas de escribir un artículo sobre ello. Pero antes de nada, intentas que no quede ningún agujero por tapar, y a mí sí que me quedaba alguno.
La cuestión es la forma de programar con javascript de manera no intrusiva, es decir, sin mezclar código XHTML con llamadas o instrucciones javascript (en eventos de tipo onclick, onchange, etc.).
El tema está en que yo conocía sólo *UN* argumento en contra de utilizar javascript no intrusivo, contra el cual tenía una solución, pero aún sin llevar a la práctica, así que me decidí a escribir en los grupos de noticias de javascript planteando la duda, antes de escribir un posible artículo. El resultado fue éste: Attaching functions to events, from external JS files.
Y no me puedo quejar, pues las respuestas me han ayudado bastante. Una de ellas me apuntó hacia un artículo sobre Unobtrusive JavaScript, lo cual puede ser una réplica sobre lo que yo exactamente quería hablar. Otra persona sin embargo se mostró totalmente contraria al uso de esta técnica, precisamente por el inconveniente que mostraba yo en mi comentario, del que escribía como sin tener absolutamente ninguna solución.
Aunque se puede leer detalladamente sobre el problema en el enlace que ya he proporcionado, haré un resumen: cuando se utiliza javascript no intrusivo, los comportamientos de los controles son adjudicados cuando se dispara el evento onload de la página, lo que puede traer problemas cuando el cliente (o el servidor) dispone de una conexión lenta o la página es muy grande.
La solución que había pensado yo (que no es perfecta) es utilizar un DIV transicional con el típico texto de "CARGANDO...", que desaparecería al cargar la página. Desgraciadamente aún no tengo la prueba de concepto, pero estoy en ello.
Más información en enlaces derivados del artículo anteriormente mencionado: Call of the wild (scripts) y Blog sobre Unobtrusive Javascript.
Actualización: La prueba de concepto ya está lista. Bueno, en realidad, lo que he preparado ha sido un módulo denominado PreContent, que se integra dentro de mi framework JavaScript AMUSE cuyo código he subido hace poco.
Labels: General, Programacion, WebDev
# posted by knocte @ 2:14 pm 
Comments:
<< Home
Buscaba información sobre Perl y termine en su bitacora.
Tras leer esta entrada, tan solo te puedo comentar que desde mi experiencia, siempre he escrito las librerias de javascript fuera de la pagina, con el objeto de reutilizar el codigo, y la forma de utilizarlo es con eventos.
Desconocia el concepto de javascript no intrusivo, pero me parece la forma mas natural de escribir codigo.
En cuanto su carga, la forma mas correcta es cargarlo y avisar al usuario, y deshabilitando el uso de la pagina hasta terminar la carga.
Otra discursión es ¿se debe utilizar javascript para validar los datos en el navegador del cliente on cargar el servidor?, pero eso es otra cuestión.
Magnifica entrada
Saludos
Tras leer esta entrada, tan solo te puedo comentar que desde mi experiencia, siempre he escrito las librerias de javascript fuera de la pagina, con el objeto de reutilizar el codigo, y la forma de utilizarlo es con eventos.
Desconocia el concepto de javascript no intrusivo, pero me parece la forma mas natural de escribir codigo.
En cuanto su carga, la forma mas correcta es cargarlo y avisar al usuario, y deshabilitando el uso de la pagina hasta terminar la carga.
Otra discursión es ¿se debe utilizar javascript para validar los datos en el navegador del cliente on cargar el servidor?, pero eso es otra cuestión.
Magnifica entrada
Saludos
# posted by 
: Sunday, January 29, 2006 6:38:00 pm
: Sunday, January 29, 2006 6:38:00 pm
Buscaba información sobre Perl y termine en su bitacora.
¡Qué raro! ;)
Tras leer esta entrada, tan solo te puedo comentar que desde mi experiencia, siempre he escrito las librerias de javascript fuera de la pagina, con el objeto de reutilizar el codigo, y la forma de utilizarlo es con eventos.
Entonces ya sabes que el Javascript intrusivo no es algo antinatural ni algo que haya inventado un loco en un garaje :) A cualquiera se nos puede ocurrir; sólo había que escoger un término que lo aunara.
Desconocia el concepto de javascript no intrusivo, pero me parece la forma mas natural de escribir codigo.
Pues aún hoy hay muchas páginas que usan Javascript inline, lo que EMO es una aberración. Incluso creo que los nuevos estándares que vienen (XHTML2) deberían prohibirlo o desaprobarlo.
En cuanto su carga, la forma mas correcta es cargarlo y avisar al usuario, y deshabilitando el uso de la pagina hasta terminar la carga.
Esto es exactamente a lo que se refiere la prueba de concepto que diseñé como ejemplo preliminar de mi módulo PreContent de AMUSE.
Otra discursión es ¿se debe utilizar javascript para validar los datos en el navegador del cliente on cargar el servidor?, pero eso es otra cuestión.
Efectivamente eso es otra discusión, pero yo tengo mi respuesta (la cual coincide con la mayoría de los programadores buenos de JavaScript y desarrollo web en general): se debe validar siempre en servidor, y opcionalmente en cliente. Lo que ocurre es que los programadores son normalmente incompetentes o vagos porque a menudo sólo validan en cliente. Con mi librería FormValidation de AMUSE se puede prevenir esto porque permite definir la validación en un fichero XML para no tener que codificar validación alguna y que automáticamente exista validación en cliente y en servidor.
Magnifica entrada
¡Gracias!
Post a Comment
¡Qué raro! ;)
Tras leer esta entrada, tan solo te puedo comentar que desde mi experiencia, siempre he escrito las librerias de javascript fuera de la pagina, con el objeto de reutilizar el codigo, y la forma de utilizarlo es con eventos.
Entonces ya sabes que el Javascript intrusivo no es algo antinatural ni algo que haya inventado un loco en un garaje :) A cualquiera se nos puede ocurrir; sólo había que escoger un término que lo aunara.
Desconocia el concepto de javascript no intrusivo, pero me parece la forma mas natural de escribir codigo.
Pues aún hoy hay muchas páginas que usan Javascript inline, lo que EMO es una aberración. Incluso creo que los nuevos estándares que vienen (XHTML2) deberían prohibirlo o desaprobarlo.
En cuanto su carga, la forma mas correcta es cargarlo y avisar al usuario, y deshabilitando el uso de la pagina hasta terminar la carga.
Esto es exactamente a lo que se refiere la prueba de concepto que diseñé como ejemplo preliminar de mi módulo PreContent de AMUSE.
Otra discursión es ¿se debe utilizar javascript para validar los datos en el navegador del cliente on cargar el servidor?, pero eso es otra cuestión.
Efectivamente eso es otra discusión, pero yo tengo mi respuesta (la cual coincide con la mayoría de los programadores buenos de JavaScript y desarrollo web en general): se debe validar siempre en servidor, y opcionalmente en cliente. Lo que ocurre es que los programadores son normalmente incompetentes o vagos porque a menudo sólo validan en cliente. Con mi librería FormValidation de AMUSE se puede prevenir esto porque permite definir la validación en un fichero XML para no tener que codificar validación alguna y que automáticamente exista validación en cliente y en servidor.
Magnifica entrada
¡Gracias!
<< Home
