Que libreria JS utilizas?

[Calisco]

Puede ser ... se está armando el cierco en La guerra de los FrameWorks. Nos vemos ahi ?

[Shiryu_Libra]

esto se pondre interesante

[AlZuwaga]

Interesante discusión.. de la que sólo puedo aprender mas no aportar

Hace muy poco me he metido a hacer algunas cosillas con AJAX (Shiryu_Libra es testigo ;). En el camino me puse a leer dicho foro... pero terminé muy perdido. No sé, como que alguien hacía una consulta (tal vez no demasiado puntual) y se le respondía que con json, scriptuaculous y no sé que otro más se podía lograr, que era más eficiente, etc, etc, etc.

A mi me dieron "miedito" y finalmente las dudas las despejé en el foro javascript.

Y, si bien tal vez esté diciendo alguna gilada, esto me hace pensar en un replanteo del foro AJAX. O al menos cambiarle el nombre a FrameWorks (o similar) y utilizar el foro JS para todo lo relacionado con AJAX en donde no se use un FW prefabricado.

Reitero que soy neófito en el tema, así que es muy probable ue esté diciendo disparates!

Saludos y estaré atento al desarrollo y comentarios de este tema.

[Shiryu_Libra]

y funciono perfectamente A_Z(), y si habra que hecharle porras a alguno de los TEAMS que se estan conformanco, definitivamente el apoyo seria para los que no requieren FW, para implementar y que son aventureros de crear sus propios procedimientos.

no desmerito a los que utilizan procedimientos que ya estan preformateados solo para implementacion, ya que en ciertos casos te salvan de muchos dolores de cabeza, pero tal cual mencionaron Panino, Caricatos, Derkenuke, tener control de tu programacion es preferible en un 90% de los casos, ya que al conocer todo el procedimiento de la pagina, creas, eliminas o incluso vas directamente al detalle, y no tienes que batallar en muchos casos, con errores de compatibilidad de los datos y tener que atormentarte corrijiendolos casi casi a diario

en mi caso, solo como observador seré ya que si en caso afirmativo se realiza la competencia, sera un incentivo extraordinario para aprender de cualquiera de los equipos que realizen su trabajo

mientras sigo mirando

[programeitor]

Me apunto, espero que sea de probecho.

Postdata: por favor.. ,no hagan alegoria.

[derkenuke]

Iniciado por Panino5001

Yo propongo realizar un resolvedor de sudokus íntegramente hecho con javascript.

Me apunto!!

Sobre todo porque ya hice uno... jeje. Hace mucho postee sobre aquello... Bueno, no era un resolverdor de sudokus, era un generador de sudokus. Pero bueno, se le parecerá. Un tema complicado y no obtuve respuesta, pero al final salió más o menos.


Buena temática Panino!

[miketrix_esp]

Despues habría que comprobar que el script es cross-browser, que funciona para todos los navegadores populares ;)

(que por cierto es una ventaja de los frameworks... ejem :P)

[caricatos]

Iniciado por miketrix_esp

Despues habría que comprobar que el script es cross-browser, que funciona para todos los navegadores populares ;)

(que por cierto es una ventaja de los frameworks... ejem :P)

Con unas mínimas consideraciones se consigue que un código javascript corra en todos los navegadores... (por cierto, se podría obviar el netscape de los layers...):

Evitar el document.all, y a la vez usarlo para discriminar cosas como addEventListener/attachEvent o target/srcElement... olvidarse de getElementsByName (que explorer lo implementa por el id... como si se pudiese duplicar ¿?)... y pocas consideraciones más

Saludos

[miketrix_esp]

Yo creo que a estas alturas ya se podría sacar una conclusión clara a todo esto. Desde mi punto de vista creo que una libreria o framework JS es altamente recomendable para proyectos medianas-grandes (hablo de proyectos que pueden durar meses o que trabaja en él un equipo de personas) aportando agilidad y "estandarización" en la codificación. Para páginas web simples o portales puede que sea igual de costoso usar el js nativo que un framework, en estos casos no se notará mucho la diferencia entre uno y otro.

Para compararlo, estaba ahora ojeando el Zend Framework para PHP, que lo han sacado los propios que han desarrollado el php engine2 (el motor del PHP5), y se podría abrir la misma discusión que tenemos con el JS, pero si han trabajado en un proyecto así es por algo digo yo. Por qué JAVA es considerado uno de los lenguajes más potentes y completos? Pues curiosamente es de los lenguajes que tiene un framework más extenso (multitud de librerías para lo que quieras y más)

