Foros del web, para los que viven de bits

Conozco 2 librerias JS muy completas y conocidas, y queria saber cual usa mas la gente.

Yo personalmente utilizo en el trabajo y en casa Prototype (junto a Scriptaculous).

Dado que Prototype y Mootools tienen ya sus propios Cores definidos, tengo entendido que no son compatibles entre sí, que no se pueden usar las 2 en una misma página porque entrarían en conflicto.

Las webs oficiales:

Prototype: www.prototypejs.org
Mootools: www.mootools.net

Prototype y jquery principalmente. Voy a mirar mootools...

Hola:

Apenas he curioseado alguna de ellas, y me parecen bastante complejas para las situaciones normales... y dudo que sean necesarias cosas complejas en las páginas web...

Saludos

Recientemente he comenzado a usar mootools y me facilita algunas acciones.
Por otro lado he leído que Amazon utiliza prototype, y debe tener alguna razón para hacerlo (no puedo incluir el link a la página mildiez.net).

Caricatos ... realmente has Apenas he curioseado alguna de ellas; ya que es justamente lo opuesto a bastante complejas para las situaciones normales.
Personalmente nunca dediqué mucho tiempo a programar del lado del cliente; pero por cuestiones del destino tuve que agarrar el toro por las astas. Con JS el toro me saco punteando ... si no fuese por mootools tendría que preocuparme por problemas de compatibilidad entre browsers, la implementación de clases, los efectos y cosas que ni siquiera conozco ...
Con los frameworks de javascript se abre una nuevo nivel de programación; un poco mas alto pero tanto o más potente que el base. Y fijate y acordate ... con las nuevas versiones de JS (creo que ahora sale la 1.8) funciones que antes eran ejecutadas por los FWs ahora lo harán en forma nativa; un ejemplo de esto es getElementByClassName, donde el tiempo de respuesta es increíblemente mas rápido.
Es un cambio que hay que aceptar ... un tren que hay que tomar; ya sea mootools, jquery, prototype, dojo, etc ...

mount ... tampoco deberías ser influyente la calidad de un FW si es o no es utilizado en Amazon. Mootools es utilizado en Ubuntu, CNet, y otras más ... Eso a mi no me dice nada.
Saludos...

Creo que es preferible aprender a programar que utilizar librerias de funciones ya hechas. ,pueden estar bien. ,pero para quien las conoce, y son tan extensas que se hacen aun menos atractivas.

Aconsejo ,eso si, crear las propias, unica forma de expandir el leguaje ,compartir, enseñar y aprender.

Salud os

Tu consejo no es siempre absoluto.
A veces es mejor aprender a utilizar las funciones ya hechas ... y a veces no.
Hagamos una apuesta:
Que alguien dicte una tarea ... vos la implementas con JS y yo con MooTools. Nos damos el plano de un día. Al final vemos las ventajas y desventajas. Una de las cosas que deberíamos hacer es medir el tiempo de respuesta de los scritps, el consumo de memoria (no se como medirlo, pero supongo que se puede hacer), lineas de código entre otras cosas.
Habría que medir muchas otras cosas más que a simple vista no son tan ... como decirlo ... visibles.
Estoy seguro que la revolución de la web 2.0 y las nuevas técnicas de programación y el concepto de aplicación web no sería tan arrastrante en los últimos tiempos si no fuese principalmente por ajax y los frameworks. Si no ... hace memoria 2 años atrás ... hay una tendencia evolutiva y es gracias a los FW.

no lo puedo creer una competencia

de aki no me muevo

Muy bien, como dices

lo cual significa que has tenido que aprender a manejar MooTools, los nombres y sintaxis de sus funciones etc..., lo que no dudo que te ha tenido que llevar largo tiempo. Cosa esta, que es comparable al programador que usa sus propias librerias ,las cuales a ido fabricando o adaptando conforme aprendia. ,de esta forma se crean programadores conocedores del lenguaje de la otra no se exactamente que aprenderian ,bueno si, otro lenguaje de programacion.

Ahora para ser justos, propongo otra cosa, que sea un neofito el que se eche a la espalda esa libreria y que otro novel lo haga con javascript puro. Por supuesto, la tarea no puede estar pensada para favorecer las prefunciones de Mootools.

Dudo que nadie quiera aprender a manejar una libreria solo para hacer una tarea.

Esas librerias pueden ser utiles ,para el que las hace o para el que las estudia, pero dejar de hacer javascript y encasillarse con una serie de funciones prefabricadas, que por supuesto, no lo abarcan todo. ,no me parece buena idea, sobre todo para los principiantes.

