Contenido

Valerio Proietti (MooTools) opina sobre Sizzle

5 Dic

+ 7

Valerio Proietti, padre de MooTools, nos cuenta el por que NUNCA Sizzle será parte del código base de MooTools. Al contrario que la gente de Dojo que parece estar sopesando la idea de incluirlo como código de Dojo.

Entre los motivos que Valerio expone, me quedo con estos.

  1. El código que tienen actualmente es rápido y lo más importante, lo conocen. Imprescindible para el día a día.
  2. Los resultados de SlickSpeed se basan en la ejecución de 5 veces la selección lo que hace que el sistema de cacheo haga reducir los tiempos, «engañando» a los números.Lo mismo nos pasa con Peppy.
  3. La dinámica de trabajo de MooTools es incompatible con el código de Sizzle. Al parecer ya tienen una hoja de estilos a la que siguen a raja tabla y entrar ahora con Sizzle supondría un atraso.
  4. El código de Sizzle es realmente grande (cierto) y no ayuda a la reducción de peso que están planeando para la nueva versión.

Para demostrar que los resultados de Sizzle no son tan asombrosos como parecen, ha modificado el código de SlickSpeed para que las consultas se ejecuten una sola vez y además ha usado una versión modificada de MooTools que no devuelve los elementos extendidos para realizar la prueba con el selector de MooTools 1.2.1 y los resultados demuestran que la diferencia es inapreciable.

  • Es un placer leer el código de MooTools en general y en concreto el de módulo selector CSS. Echadle un vistazo a la fuente (como siempre recomiendo). No se puede decir lo mismo de Sizzle, producto ‘celebre’ gracias al tirón del nuevo palabro de moda, jQuery.Y es que todo lo que esté relacionado con este magnífico framework (eso es indiscutible) es superhipermegaguay, incluyendo cualquier aportación de su progenitor. Que curioso me resultó el post aquel en que «descubría» DocumentFragment y prometía optimizaciones gracias a su uso, seguido por un coro de laudatorios comentarios.

  • @Jose: Jose, hay que diferenciar MooTools de jQuery, son cosas diferentes y se hacen servir para cosas completamente diferentes.

    El que te guste el código más o menos es algo muy personal, a mi MooTools me gusta como está estructurado pero no lo considero la opción más acertada para el Javascript que necesito programar.

    El selector CSS Sizzle, está d.p.m. y eso no se lo puede quietar nadie. Valerio no lo quiere incorporar por los motivos que comenta, encambio la Dojo Company si que lo está barajando por otros motivos.

  • tambien hay que ir pensando que no dentro de mucho la mayoria de los navegadores tendran Selectors API y ya no sera tan importante la optimizacion en este aspecto.

  • Andrés, desde un punto de vista absolutamente objetivo ¿qué hace a Sizzle tan especial? Vamos a ver los criterios de comparación:

    1. Interfaz: todos los modulos dedicados a selección CSS presentan la misma interfaz: tomar un selector y devolver una lista de nodos. No es un criterio para comparar.
    2. Selectores soportados.
    3. Las diferencias en tiempos de ejecución (sin utilizar caches, por favor)
    4. Estructura y claridad del código.

    Pués eso, ¿por qué Sizzle es tan celebre?

    Por otra parte, por supuesto que jQuery y MooTools no son totalmente comparables. Como otras veces he comentado, jQuery en la práctica es un DSL extensor de CSS con soporte para HttpRequest. MooTools está en la liga de Prototype y otros grandes. Pero de todas formas podemos comparar como están programados y jQuery/Sizzle son más díficiles de entender que las cosas que salen del equipo de Proietti. Y cuando uno quiere adaptar personalmente (vicios que tiene uno 😀 ) código de otros es importante que las cosas esten claras, y no tener que torear haks pretenciosos y ofuscantes.

  • Personalmente, reconociendo el mérito de Sizzle, su relación tamaño/optimización que gano no compensa demasiado, pero es una opinión personal.

    Y aunque no he usado MooTools, reconozco que esta muy bien estructurado de forma modular y que de base inclulle más cosas que jQuery. La razón por la que uso jQuery es su facilidad de uso a la hora de seleccionar elementos e iterar por ellos (MooTools tambien es facil pero escribiendo 2 lineas más).

  • El exito de jQuery se basa fundamentalmente en su interfaz ultra-minimalista basada en un sobrecarga de métodos a veces un tanto confusa desde un punto de vista formal, la iteración automática que aplican todos sus métodos y una obsesión permanente por encadenar invocaciones de métodos, que lleva en este útimo caso a mantener una pila de wrapped sets en cada wrapper jquery.

    Respecto a ese útimo asunto, ¿merece la pena mantener tal infrastructura en memoria, incluso en los casos en los que no será necesaria, simplemente para ahorrar un cacheo expreso por parte del programador?¿Tan vagos somos? Me explico con un ejemplo:

    
    $('#osbourne').find('.kate').css({'background-color' : 'yellow'}).end().css({'background-color' : 'blue'})
    
    z = franki.get('#osbourne');
    z.get('.kate').css({'background-color' : 'yellow'});
    z.css({'background-color' : 'blue'});
    

    Que me digáis que está bien mantener el asunto de la pila por ahorrarnos la z y presumir de que nos gusta el rollo de las monads y las arrows creo que es el colmo de la vagancia y la pedanteria 😀

  • @Jose: a mi personalmente el encadenamiento de jQuery me encanta. Es cierto que no ayuda a la comprensión del código, pero en la mayoría de los casos ayuda a hacer las cosas muy fácil.

    Hay que partir de que MooTools y jQuery son dos filosofías diferentes para afrontar problemas similares. Por ese motivo hay quien le gusta más uno que otro.
    @Punkesito: Completamente de acuerdo. El problema es que los navegadores no se actualizan a la velocidad que desearíamos.
    @Jose: a ver por partes:

    1) Sizzle es celebre por que lo ha desarrollado quien lo ha desarrollado nada más. Es una muestra de dominio del lenguaje y estoy contigo en que es un desarrollo muy sucio y dificil de entender.

    2) No creo que debamos puntuar un framework por lo fácil que sea entender su código ya que eso lo necesita una minoría. Creo que es más importante que funcione, que lo haga bien y rápido antes que la claridad del código.

    Ojo!, que si encima está bien estructurado y es claro mejor, pero para mi son cosas prescindibles, su finalidad es otra.

Comentar

#

Me reservo el derecho de eliminar y/o modificar los comentarios que contengan lenguaje inapropiado, spam u otras conductas no apropiadas en una comunidad civilizada. Si tu comentario no aparece, puede ser que akismet lo haya capturado, cada día lo reviso y lo coloco en su lugar. Siento las molestias.