[caricatos]

Hola:

Cualquiera que haya estudiado programación (en un nivel aceptable) sabe que debe documentar el código, y un proyecto bien documentado es fácilmente modificable... y un código sin documentar y "caótico", usando la mejor librería puede ser muy difícil de modificar, así que no creo cierta tu afirmación.

Incluso, tratándose de grandes proyectos, sin duda con "código nativo" se conseguirá un código más rápido... y con menor consumo de recursos.

Lamentablemente en esto de las páginas web hay mucho intrusismo, y los códigos de la mayoría de las páginas es "horrorosamente caótico", plagado de códigos que empiezan por "MM_" (aún más caótico en mi opinión), o los típicos mensajitos (comentarios) en inglés, indicando una "dudosa procedencia"...

Pues yo creo que al que le gustan los frameworks o librerías (o como se se llamen) está bien que las usen... pero todo lo que se aporte del javascript clásico posiblemente mejore el rendimiento, y sin duda ayudará a aprender mejor el lenguaje.

Saludos

[eContento]

Estoy con Caricatos,

Habitualmente tardas menos en desarrollar lo que necesitas que en entender el API del framework. Además todo desarrollador ya tiene su propia colección de recursos y funciones... Reutiliza su propio código.

Conocía de la existencia de Prototype, pero no había oido nada de los otros frameworks. Recuerdo que el primero que empezó a hacer esto en serio fue Dan Steinman, en su día con su DynAPI, hasta que un grupo de sourceforge se metió a desarrollar el DynAPI 2. Recuerdo, que me lo miré, porque entonces eran muchas las páginas que usaban el CollapseMenú de este señor. Casi me muero.

Habitualmente no es necesario hacer cosas tan complejas, y cuando lo es, pues genial, eso es lo divertido de nuestro trabajo y para eso nos pagan. Yo echo de menos que caigan más problemas complejos en mi mano: suelen ser siempre sota, caballo y rey.

Y todo lo de Cross-Browser, yo sinceramente, creo que hoy por hoy, siendo casi todos los navegadores DOM, se puede desarrollar de una forma muy estándard para todos. Aquellos que siguen haciendo discriminación por navegadores de forma habitual, creo que se complican la vida innecesariamente.

Otro motivo para no usar librerías de JavaScript, es que estás cargando en memoria un core bastante pesado, para luego usar el 5%.

[kepawe]

Hola a todos:
Comparto más punto de vista de miketrix_esp.
Una pregunta.

¿Por qué Mozilla utiliza prototype en Mozilla Developer Center y jQuery en Firefox Add-ons?

Salu2.

[miketrix_esp]

Habitualmente tardas menos en desarrollar lo que necesitas que en entender el API del framework. Además todo desarrollador ya tiene su propia colección de recursos y funciones... Reutiliza su propio código.

Cierto, pero no siempre puede ser productivo para una empresa. Si un día se va de la empresa, por muy perfecto que haya documentado y desarrollado su API y sus funciones, el coste de la nueva persona encargada de aprender eso existirá sí o sí.

Dejo en el aire la siguiente pregunta: Por qué una web como puede ser la de apple.com, que podría perfectamente desarrollar su propio framework JS, esta utilizando prototype? Porque solo deben contratar a becarios, programadores "de bajo nivel"? (va por caricatos jeje)

[derkenuke]

Yo opino que lo mejor que puedes hacer es crearte tu propio framework, que tenga las funciones JUSTAS para lo que quieres hacer.

Otra cosa es que no tengas tiempo, pero si no tienes tiempo, pues haz una cosa prefabricada, hazte un wordpress y véndelo, yo que se... pero no es manera de hacer las cosas.


Para algo se supone que paga el cliente ¿no? Al final sacarán un programa para programar con frameworks, para añadir funciones con botoncitos. Pero bueno, eso nunca funciona (tipo MM_...).


Bueno, ahí las conclusiones.

[eContento]

Bien, otra cuestión... que no conozco.