Salud os.

Me parece que estas subestimando el potencial de los frameworks. Aclaremos de antemano que ambos pueden coexistir. Me parece que en general tu idea es claro y válida, pero este no es el caso. Estamos metidos en una transición evolutiva donde JS se va a adaptar a los cambios que hoy por hoy están proponiendo los FrameWorks. JS va a evolucionar para donde los FrameWors manden.
Antes cité getElementByClassName. Esto en FF3 ya es un hecho. Funciones como dollar $() o doble dollar $$() tarde a temprano van a estar soportadas en forma nativa por los Browsers.

Y al final de cuentas ... es una cuestión de elección a que apunta uno como programador. Es como Linux. Yo soy usuario de Ubuntu y lo utilizo solo como plataforma que me permita programar mis cositas. Me desentiendo de la versión del Kernel, de las mejoras, etc ... yo estoy en otro nivel. Soy un usuario.

Con los FrameWorks pasa lo mismo. Para vos tal vez sea mejor no utilizar ninguno e implementar tus scripts de la forma mas baja que JS te lo permita. Eso no quita que un usuario que utiliza un FrameWork pueda desarrolar un sitio web con un buen funcionamiento tan bien o mejor estructurado del que pueda hacer alguien que no lo utilizara ...

Te hago este planteo:
Un programador de medio pelo ... hace un sitio web en forma sencilla mediante un FW. El resultado final es muy bueno, con rutinas compatibles con todos los browsers, buen rendimiento, que valida bajo W3C; ... y lo ha realizado sólo.
Donde está el punto en contra ?

Me podrías contestar que alguien tuvo que hacer ese framework, que quien lo utiliza depende de otros programadores. Vos no ?. Salvo que seas el creador de JavaScript vas a tener que adaptarte a las continuas modificaciones que esta sometido.
No soy bobo ... entiendo perfectamente lo que decis ... y en parte estoy muy de acuerdo. Pero con el tiempo creo que encerrarse a veces es contra productivo.
Es como negar que un sistema operativo windows no revolucionó el uso de las computadoras. Hoy por hoy tenes miles de SO con entorno windows ... y también lo tenes bajo linea de comandos. Lo importante es poder elegir.

Y cierro con esto: La evolución de JS y el rol que tiene actualmente es principalmente por culpa de los framWorks. Cual están actualmente las películas en Flash ?

Yo personalmente soy partidario de programar "a pelo". Los framework me obligan a aprenderme nuevas funciones, y me ciegan un poco la mente. Además suelen proponer una única manera de hacer las cosas. Otro punto en contra es tener funciones que no necesito junto con las que necesito.

Dentro de poco pasará que conoceremos $() pero no sabremos lo que es document.getElementById(), y peor aún, ya ni nos sonará document.


Opino que ese tipo de librerías están bien para ahorrarse tiempo en programar algo fiable, pero sirven para desarrollarse en javascript como un cursillo de 1000 palabras sirve para aprender inglés. Al final siempre sale la duda de: ¿Y si quiero esto pero en color azul, qué tengo que cambiar?


Y no me gustaría que la evolución de js la marquen las framework, la tendrían que marcar las necesidades del programador. Adaptar un navegador a las framework que rondan por ahí distanciaría más uno de otros y habría una batalla campal por los estándares. ¿ $() estándar ? Espero que no, nunca ha sido explicativa por si misma como lo es cualquier propiedad / función de javascript.


Pero... ¿sabrá javascript? ¿Hace él la web o como ve un efecto acordeón en el FW lo coloca en su página? Es probable que únicamente haga lo que su FW le permita, y que si conocía javascript, lo irá olvidando. Algo parecido pasa con los CMS.


Un saludo.

Hola:

Pasa en todos los lenguajes de programación, que puedes crear programas de cualquier índole... y posiblemente muy bonitos y funcionales, pero si se quiere depurar algún módulo para mejorar la velocidad o cualquier posible mejora hay que bajarse al ensamblador, o incluso más abajo: al código máquina.

Hacer una librería propia es una idea que creo que todos hacemos... una función que siempre uso, y para poner un ejemplo:

function tag(id) {
return document.getElementById(id);
}

Espero que lo de competencia siga en pie...

Calisco: verás, en estos foros estamos viendo que se hacen muchas preguntas y prácticamente todas las respuestas se dan con javascript puro... ¿Qué te hace pensar que usando una librería vas a conseguir mejores resultados?

