La Guerra de los FW - JS

[Calisco]

Realmente esto continuamente va a traer controversias, plantear un desafío, etc. Va a ser difícil que todos nos contentemos; pero no tenemos que perder la idea fundamental de esta competencia.
Solucionar problemas específicos con distintos FramWorks y también con JS puro.
La idea es hacer varios desafíos ... donde en cada caso, entre las distintas conclusiones que se puedan sacar, veremos cuando, donde y como es preferible utilizar o no un frameWork. O sea, todo es muy experimental por lo tanto va a traer un cierto caos a la hora calificar los resultados.
La diversión está asegurada.

[caricatos]

Hola:

Plantear algo será siempre un problema, pero se pueden hacer tantas cosas que sería cuestión de plantear un reto cada semana (por ejemplo)... y si resolver un sudoku no parece adecuado para comenzar, puede dejarse para el futuro... yo también podría proponer "la máquina de Turing" (¡Jé! ya la tengo hecha...) pero creo que todos estamos de acuerdo en que tenemos que pasarlo bien, y si es posible aprender... creo que es una buena forma para los que no usamos librerías, de ver los resultados que se consiguen con su uso, y el nivel de dificultad que pueden tener...

Creo que una de las cosas más importante de javascript son las validaciones, así que puede ser una de las primeras pruebas; y para los comienzos plantear cosas muy básicas para calentar motores, como precargas, rollovers, tooltips... también pueden interesar efectos gráficos como transiciones...

Saludos

[Holden]

Totalmente de acuerdo con vos Caricatos... igual el sodoku me tiene "on fire" y estoy tirando los primeros bosquejos je je je...
Salgamos con las trivialidades y las cosas mas preguntadas en los foros que sin dudas son las que nombraste tambien agregaría el tema de los combos dependientes. Altamente solicitado.

[Calisco]

Exactamente. Tenemos que arrancar con algo sencillito. Hasta un mismo desafío se puede ir incrementando en complejidad. Por ejemplo, yo estaba pensando en una calculadora sin usar elementos de formulario. Pienso en esto para el manejo de eventos.
Una calculadora en una página, que cuando la actives el browser sólo responda a la misma. La página debería contar con otros elementos de formularios para demostrar que al usar la calculadora no podamos ingresar valores a estos elementos.
Como para arrancar, no se ...

[AlZuwaga]

Hola, sólo por proponer, ¿qué tal una máquina expendedora de boletos de colectivo (ómnibus)?
Podría incorporar bastante en eventos y al mismo tiempo lleva un poco de programación.

Monedas que acepta: 0.05, 0.10, 0.25, 0.50, 1.0
Valores de los boletos: 0.75, 0.80, 1.0, 1.25

Las máquinas están cargadas inicialmente con:
50 monedas de 0.05
25 monedas de 0.10
10 monedas de 0.25
5 monedas de 0.50
0 monedas de 1.0

Debe dar la menor cantidad de monedas posibles al dar el vuelto.
Debe indicar si el pago debe ser exacto ante la imposibilidad de dar vuelto.

Qué les parece?

[Shiryu_Libra]

orale, definitivamente esta pelicula tendra un giro muy bueno cuando el director diga

ACCION!!!!

[derkenuke]

Me parece muy bonito Al Zuwaga, me gusta mucho la idea y me pondría a desarrollarla ahora mismo (más que nada porque yo soy así). Pero ¿qué aplicaciones prácticas puede tener eso en una página web normal y corriente? No encuentro ningún proyecto pragmático que haya tenido que implementar algo similar.


Y respecto a empezar con algo como validaciones y tal... igual se queda corto. Tal vez queramos que en un campo solo existan números, y en un framework exista el típico

Código PHP:

  campo.onkeypress = onlynumbers; 
formulario.onsubmit = submitonlynumbers;  
   

Y ahí ya habría acabado su ejercicio...
¿tendría ésto algún sentido salvo comprobar rendimientos?

• Líneas de código de un equipo: 2+onlynumbers+submitonlynumbers=100
• Líneas de código de otro equipo: 50
• Horas de trabajo de un equipo: 1min
• Horas de trabajo del otro equipo: 2 horas
• crossbrowser de un equipo: si
• crossbrowser del otro equipo: si