¿Cuándo alguien usa prototype lo pone en local en su web o tiran de los archivos JS de la web de prototype? Porque si realmente es verdad que tantos sitios usan prototype, lo suyo sería que la carga de esos archivos se cachearan en el navegador, y si cada uno los pone relativos a su servidor, no se gana mucho.

Hasta ahora ¿cómo lo hacen las webs que usan prototype?

[Holden]

Iniciado por derkenuke

Para algo se supone que paga el cliente ¿no? Al final sacarán un programa para programar con frameworks, para añadir funciones con botoncitos. Pero bueno, eso nunca funciona (tipo MM_...).
Bueno, ahí las conclusiones.

Me parece que una cosa no quita la otra.
Usar un framework no significa estafar al cliente. Me parecería menos ético pasarle 50 hs de trabajo a alguien por hacer un toolkit de ajax para su página que terminar usando algún fwk.
Escribir código para soluciones que ya existen y ademas están testeadas por miles de usuario me parece una pérdida total de tiempo.

Es obvio que si somos desarrolladores hay que conocer js y no se puede vivir de la vida dependiendo de un fwk. es cuestión de buscar el balance. Ambos extremos los considero no apropiados.

Esa es mi opinión y respeto las opiniones del resto.

[Calisco]

Aca hay un punto que no se esta teniendo en cuenta, me parece. Se habla de FrameWorks como simples extensiones interpretadas por JS; pero lo que no se comenta es que estamos en el centro evolutivo de JS.
JS volvió a tener un protagonismo medianamente desplazado por otras tecnologías, por ejemplo, flash.
Hoy un programador piensa en flash solo como reproductor de videos o cosas muy puntuales que JS no puede (ni le interesa) implementar.
Lo cierto es que los frameWorks le van a decir a JS como tiene que evolucionar, y lo que hoy es una implementación interpretada, en FF3 va a ser en forma nativa.
En post anteriores puse getElementByTagName. Ahora se empieza a pensar en la funcion dollar $(). Está bien, es una pavada usar $() o getElementById ... pero da muestra de que JS estará evolucionando para donde digan los FW.
De alguna manera ... todos los FW ponen en práctica y bajo pruebas métodos y tecnologías que JS no puede hacer, porque no se puede dar el lujo de hacer prueba y error. Los FrameWorks si; por eso algunos son tan inestables.

[miketrix_esp]

Yo opino que lo mejor que puedes hacer es crearte tu propio framework, que tenga las funciones JUSTAS para lo que quieres hacer.