Saludos

Vamos por parte ...
Y cuál es el problema ?. Decime el punto negativo de esto ... si yo se que haciendo var miNodo = $('idDiv');.

Otra vez en desacuerdo. Trabajar con un FW no sifnifica que no puedas indagar con JS en los mismos scripts. Coexisten ... y son lo mismo. Ahora ... considero que los FW contrariamente a acotar al lenguaje hacen justamente lo contrario !!!.

Y que te pensas que hace un FW ?. Hace más fácil las necesidades e un programador; justamente los FW evolucionan al ritmo real de lo que los programadores piden ... cosa que JS también lo hace, pero a su ritmo.

Sabes como fue la historia de JavaScript ?. Como fue evolucionando versión tras versión; el tironeo de los browsers ya que la compatibilidad nunca fue total. El Entandar se hace a los porrazos, siempre fue así. En su tiempo IE a voluntad propia manejaba el estandar; tenía cerca del 95% de la humanidad comprada. Hoy no puede; el entandar lo rige la W3C y la presión de los browsers.
Si FF3 implementa en forma nativa getElementByClassName ... veremos que dice W3C; seguro que lo acepta.

El albañil que pega ladrillos ... hace la mezcla con cemento, cal, arena y agua. Sabe el proceso de construcción del cemento o de la Cal ?. Sabe que el agua es el elemento que desatará la tercer guerra mundial ?. No, el pega ladrillos.
Vos sabes como los punteros y acumuladores trabajan con JS ?, como mapea la memoria RAM; sabes la corriente que consume asignar una direccion por el bus de direcciones ?. No. No te importa. Vos programas en JS.
Sabe el que usa un FW que es lo mismo que getElementById ?. NO. YYYYY ???
Si esa persona puede desarrollar mejor que vos, mas eficientemente ... entonces, donde el problema ?.
Estamos hablando de tareas distintas. Gente que piensa como vos hace los FW para que los utilicen los usuarios. Eso va a evolucionar JS. Porque los FW son mas pretenciosos ... y los browsers van a ejecutar en forma nativa lo que hoy por hoy son funciones armadas ... y ahí vas a dejar de tener esa disyuntiva; $() y $$() va a ser tus funciónes perfectas porque formarán parte del conjunto de funciones propias de JS.

No es algo que piense yo Caricatos ... es algo que está ocurriendo alrededor nuestro.
Hace un recuento de los post del foro de JS. EL 95% de los post son 'drag de div, no se mueve !!!', 'menu con li anda en IE pero no en FF !!!', etc, etc, etc ... Cual es la solución a eso ?. Un buen FramWork.

Finalizando mi idea general:
JS no se va a perder, va a evolucionar. Los FramWorks van a tener mucho que ver. Toda evolución levanta polvareda. Aguante JS para los puristas, aguanten los FW para gente como yo ... que le hacen la vida más fácil.

Disculpen que sea insistente ... este tema me apasiona. Creo que estamos viviendo una revolución. Observen este gráfico:

Fijensé la diferencia de tiempos. El estudio se encuentra el hilo del blog de EJonh.
El estudio habla de tres técnicas de recorrido de los nodos html. DOM Puro, DOM Tree Walker y XPath. Miren los tiempos ... en forma nativa lo hace FF3. Por ejemplo prototype utiliza Xpath.
Que pasa si el día de mañana IE no ejecuta en forma nativa este método ?. Se jode, porque en estos tiempos la evolución no está regida por una cuestión de mercado si no por la comunidad mundial de programadores.
Saludos.

Lo que finalmente me ha llevado a decidirme por un FW ha sido que me asegura la compatibilidad con todos los navegadores.

Saludos

Para paginas normales no, pero para aplicaciones web puede ser util e incluso necesario para optimizarlas (repartir la carga entre cliente y servidor). Cada dia estamos viendo mas servicios o aplicaciones web por Internet, nadie negará que es un hecho.

Sobre si es mejor programar con el lenguaje nativo o usar framework: Yo solo digo que si en mi trabajo tuviera que programar todo en nativo, mi jefe estaría cada 2 x 3 riñéndome de porque tardo tanto en sacar adelante los proyectos. Los frameworks sirven principalmente para eso, para facilitarnos un poco la vida a los programadores. Hay rutinas o codigos que tenemos que recurrir a menudo, y en un proyecto grande vemos que se repiten mucho a veces estos codigos, los frameworks simplifica estos codigos, ademas de que nos aseguramos que es cross-browser.