¿Y llegaríamos a alguna conclusión? Lo que pasa es que muchos FW ya tienen implementado métodos como esos... no sé yo si haciendo algo tan "básico" llegamos a algo... Aunque no tengo ni idea de lo que está implementado y lo que no... me puedo hacer una idea (estoy desinformado de esto, aviso).

Esto lo comento para las ideas de precargas, rollovers, tooltips que comentabas caricatos. Incluso cosas como menús en árbol, drag & drop, y selects dependientes seguro que ya se pueden incluir en un proyecto con 10 líneas de código y un framework.


---


Otro asunto que se me ocurre es si en el FW no está implementado. Ejemplo: Quiero un campo que sólo admita números y que en el quinto carácter haya una vocal cualquiera opcionalmente. ¿Qué se hace en esos casos trabajando con FWs? ¿replantear el tema y programarlo en a pelo? ¿o añadir una función al fw?


En fin, tengo muchas lagunas..

[Calisco]

Nos vamos tener que poner de acuerdo, de alguna manera u otra. Vamos a hacer un listado de los desafíos propuestos y haremos una encuesta.

[Holden]

Me parece que se pueden hacer cosas interesantes con las validaciones desde ui hasta usabilidad...
No creo que sea algo tan acotado.

Mi validador tiene las cosas triviales...
Validar.Email, Validar.Fecha, Validar.Entero, Validar.Vacio etc etc etc
Me gustaría extender funcionalidades y dar mecanismo para serverside (ajax) para validar por ejemplo si un username esta disponible o custom validations usando un mecanismo unificado e inteligible de forma tal que si queremos que ingresen un codigo unico tributario podamos adherir esa validación en forma sencilla sin tener que agregarla al toolkit como validación trivial.


A mi el validador me interesa y el "cosito ese de acomodar números" (el sodoku :P) tambien me interesa.
Por lo cual doy mi voto para incluir esos dos temas.

[Calisco]

OK ... empezamos a hacer un listado entonces ...

[MaBoRaK]

loading............


Y la guerra????... come on!!!!!
VIVA LA GUERRA!!!!!!

.... de FW Vs Javascript nada más :D

comenzemos no?.... javascriptEROS atacamos primero? :D


connection closed.

[Shiryu_Libra]

quiero ver sangre!!!
a mi no me mueven de este lugar
aganse a un la'o que quiero mirar sin estorbos



suerte para todos

[derkenuke]

Una idea que se me ha ocurrido... sólo se me ocurrió ayer, no sé lo buena que podrá ser.

Se da una sopa de letras y una lista de palabras a buscar en la sopa de letras, y el programa tendrá que encontrar cada palabra de la lista en la sopa de letras y marcarla.

No sé si tendrá mucho de sudoku (cálculo) y tal. Aplicación práctica pues.. enfin, pero sí que se trabaja con la presentación de la sopa de letras, con los cálculos de arrays, con navegación por el DOM...


Sería bonito, pero me gustaría ver vuestras opiniones.



Bueno, un saludo.

(Por otra parte se me ha ocurrido que igual es un poco complicadilla la coordinación entre los componentes de los equipos... no había pensado en ello).

[Calisco]

Nadie dijo que los integrantes debían coordinarse y realizar un sólo script por FrameWork. Creo que eso sería un poco complicado. Sin embargo ..., si quieren hacerlo bienvenido sea.
Saludos.

[Fridureiks]

Yo creo que las pruebas se deberian realizar con tareas algo mas 'cotidianas'.

Validacion de formularios.
Algunos efectos
Drag drop
Ajax
.etc

Una vez hechas las pruebas de cada bando y/o participante, comparar tiempos de carga, memoria, los distintos navegadores, claridad del codigo, peso kb del script, etc

Ya me diran... Claro!! asi es mas facil para los que usan FW!! Justamente un FW se supone que tiene herramientas para facilitar la solucion de aquellos problemas que se presentan todo el tiempo. Sodokus y similares, dejenlo para ejercicios con algoritmos y demas.... un framework no mostrara su potencial con algunos calculos ademas de que seria totalmente inutil cargar una libreria solo para realizar operaciones basicas.

Saludos

[derkenuke]

Entonces no hay conclusiones que sacar, con un framework es instantáneo, y sin framework te puedes tirar días haciéndolo.

