{8} Comentarios.

1. 

   Jordi Rivero

   28Mar2011/

   Un articulo excelente Carlos.

   Me gustaría puntualizar algo. Un proyecto pequeño, tendrá necesidades pequeñas, fácilmente, muchos recursos para desperdiciar y sobretodo, poco DOM para parsear. Es decir, tendrás pocos problemas sobrecargando con jquery.

   En mi opinión, más bien són los proyectos grandes con grandes exigencias los que te hacen pararte a optimizar quitando lo innecesario o bien los que de inicio tienen pocos recursos que ofrecer, como por ejemplo las plataformas moviles.

   De todas formas, de inicio esta claro que mejor recurrir a lo minimo necesario 🙂

   Al margen, me gusta mucho la filosofía de zepto y me encantaría que jquery la aplicase, además, me gustaría que cambiasen el sizzle por el qwery 😛

   Un saludo!

   • 

     Carlos Benítez

     28Mar2011/

     Completamente de acuerdo en cuanto a que un proyecto pequeño tendrá exigencias pequeñas. Sin embargo, la idea es como bien dices, conocer las opciones más adecuadas para cada caso.

     Yo por ejemplo, siempre incluía jQuery por defecto en mis trabajos, hasta que empecé a encontrarme con problemas en móviles y en videoconsolas (PlayStation 3 se pega con jQuery). Desde entonces, me puse a investigar otras alternativas no solo para aquellos proyectos exigentes sino también para los más modestos. Pero está claro que es en el campo de los móviles donde más se agradece el cambio.

     Y seguramente John Resig le esté echando ya un vistazo a Qwery para optimizar aún más su Sizzle; la siguiente versión vendrá con 10Kbs menos 🙂
     Saludos!
2. 

   JuniHH

   29Mar2011/

   Varios amigos y mi jefe me dicen que debería probar con jQuery, que ofrece muchas ventajas y evita escribir código extra, que evito los haladera de cabellos cuando un script no funciona con IE6-7, entre otras cosas y aunque tienen razón, la verdad aún no le encuentro la vuelta precisamente por lo mismo que te llevó a escribir este artículo: Rendimiento de carga de jQuery u otros.

   Aún escribo mi propio código y la verdad me siento bastante cómodo porque me garantiza cargas livianas en mis páginas, independientemente a que el servidor las comprima. También me aseguro de usar los minifier’s, porque tiendo a usar muchos comentarios y espacios.

   Ya que varios de los ejemplos que pusiste eran para colección de tags, comparto una de mis funciones para lo mismo. Si no quiero hacer una colección general de todos los elementos sino de casos específicos, aplico una clase a cada objeto aunque sea de forma simbólica y filtro estos con la función (además es liviano):

   var clsFltr = function (id,tg,cl)
   {
   	if ( !document.getElementById(id) ) return;
   	
   	var obAll = document.getElementById(id).getElementsByTagName(tg), obCn = obAll.length;
   	var obs = [], obsNx = 0;
   	
   	for (var x = 0; x < obCn; x++)
   	{
   		if (String(obAll[x].className).indexOf(cl) != -1)
   		{
   			obs[obsNx] = obAll[x];
   			obsNx ++;
   		};
   	};
   	
   	return obs;
   };
   

   Por otro lado, encontré este blog recientemente desde un link en Twitter y ya forma parte de mis lecturas favoritas. El sábado pasado duré toda la mañana deborando artículos viejos. Muchas felicidades Carlos, haces un gran trabajo acá.

   • 

     Carlos Benítez

     29Mar2011/

     Hola!
     Es cierto que las librerías suponen una pequeña penalización a la hora de cargar una página pero también lo es que suelen ofrecer soporte multinavegador para todos aquellos métodos que implementan. Eso es un tema muy interesante que nos puede ahorrar muchos quebraderos de cabeza como bien comentas. Al final, siempre tememos que sopesar los pros y contras dependiendo de la funcionalidad que queramos incluir en un proyecto.

     Sin embargo, otra cosa que tenemos que medir es el rendimiento de aquellas funciones que nosotros implementemos a mano frente a las que ofrecen estas librerías. La función que has compartido puede, por ejemplo, hacerse un poco más rápida cambiando el modo en que se recorre el array de elementos encontrados, evitando la declaración de algunas variables intermedias que no son necesarias y omitiendo el CAST:

     var clsFltr = function (id, tg, cl){
     	if ( !document.getElementById( id ) ) return;
     
     	var obAll = document.getElementById( id ).getElementsByTagName( tg ), obCn = obAll.length;
     	var obs = [];
     
     	while(obCn--){
     		if (obAll[ obCn ].className.indexOf( cl ) != -1){
     			obs.push( obAll[ obCn ] );
     		}
     	}
     
     	return obs;
     };
     

     Utilizando un ‘reverse loop‘ que para este caso funciona bien, evitamos declarar ‘x’ e incrementamos notablemente el rendimiento para conjuntos grandes.
     El método ‘push’ también evita al intérprete el cálculo de la asignación directa del índice en el array ‘obs’.
     Finalmente, eliminando el CAST String, evitamos la comprobación de tipos interna.

     Y con eso, pues tenemos nuestras necesidades, tanto de funcionalidad como de rendimiento, cubiertas 🙂
     Gracias a ti por leer este blog y por compartir con nosotros tu comentario.

     Un saludo!
3. 

   Diego

   17Jun2014/

   El último ejemplo:

   var myLayer = $(‘#myLayer’);
   addEventListener( myLayer, ‘click’, function(){
   // Do something awesome here…
   })

   ¿no debería ser?:

   var myLayer = $(‘#myLayer’);
   addMyEvent( myLayer, ‘click’, function(){
   // Do something awesome here…
   })

   En caso contrario, pido disculpas 🙂

   • 

     Carlos Benítez

     20Jun2014/

     Tienes razón; corrijo el ejemplo.

     Gracias!
4. 

   Jose

   08Dic2016/

   exelente articulo, es un poco liado si te acostumbraste mucho a jquery por que sempre esta actualizado y tiene cosas novedosas, pero como dices para muchos proyectos no es tan necesario
5. 

   Jose

   10Ene2017/

   Me gusto mucho el articulo, sobre todo porque en muchos casos no necesitamos mas que algunos eventos simples, ¿tienes algún link donde puedo aprender mas sobre javascript?
   ya no quiero depender de librerías 🙂