Eso sí, si alguien no conoce javascript y aprende directamente un framework, puede ser un error. Lo ideal es conocer lo básico de js y utilizar FW. Y no hace falta que sean proyectos medio-grandes, una vez te acostumbras (como yo), las paginas sencillas salen enseguida.

Lo de crear uno su propio framework, bueno, si son cosas muy concretas y personalizadas me parece bien, pero para las cosas básicas y cuotidianas, si ya hay varios frameworks para usar, constantemente revisandose y utilizado por otros sitios, porque no usarlo? Asi, el tiempo que ganamos lo empleamos en mejorar los proyectos en vez de en "crear" lo que ya hay en realidad.

Añado:
Y sobre el mantenimiento del codigo? Los FW simplifican bastante el codigo y hace que cuando revisemos algo de hace 8 meses, nos sea menos "traumatico" entenderlo (en el caso de que no estuvierda documentado el codigo claro jeje)

Y sobre aprender desde cero un FW sin saber javascript... es como si alguien para un examen de mates se memoriza los problemas de clase en vez de entender como se hace. Ni un extremo ni otro :P

No ... sería como resolver problemas matemáticos sin saber la esencia de la misma. Algo asi como ... saber que si multiplas un número negativo por otro positivo da negativo; sin saber el porqué. O aplicar 2 al cubo es 2x2x2.
Respecto a realizar nosotros un FW;, yo me pongo en esta situación. No quiero desmerecer mi capacidad nu mucho menos, pero yo si me pongo a diseñar mi propio FW no hago lo que tengo que hacer; no trabajo ni vivo de esto y se me hace muy pesado. Por otro lado tenes un grupo de 30 programadores TODO el día depurando, optimizando, buscando el más minucioso detalle ... y yo jamás voy a poder llegar a un resultado similar. Esa es mi pura y cruel realidad.

Yo voto por mootools, sin lugar a dudas. Evidentemente para muchas cosas no es necesario mootools y se debe hacer directamente con javascript, pero para otras tantas se me hace muy necesario tener una libreria que me quite los dolores de cabeza que me provocan los distintos navegadores entre otras cosas.

Podria tener mi propia libreria, pero eso implica mucho tiempo escribiendo codigo, documentando, respondiendo por mis propios errores, compatibilidad con distintos navegadores y asi y todo dudo que algun dia pueda lograr tener tantas funcionalidades como una libreria armada por tantas personas.

Por otro lado es una manera de unificar un grupo de trabajo. Es mas probable encontrar 5 personas que dominen prototype que otras 5 que dominen la libreria que tu has creado.

Esta claro que no hablo de pequeñas cosas, no voy a incluir el fichero de mootools solo para evitarme el getElementBy...hablo de cuando es necesario crear funcionalidades que involucran mucho codigo y compatibilidad con distintos navegadores.


Un saludo.

Solo paso para votar, en lo personal utilizo Prototype, lo encuentro muy completo, y me ayuda a crear mis clases en Javascript de una forma mas sencilla, me ha servido en mis proyectos personales y en mi trabajo asi que no he mirado para otro lado, aparte lo encuentro rapido y no atasca el navegador (claro depende mucho del codigo JS que implementes).

Saludos.

hola

eh... no se que decir, .Una libreria de herramientas prefabricadas, listas para su uso? lo dudo.

Me ha interesado la grafica que muestra como cualquier libreria aumenta el tiempo de proceso, eso ya de por si, no dice nada de ellas.

Hay que sumarle, un tiempo de aprendizaje ,que alguien deberia aclarar ¿cuanto es?.

Tambien habria que saber, si javascript, es un paso obligado para el uso de estas librerias, o se pueden utilizar(despues de aprenderselas) sin dicho conocimiento.

caricatos. Ha dado en un punto muy importante, que indica claramente ,a quien van destinadas estas librerias. A gente que no tiene tiempo.

libreria al minuto:
conocimiento previo de javascript
mayor tiempo de proceso
tiempo de aprendizaje

javascript
¿conocimiento previo de programacion?
tiempo de aprendizaje con mas recursos
menor tiempo de proceso.

voy a dar por sentado, que tan mal programa puede ser, uno echo en javascript. ,como otro fabricado con MEGALIBRERIAS. ,o utilizando ambas dos.


como siempre, tal vez me equivoque, pero son gajes del oficio sin beneficio.