La diferencia es que aprendes más y tienes control de cada línea de tu código, y con el framework no.

¿Tiene sentido que yo me ponga a desarrollar un drag & drop si en el framework se hace con dos lineas y yo me tiro dos días? Las conclusiones ahí ya vienen dadas, ¿no?

[Fridureiks]

Yo coincido con lo que decís. Quizas agregaria algunas cosas

Iniciado por derkenuke

Entonces no hay conclusiones que sacar, con un framework es instantáneo, y sin framework te puedes tirar días haciéndolo.

Como todo tiene sus pro y sus contras, dependiendo del framework es probable que el codigo(de la libreria) sea mas pesado en kb que lo que tu hagas.

Iniciado por derkenuke

La diferencia es que aprendes más y tienes control de cada línea de tu código, y con el framework no.

Seguramente. El detalle que no estas teniendo en cuenta es que el FW no esta hecho para que cada quien lo modifique a su gusto (salvo que tengas ganas), esta hecho para que lo uses. En caso de haber problemas, existe una comunidad detras en la cual seguro ya alguien paso por tu mismo problema.

Lo de aprender mas no te lo discuto, el FW oculta mucho del trabajo mas arduo. Pero quien ya sabe javascript o a quien no le interesa saber cada detalle de javascript no tendra inconvenientes con este punto.


Y agrego:

Si estas en un grupo de trabajo en el cual sale y entra gente todo el tiempo, es mas probable que encuentres gente que domine prototype a gente que domine la libreria que vos mismo has creado.... porque quiero creer que librerias propias si usan, no? o como trabajan?


Una prueba de rendimiento seria buenisimo, verdaderamente podriamos ver si en el uso de FW pesan mas las contras o los pros.

Saludos

[Calisco]

En parte coincido con lo que dice derkenuke. Ya tenemos conclusiones antes de lanzar un desafío. Es simple: es casi imposible definir un desafío que sea parejo ... porque dependiendo de lo que queramos implementar será parcial para una u otra herramienta.

Entonces ... que hacemos ?. Pienso que hay que hacer varios desafíos y analizar en conjunto. Arrancamos el lunes.

[derkenuke]

Iniciado por Fridureiks

Como todo tiene sus pro y sus contras, dependiendo del framework es probable que el codigo(de la libreria) sea mas pesado en kb que lo que tu hagas.

Podemos tener en el servidor la librería comprimida, sin espacios, y los nombres de variables reducidos a caracteres del alfabeto, el tamaño en kb se reduce un montón..

Como contrapunto: ¿Quién que programe javascript (incluso en FWs) no ha comentado sus códigos, espaciado tres veces seguidas... etc para hacerlo más legible? Porque podríamos comprimir también nuestros códigos propios.. pero ¿quién lo hace?
Además, ¿qué son 10kb contra 50kb en una línea ADSL actual? El tiempo de espera mayor se lo lleva la petición al servidor, no el tiempo de descarga...

Iniciado por Fridureiks

Una prueba de rendimiento seria buenisimo, verdaderamente podriamos ver si en el uso de FW pesan mas las contras o los pros.

Y hablando de rendimiento... por el bien de la librería espero no saber/poder hacer una función más óptima que las implementadas ahí. Perdería mucha confianza en ellas. Se supone que están requetepensadas, ¿no?

Iniciado por Fridureiks

Si estas en un grupo de trabajo en el cual sale y entra gente todo el tiempo, es mas probable que encuentres gente que domine prototype a gente que domine la libreria que vos mismo has creado.... porque quiero creer que librerias propias si usan, no? o como trabajan?

Eso no te lo discuto, es cuestión de números y de probabilidades. La masa manda.

Iniciado por Calisco

Entonces ... que hacemos ?. Pienso que hay que hacer varios desafíos y analizar en conjunto. Arrancamos el lunes.

No lo sé compañero, vuelvo a estar en blanco de nuevo. Probablemente perdamos el tiempo implementando drag & drops, pero ¡qué demonios, estoy de vacaciones y me divierte!

[Calisco]

JAJAJA ... valla vacaciones las tuyas. Las mias no son muy distintas.
Saludos.

[caricatos]

Hola:

Estoy de acuerdo en comenzar el lunes, pero aún no está la cosa muy madurada