Mootools por ejemplo te permite descargar la libreria js con aquellos componentes que necesitas (http://mootools.net/download). Con Scriptaculous cargas los efectos o funcionalidades que tú quieras. Vamos, que ellos tambien se fijan en el peso :P

Y por cierto, comparto lo ultimo que ha dicho holden y calisco.

[caricatos]

Iniciado por miketrix_esp

...

Dejo en el aire la siguiente pregunta: Por qué una web como puede ser la de apple.com, que podría perfectamente desarrollar su propio framework JS, esta utilizando prototype? Porque solo deben contratar a becarios, programadores "de bajo nivel"? (va por caricatos jeje)

¡Je, je!

La verdad es que la contratación de becarios me parece una opción muy acertada en esas empresas donde reciben subvenciones de la administración... no sé si será el caso de apple, pero en España es algo muy normal, y al menos esos becarios tienen (o suelen tener) una buena preparación.

Saludos

[buzu]

Estoy al 100 con Caricatos. En lo personal no uso ningun FW y espero nunca tener que hacerlo. Se pueden conseguir buenos efectos con esos FW pero a la larga vamos dejando detras el codigo nativo y olvidando que es lo que realmente hace posible que un div degrade su color de rojiso a verde claro. Eh encontrado ciertos efectos realizados con mootools, prototype y otras librerias los cuales no encuentro que sean de mucha ciencia. No olvido tampoco a jQuery que tambien parece ser popular en estos dias.
A mi me gustan las cosas claras y como siempre se ha discutido y como siempre eh defendido no hay nada mejor que un codigo entendible y semantico. Para mi es mas entendible un getElmentById() que un $().
Al final de cuentas ese $() llamara al getElementByID tarde o temprano por lo que si uso directamente el getElementById le ahorro al ordenador un paso.

No estoy muy familiarizado con los FW y quiza mi respuesta sea erronea. PEro para mi no hay nada como el reto de realizar algo con codigo nativo y siempre seguro de lo que estoy haciendo.

[Snd234]

Iniciado por buzu

Al final de cuentas ese $() llamara al getElementByID tarde o temprano por lo que si uso directamente el getElementById le ahorro al ordenador un paso.

Claro, si solo quieres tener una referencia al elemento y realizar por ejemplo una validación, usa getElementById, pero si quieres tener referencia a ese elemento y hacer otra acción, ya sea cargar algún contenido de una petición AJAX, agregarle algún efecto, u otro, mejor utilizar la librería... Para que reinventar la rueda si ya existe? si al final todo se trata de eso, reutilizar código...

[buzu]

Para mi es mejor guardar la referencia al objeto en una varible.

Código HTML:

<script type="text/javascript">
     var customDiv = document.getElementById("custom");

</script> 

Después soolo necesitaría escribir customDiv. Claro que no es tan corto como un simple $() pero es mas especifico. Quizá las librerías sean una buena opción dependiendo del tipo de programador que eres. Me refiero a la forma en que te gusta programar pero al final de cuentas lo único que hace posible que jQuery, mootools, prototype y todos los FW escritos en javascript funcionen es simple javascript.

[Ismail al-yahoo]

Por lo que veo falta una mirada sobre proyectos mas que sobre simples paginas.

Concuerdo con los que prefieren frameworks porque justamente en un proyecto se busca mejorar la velocidad de desarrollo, tener una base comun en el/los equipos de desarrollo y poder crear aplicaciones web (no paginas web normales) que hagan mas de lo que hacen actualmente.

Basarse en lo que "normalmente" se hace en una pagina web es negarse a la evolucion natural, se debe pensar justamente en lo que es nuevo e innovador no en lo "normal" que en la practica es lo que esta a punto de ser obsoleto y anticuado.


Algunos opinan que ya tienen sus funciones que reutilizan y por eso no necesitan Frameworks. ¿pero no son acaso esas funciones un pseudo-framework? si quisieran trabajar en un grupo de desarrollo tendrian que documentar y explicar el uso de esas funciones al resto de los desarrolladores y quizas estos tambien tengan sus propias funciones, por lo tanto la curva de aprendizaje es similar y ni siquiera habria compatibilidad en el codigo general del proyecto.



Creo que evaluar un framework por lo que se puede demorar $() contra getElementById no tiene un sentido practico real. El objetivo no es bajo ningun aspecto mejorar unas velocidades en milisegundos que los usuarios finales no van a apreciar. Obviamente si un framework js es tan simplista que debe cargar toda su estructura para poder ocupar un 5% de el, entonces es un MAL FRAMEWORK, pero no todos hacen eso, la mayoria por lo que he visto y probado te permiten cargar un nucleo pequeño y luego secciones o plugins especificos.



A mi parecer la unica forma de evaluar si es mejor utilizar un framework o ser un fundamentalista de js, es la calidad de los sitios que podemos desarrollar, en cuanto tiempo y si es posible . Estando el tiempo de procesos en margenes que el usuario acepte o ni siquiera note pasa a ser un factor irrelevante para comparar.

Y obviamente si quieren competir hagan algo como un carro de compra donde selecciones tus productos con drag&drop, algunas ventanas de confirmacion y/o consulta que sean modales y alguna grilla de datos con paginacion y ordenamiento al hacer click en cada columna.

[Ismail al-yahoo]

Yo personalmente utilizo jQuery por ser una muy pequeña libreria de 19kb, es casi como poner un .gif en el sitio. Es bastante potente al facilitarme trabajar con AJAX, acceder a cada parte del documento y modificar facilmente css, HTML y clases ademas existe una gran cantidad de plugins que me permiten hacer muy rapido y muy simple cosas como drag&drop, grillas de datos, tabs, treeViews, menus, etc.

Antes de jQuery apredi a usar prototype, pero termine por usar jQuery por ser mas liviano y simple. Actualmente quiero echarle una mirada a Dojo por lo potentes que se ven las aplicaciones creadas en el, espero que no sea muy pesado y lento para el usuario ni para mi aprenderlo.


Comprendo a los que no quieren aprender un framework por tener que aprender mas formas de sintaxis para lo que ya hacen (aunque con mucho mas trabajo y tiempo), ademas se que es desagradable (y por algo nacio este thread) elegir un framework y despues darse cuenta de que otro es mejor, o simplemente no saber cual es mejor y tratar de aprenderlos todos, pero la ventaja que te otorgan es grande, mucho mas cuando estas con un grupo de desarrollo y debes tomar desiciones y ponerte de acuerdo. Es impresindible hablar el mismo idioma.

y si tienen dudas sobre cual es mejor, que en tal foro dicen tal cosa, que en el otro dicen lo contrario, pues mejor elijan el que mas les tinque y aprendan a ocuparlo correctamente, es mejor saber alguno que quedarse paralizado por la duda, yo por facilidad de aprendizaje prefiero jQuery .



Ademas los frameworks estan echos en js, sus plugins estan echos en js, y estan bien documentados por lo que modificarlos en caso de que algo no te acomode, no es ningun problema. Yo he modificado para mis proyectos algunos plugins de jQuery y no veo ninguna barrera que te obligue a acomodarte al framework en ves de que este se acomode a ti. es simplemente meterse en un archivo .js




y finalmente, si no fuera por los frameworks de js ahora estariamos discutiendo sobre como se pueden hacer llamados ajax, menus, drag&drop y formularios modales en flash y no en JS. Han sido claramente el elemento que ha revitalizado el lenguaje empujando a flash a su mercado de diseñadores graficos.

[caricatos]

Iniciado por Ismail al-yahoo

Por lo que veo falta una mirada sobre proyectos mas que sobre simples paginas.
...
Y obviamente si quieren competir hagan algo como un carro de compra donde selecciones tus productos con drag&drop, algunas ventanas de confirmacion y/o consulta que sean modales y alguna grilla de datos con paginacion y ordenamiento al hacer click en cada columna.

¿Acaso es una propuesta concreta para un desafío?

Iniciado por Ismail al-yahoo

...
y finalmente, si no fuera por los frameworks de js ahora estariamos discutiendo sobre como se pueden hacer llamados ajax, menus, drag&drop y formularios modales en flash y no en JS. Han sido claramente el elemento que ha revitalizado el lenguaje empujando a flash a su mercado de diseñadores graficos.

¿No estarás confundiendo frameworks con ajax?

Nadie duda de lo valioso que puedan ser los frameworks, pero no creo que sean tan fáciles de aprender y usar... en concreto, un número importante de preguntas sin respuesta en estos foros son las que se refieren a soluciones con los frameworks... ¿o será que los que aprenden algo de ellos no están dispuestos a compartir sus conocimientos?

Saludos

[marcopoloaz06]

Yo uso jQuery es la mas chida!!

[derkenuke]

Iniciado por caricatos

Iniciado por Ismail al-yahoo

Por lo que veo falta una mirada sobre proyectos mas que sobre simples paginas.
...
Y obviamente si quieren competir hagan algo como un carro de compra donde selecciones tus productos con drag&drop, algunas ventanas de confirmacion y/o consulta que sean modales y alguna grilla de datos con paginacion y ordenamiento al hacer click en cada columna.

¿Acaso es una propuesta concreta para un desafío?

Pues sinceramente, si es una propuesta para un desafío la veo tan complicada de abordar desde un principio que si ya obtenemos poca participación en validar un formulario, no quiero ni pensar en un proyecto mixto de esas envergaduras...

Iniciado por Ismail al-yahoo

y finalmente, si no fuera por los frameworks de js ahora estariamos discutiendo sobre como se pueden hacer llamados ajax, menus, drag&drop y formularios modales en flash y no en JS. Han sido claramente el elemento que ha revitalizado el lenguaje empujando a flash a su mercado de diseñadores graficos.

No creo que con los frameworks el desarrollador se haya decantado más a usar javascript que flash, o que discutiésemos más sobre como hacer llamadas con AJAX... Los frameworks quizás hagan un poco más llevadero trabajar con AJAX, quizás lo simplifican, pero no son los que han posibilitado su uso. Estoy de acuerdo contigo en que los FW han revitalizado el lenguaje algo, pero no creo que sean la piedra angular del desarrollador web.

Iniciado por caricatos

Nadie duda de lo valioso que puedan ser los frameworks, pero no creo que sean tan fáciles de aprender y usar... en concreto, un número importante de preguntas sin respuesta en estos foros son las que se refieren a soluciones con los frameworks... ¿o será que los que aprenden algo de ellos no están dispuestos a compartir sus conocimientos?

Totalmente de acuerdo, una vez tienes el lenguaje claro, meterte con la sintaxis rebuscada y acomodarse a la manera de trabajar de un framework puede ser árduo. Las preguntas sin respuesta acerca de frameworks en el foro probablemente se puedan responder sin la ayuda de dicho FW, como puede ocurrir en este reciente tema: http://www.forosdelweb.com/f13/mostr...0/#post2219950, y quizás el pedir a que la sintaxis sea la de mootools en una tarea a simple vista tan trivial impide que algunos usuarios puedan (podamos) responder como se espera.



Aquí otra duda, ¿el experto debe saber trabajar tanto con prototype como con jquery, mootools, yahoo, moo.fx, script.aculo.us, dojo...? ¿Cómo funciona esto de aunar programadores fácilmente bajo una misma librería si existen ya decenas de FW y no se pueden saber todos? En los tablones de anuncios dejarán de escribir "Se necesita programador javascript" para escribir "Se necesita programador en dojo"?



Un saludo

[caricatos]

Iniciado por derkenuke

Pues sinceramente, si es una propuesta para un desafío la veo tan complicada de abordar desde un principio que si ya obtenemos poca participación en validar un formulario, no quiero ni pensar en un proyecto mixto de esas envergaduras...

Un saludo

¡Je, je!

Será que me gustaría ver otro duelo..., y no sabía que los FW pudieran implementar un drag'n drop... ¡con lo que nos costó mover imágenes en este tema: Arrastrar objetos!, y los que manejan FW's no dijeron ni mu ...

Por mi parte, voy a ver si hago uno (esas cosas "complicadillas" me entusiasman)

Saludos

[Ismail al-yahoo]

Iniciado por caricatos

Nadie duda de lo valioso que puedan ser los frameworks, pero no creo que sean tan fáciles de aprender y usar... en concreto, un número importante de preguntas sin respuesta en estos foros son las que se refieren a soluciones con los frameworks... ¿o será que los que aprenden algo de ellos no están dispuestos a compartir sus conocimientos?

Un framework no es complejo de aprender, menos si conoces bien javascript, pero algo es indudable, es un queso tratar de aprender a usarlos todos o un poco de varios no sirve de mucho. Decidirse resulta un quebradero de cabeza y es lo que mas molesta del uso de frameworks, y una vez que te decides es como el matrimonio, al poco tiempo de uso ya empiezas a mirar para el lado.

Y aunque defienda los frameworks esta claro que saber manejar un framework js sin saber js es de dudosa utilidad, es como conducir un vehiculo y no saber siquiera cambiar una rueda. El lado oscuro de los frameworks, debe ser ese, que los nuevos desarrolladores entran de cabeza a ellos sin saber como estan hechos, como funcionan ni los fundamentos de javascript y tenemos entonces una generacion de usuarios de framework en ves de programadores capaces de sacar problemas como vengan y no solamente si el framework lo contempla.



Competir haciendo objetos drag&drop es una contienda demasiado desigual, ya que para hacer dragable un objeto del HTML con jQuery basta bajar el plugin de jQuery.UI y escribir esta linea:

$("#idDeLoQueQuierasMover").draggable();

Asi todo se vuelve muy facil y rapido . Supongo que hacer que un objeto se mueva con el cursor debe ser un parto con js puro. y droppable peor aun

[Ismail al-yahoo]

Y antes de saber cuales frameworks prefieren mi duda es porque los prefieren.


¿cuales son las caracteristicas que debemos buscar en un framework?



las cosas que yo busque fueron:

- Peso del framework.
- Que los complementos se utilicen de manera modular (no tener que cargar todo para usar el 5%)
- Que sea facil de extender (Ningun FW cubre todas las necesidades y si no es ampliando el FW solo lo estas parchando)
- Que me permita acceder y modificar el documento con poco codigo y en forma legible
- Amplia variedad de plugins (como grillas de datos, drag&drop, etc.) y que la cantidad (y calidad) de estos crezcan en el tiempo. O sea, que la comunidad al rededor de ese FW este viva y no moribunda, o durmiendo en los laureles.
- Que el usuario final no note la diferencia de velocidad entre el fw y js puro.
- Que no tenga que mezclar codigo en el HTML


¿que mas? ¿que cosas buscan ustedes?