javascript - noconflict - not conflict jquery
Es mootools alternativa de jquery+backbone/spine/sprouteCore (1)
Desarrolladores de Java a tiempo completo, ahora también trabajo en JavaScript. Hace un par de años, cuando comencé a aprender JavaScript, la primera biblioteca que probé fue como la mayoría de las personas. Pero me hizo la vida más difícil, y después de algún tiempo comencé a escribir aplicaciones bastante grandes de JavaScript. No se unió para mí usando jquery. Tenía una gran base de código sin mucha estructura. Fue el método que bloquea la actualización de bloques HTML utilizando selectores. Luego probé mootools e inconscientemente como desarrollador de Java me atraía mucho. Y pude escribir aplicaciones web administrables con una gran base de código.
Según mi entendimiento, Mootools no se considera una forma preferida de escribir JavaScript porque imita el OO convencional en comparación con el lenguaje de OO basado en prototipos predeterminado. Así que ahora para entender realmente el javascript y el deseo de caminar con el mundo, decidí probar otros enfoques, así que volví a jquery y me di cuenta de que solo jquery no es suficiente. Así que empecé a buscar en los frameworks de tendencias actuales, como backbone, spine, ember.js, sprouteCore. Extrañamente, encontré que estos marcos en su núcleo intentan imitar los mootools convencionales de OO solo al tener constructores y crear un objeto de clase y reutilizar este objeto de clase para crear objetos de instancia. Asi que
- ¿Me estoy perdiendo de algo?
- ¿Los mootools están realmente mal?
- El proyecto Mootools está muy vivo y lanza nuevas versiones / características, pero no veo a mucha gente hablando de ello en Internet, tampoco hay comparación entre backbone / spine, etc.
Según mi comprensión, Mootools no se considera una forma preferida de escribir JavaScript porque imita al OO convencional con respecto al lenguaje de OO basado en prototipos predeterminado.
¿De dónde sacas eso? Lo mejor de javascript es que está tan vagamente tipeado (mira lo que hice allí): puedes escribir lo mismo en un montón de formas. También hay muchas maneras de abstraerlo y volver a empaquetarlo, y esto se aplica desde un new Array() vs [] a cómo se estructura la aplicación.
Si adoras JavaScript (o simplemente lo conoces y lo odias en secreto), estarás bien con MooTools. La API es principalmente js nativa o especificación ES5 o, rara vez, una utilidad adicional que también se siente "natural". La excepción notable que se destaca es Class . Y el hecho de que puede abstraer tener que lidiar con herencia prototípica pasando un objeto a un constructor especial Type función Type que devuelve su instancia es ... oh, espera. Se ve diferente, pero lo que hace suena bastante normal javascript. Solo que más fácil, ¿por qué no preferirías eso?
Mucho se está haciendo en estos días del boom MVC cliente y esta ''nueva forma de desarrollar aplicaciones''. De repente, a la gente de jQuery se les dio el lujo del agua del grifo. He hablado con muchos desarrolladores de MooTools sobre esto y (sorprendentemente) descubrí que la mayoría piensa que MooTools rara vez necesita algo así. Tiendo a estar de acuerdo con ellos. El único agujero abierto es un controlador de vista con plantillas, pero hay pocas soluciones justas.
La cuestión es que no se puede comparar directamente un framework MVC con MooTools, no es lo mismo. En absoluto. Puede comparar los llamados constructores de modelos vs clases.
Ahora he pasado un tiempo investigando varias soluciones y patrones de framework MVC para ver si nuestra nueva aplicación se puede moldear en una forma de "mejores prácticas".
Básicamente, probé backbone.js (con y sin adaptador mootools) y me resultó incómodo usarlo después de MooTools, parecía un paso atrás. Cuando digo uso , no me refiero a que no pueda usarlo, pero me parece incómodo extenderlo y construirlo. Sin embargo, estoy seguro de que es solo cuestión de experiencia, todavía tengo que leer todos los ejemplos de patrones principales que existen.
Problema típico con el que me topé: quería tener una propiedad especial del Modelo que le diga que use localStorage para buscar / guardar. No es obvio cómo: los ejemplos tienden a mostrar que puede enrutar Backbone.sync a uno u otro, pero no a ambos al mismo tiempo. De hecho, tuve que decorar la función y ampliarla, manteniendo el original referenciado en caso de que el modelo no requiriera localStorage. NO es el patrón mejor / más obvio para mantener y me deja dependiente de sus cambios sin romper mi código.
En MooTools, simplemente habría extendido mi clase Model y podría haber definido una propiedad personalizada de Mutator de Clase (como Binds o Implements ). Hecho. Escribe lo que sabes, dicen, y no por nada ...
Otro problema: está estrechamente relacionado con los datos y no puede reutilizar modelos como las clases. Por ejemplo, un modelo de usuario carga un usuario y lo renderiza a través de una vista de edición de usuario. A continuación, desea crear un nuevo cliente y, de repente, no puede reutilizar el objeto antiguo fácilmente y simplemente renderizar la misma vista pero con valores vacíos. Creo que también será responsabilidad de la inexperiencia de mi parte o mala arquitectura.
Ember.js encontré un poco más moo-ish como interfaz aunque tampoco hizo clic. Francamente, la red troncal fue menos problemática para la configuración.
Hay otros intentos. Composer es uno, una vez más para mootools, pero se esfuerza demasiado para ser una columna vertebral y está escrito por personas que son relativamente nuevas en el framework, así que no lo llamaría maduro. Knockout, etc. Hay uno nuevo todos los días, literalmente.
Garrick Cheung lanzó un marco llamado Neuro que tiene un gran potencial.
Escribí Epitome : una implementación completa de MVP basada en clases y eventos y envuelta en módulos de AMD, no dude en consultarla. También viene con un constructor, un creador de documentación y muchos pequeños extras para que comiences.
SeanMonstar lanzó Shipyard, que es utilizado por Mozilla Flight Deck - http://seanmonstar.github.com/Shipyard/ . Mientras que no son mootools nativos, es mootools-ish con clase mootools, etc., solo que no se extienden los nativos, por lo que es una gran alternativa.
Por cierto, pruebe irc.freenode.net #mootools o la lista de correo y siempre obtendrá una buena respuesta.
De todos modos, suficiente en MVC. Los puntos sobre MooTools se han hecho innumerables veces. Los enemigos serán enemigos. Aquellos que lo aman no miran hacia atrás. Si usted es un programador de un fondo OOP o está buscando algo que se adapta bien a los patrones, hágase un favor y quédese con él. Tiempos emocionantes están por venir. Hoja de ruta para 1.5: AMD, para 2.0 (aka, Prime ) Creación de prototipos de objeto host opcional. Estos han sido los dos puntos de mayor rechazo a los ojos de los críticos. No más prototipos "sucios" para que la gente pueda seguir usando los bucles de ... incorrectamente en no objetos y sin hasOwnProperty comprobaciones hasOwnProperty . De todas formas...
Otras cosas de las que preocuparse pueden ser de importancia. Como, el tamaño de la ''comunidad''. Creo que tener una comunidad saludable es algo grandioso, pero incluso si se mira a jquery, la cantidad de contribuyentes reales frente a usuarios es baja. La proporción de CODE de calidad frente a buenos efectos es mala. Los complementos que puede usar: muchos no están bien escritos o están muertos y sin soporte. ¡Cuando trazas la línea, es mucho menos glamorosa de lo que piensas!
No estoy diciendo que los mootools u otros frameworks no tengan estos problemas. Es justo decir que la gente de MooTools y especialmente los desarrolladores centrales son bastante privados y menos expresivos sobre lo que hacen. Puede enviar impresiones equivocadas, no sé. Ciertamente no es jQuery. En última instancia, si tiene los recursos y los conocimientos técnicos, use lo que funciona mejor y lo que escalará. Incluso hay estos que usan coffeescript y lo juran. Quien soy yo para juzgar...
En aras de una divulgación completa, le resultará MUCHO más difícil encontrar un desarrollador mootools decente cuando reclute. No puede ser ignorado...