También se puede saber que hacen algunas primitivas de las librerías, e implementarlas sin ellas (incluso ir haciendo una especie de "depósito").

Para ir proponiendo cosillas básicas, se me ocurren: rolloveres, precargas, tooltips, validaciones... incluso ayudarnos de ajax...
También como cosas algo más avanzadas, un calendario, galerías de imágenes, sistemas de transiciones...

Todos estos temas los he tocado en alguna ocasión, pero se pueden matizar como para obligarnos a empezar desde cero.

Saludos

[Holden]

Como tuve un par de horas libres, aproveché a avanzar con algo que me interesó demás esta decir que por el momento es una versión alpha no llega ni a beta :D.

http://www.hvaldez.com.ar/sudoku/

Nota: tal como inicialmente dije, no se puede sacar mucho provecho de los frameworks, salvo que armemos UIs complejas con animaciones, fading etc. Pero deja de tener la importancia el resolvedor...

[derkenuke]

Iniciado por caricatos

rolloveres, precargas, tooltips, validaciones... incluso ayudarnos de ajax...
También como cosas algo más avanzadas, un calendario, galerías de imágenes, sistemas de transiciones...

¿Dos selects con elementos intercambiables haciendo drag & drop?
¿Una lista lista/tabla que se puedan ordenar los registros con drag & drop?

Tormenta de ideas que se me van ocurriendo... ¿qué hacemos para escoger el primer reto? ¿Una lista porque los vamos a hacer todos? ¿Cuánto tiempo por reto? ¿Abierto siempre?

[Calisco]

Iniciado por Holden

Nota: tal como inicialmente dije, no se puede sacar mucho provecho de los frameworks, salvo que armemos UIs complejas con animaciones, fading etc. Pero deja de tener la importancia el resolvedor...

La idea fundamental es clarificar esto de que si JS es mejor o peor que un FW, o cuan difícil es implementar un script, o consumo de memoria, tiempo de ejecución , etc. Si uno puede desarrollar los desafíos con un FW sin moverse un pelo ... eso es una conclusión concreta que nos ayudará a tomar mejor las decisiones a la hora de desarrollar.
De todas formas ... en la cancha se ven los pingos. Lo mejor va a ser arrancar el lunes con cosas básicas como dice Caricatos ... y de a poquito ir dando complejidad y variedad al asunto.
Saludos.

[Calisco]

Bueno ... ahi puse 4 scripts propuestos. Votemos con cual arrancamos.
Saludos.

[Calisco]

Al confeccionar la lista ... pensaba que ejemplos concretos podía agregar y no se me ocurría nada. Digamos ... estaba como buscando agua en el medio del mar. Porque ?. Amigos ... tenemos alrededor nuestro miles de preguntas sin respuesta. A veces, al leer estos post, me digo a mi mismo ... con mootools sería tan sencillo.
Que les parece hacer esto: agarramos alguna pregunta que sea digna de desafiar y la implementamos, en ese post, con la técnica que queramos. Por otro lado, los desafíos también los hacemos.

Este es un listado de los ultimos posts al momento.

• No funciona una simple linea????
• Dimensionar ventana (por ejemplo 300X400 px)
• Ha dejado de funcionar el boxover
• Validacion de campos : 1 Boton typo Imagen 2 Bot submit
• onclick tiene que esperar en IE para ejecutarse otra vez
• Redimensionar arrays dinámicamente.
• Problemas con fechas
• como se puede limpiar los valores de una matriz

[derkenuke]

Bueno, ya casi estamos a martes y aquí no se ha empezado nada.

Propongo también hacer un tres en raya, como los compañeros de PHP.

Habría que empezar con algo sencillo, una validación de formularios, pero si la hacemos habría que disponer de un enunciado, y ponernos en serio ya

[Holden]

El post enumera algunas alternativas... creo que quien desea ya puede comenzar con algo...
Yo por mi parte veré como terminar de resolver mi sodoku.

[Calisco]

Bueno, arrancamos con una validación de formulario. Yo tengo poca idea de implementarlo, ya que casi siempre valido en el server. Pero algo se nos va ocurrir. Utlizar máscaras pra las fechas, pra telefonos, DNI, etc ...
Saludos.

[MaBoRaK]

loading............


Quien será el Coordinador? porque sin un coordinador esto se vá... como tiro al aire.


connection closed.