AngularJS no debería considerarse como un reemplazo de jQuery, en mi opinión. Sin embargo, si usa AngularJS y también está usando jQuery (lo que puede hacer), es una clara señal de que probablemente esté usando AngularJS incorrectamente. Entonces, en ese sentido, puedo decir que naturalmente usará uno u otro, pero no lo llamaría un reemplazo.
Dicho esto, antes de analizar cuándo se debe usar AngularJS, podría ser importante decir por qué creo que son naturalmente mutuamente excluyentes.
Enfoque declarativo versus imperativo para la manipulación DOM jQuery adopta un enfoque imperativo tradicional para manipular el DOM. En un enfoque imperativo, corresponde al programador expresar los pasos individuales que conducen al resultado deseado. ¿Qué quiero decir con esto? Entonces, si queremos que ocurra una acción cuando un usuario escribe 150 caracteres en una entrada, en jQuery diríamos, “cada vez que el usuario presiona una tecla, verifique cuántos caracteres hay en la entrada, si excede los 150 caracteres, haga la acción.” Cada paso se aborda en el camino.
Sin embargo, AngularJS adopta un enfoque declarativo para la manipulación DOM. Aquí, en lugar de preocuparse por todos los detalles paso a paso sobre cómo hacer el resultado deseado, AngularJS lo resume y le permite decir lo que quiere hacer, en este caso, “AngularJS, cuando el estado de la entrada está en 150 personajes, haz esto “. Solo estamos declarando lo que queremos y AngularJS se preocupa por el resto, ocupándose de todo por nosotros.
Puede parecer que solo estoy dividiendo pelos aquí, pero es realmente una distinción importante. AngularJS quiere que bases tus acciones en los modelos de datos que creas. Es cómo funciona todo el marco y cómo se estructurarán sus aplicaciones. Simplemente comenzar a escribir guiones secundarios en jQuery donde estás extrayendo elementos y configurando oyentes de eventos paralelos, en mi opinión, solo va en contra del enfoque AngularJS.
El enfoque AngularJS tiene el único inconveniente que tienen las capas más abstractas, aunque es más simple, le da menos control directo. Muchas veces el control no es necesario y cuando lo hay, hay cosas como Angular-UI y ngAnimate que a menudo pueden resolver el problema que tiene de una manera más “Angular”, pero en el caso de que sea necesario, AngularJS realmente viene preempaquetado con jqLite, que es un subconjunto de jQuery. Esto se hizo intencionalmente para eliminar otra dependencia, lo que tiene sentido dado que AngularJS es un intento de ser un marco front-end que lo abarque todo. Entonces, esto le da aún más razones para no usar jQuery con AngularJS.
Dicho todo esto, si todavía siente la necesidad de usar jQuery, todo lo que necesita hacer es incluir la etiqueta de script jQuery en su página antes de la etiqueta de script AngularJS. AngularJS es lo suficientemente inteligente como para saber que hiciste esto y cambiará a usar jQuery para la manipulación DOM. Esto solo le muestra que no son reemplazos inherentes entre sí, pero según lo anterior, naturalmente no van juntos de muchas maneras.
Bien, eso fue largo aliento … pero ahora sobre la pregunta, ¿por qué deberías usar AngularJS en primer lugar?
Cuándo usar AngularJS … Esa es la pregunta. La intención de jQuery es ser una biblioteca para simplificar la manipulación DOM. La intención de AngularJS es ser un marco completo que proporcione estructura y aborde todos los aspectos de las aplicaciones web modernas que contienen frontales pesados, incluida la manipulación DOM. Entonces, ¿cuándo usas qué?
Mi opinión es que depende del tipo de aplicación que esté creando. Si está construyendo un front-end muy pesado, donde la mayor parte del trabajo pesado se realizará en el frente y todo el back-end realmente será una API REST a la que puede hacer llamadas … de lo que diría un Un marco completo como AngularJS (o Backbone.js o Ember.js o React.js) podría ser una buena idea, ya que te ayudará con mucho más que solo la manipulación DOM.
Sin embargo, si está creando un buen sitio antiguo, con un front-end muy ligero donde se realiza la mayor parte del trabajo en el back-end, un marco de front-end grande podría ser mucho menos útil para usted. Todavía podría usarlo, pero si el front end no está haciendo mucho y es bastante pequeño, parece que no valdrá la pena en mi opinión.
La siguiente es una copia directa y pegar de una respuesta recibida en StackOverflow (lo sé, lo sé …) pero el póster pudo responder a estas preguntas de manera mucho más sucinta de lo que podría decirlo, y creo que es brillante al resaltar las diferencias :
Esto es de: “Pensando en AngularJS” si tengo un fondo jQuery?
1. No diseñe su página y luego cámbiela con manipulaciones DOM
En jQuery, diseñas una página y luego la haces dinámica. Esto se debe a que jQuery fue diseñado para aumentar y ha crecido increíblemente desde esa simple premisa.
Pero en AngularJS, debe comenzar desde cero con su arquitectura en mente. En lugar de comenzar por pensar “Tengo esta parte del DOM y quiero hacer que haga X”, debe comenzar con lo que desea lograr, luego diseñar su aplicación y finalmente diseñar su vista.
2. No aumente jQuery con AngularJS
Del mismo modo, no comience con la idea de que jQuery hace X, Y y Z, por lo que solo agregaré AngularJS además de eso para modelos y controladores. Esto es realmente tentador cuando recién estás comenzando, por eso siempre recomiendo que los nuevos desarrolladores de AngularJS no usen jQuery, al menos hasta que se acostumbren a hacer las cosas de la “manera angular”.
He visto a muchos desarrolladores aquí y en la lista de correo crear estas elaboradas soluciones con complementos jQuery de 150 o 200 líneas de código que luego pegan en AngularJS con una colección de devoluciones de llamada y aplicaciones $applys que son confusas y complicadas; ¡pero finalmente lo hacen funcionar! El problema es que, en la mayoría de los casos, el complemento jQuery podría reescribirse en AngularJS en una fracción del código, donde de repente todo se vuelve comprensible y directo.
La conclusión es esta: al resolver, primero “piense en AngularJS”; si no puede pensar en una solución, pregúntele a la comunidad; si después de todo eso no hay una solución fácil, no dude en buscar jQuery. Pero no dejes que jQuery se convierta en una muleta o nunca dominarás AngularJS.
3. Siempre piensa en términos de arquitectura
Primero sepa que las aplicaciones de una sola página son aplicaciones . No son páginas web. Por lo tanto, debemos pensar como un desarrollador del lado del servidor además de pensar como un desarrollador del lado del cliente. Tenemos que pensar en cómo dividir nuestra aplicación en componentes individuales, extensibles y comprobables.
Entonces, ¿cómo haces eso? ¿Cómo “piensas en AngularJS”? Aquí hay algunos principios generales, en contraste con jQuery.
La vista es el “registro oficial”
En jQuery, cambiamos programáticamente la vista. Podríamos tener un menú desplegable definido como ullike así que:
En jQuery, en nuestra lógica de aplicación, lo activaríamos con algo como:
$('.main-menu').dropdownMenu();
Cuando solo miramos la vista, no es inmediatamente obvio que haya alguna funcionalidad aquí. Para aplicaciones pequeñas, está bien. Pero para aplicaciones no triviales, las cosas se vuelven confusas y difíciles de mantener rápidamente. Sin embargo, en AngularJS, la vista es el registro oficial de la funcionalidad basada en la vista. Nuestra declaración ul se vería así en su lugar:
...
Estos dos hacen lo mismo, pero en la versión AngularJS cualquiera que mire la plantilla sabe lo que se supone que debe suceder. Cada vez que se incorpora un nuevo miembro del equipo de desarrollo, puede ver esto y luego saber que hay una directiva llamada dropdownMenu que opera en él; ella no necesita intuir la respuesta correcta o examinar cualquier código. La vista nos dijo lo que se suponía que sucedería. Mucho más limpio.
Los desarrolladores nuevos en AngularJS a menudo hacen una pregunta como: ¿cómo encuentro todos los enlaces de un tipo específico y agrego una directiva sobre ellos? El desarrollador siempre queda estupefacto cuando respondemos: usted no. Pero la razón por la que no haces eso es que esto es como half-jQuery, half-AngularJS, y no sirve. El problema aquí es que el desarrollador está tratando de “hacer jQuery” en el contexto de AngularJS. Eso nunca va a funcionar bien. La vista es el registro oficial. Fuera de una directiva (más sobre esto a continuación), nunca, nunca, cambias el DOM. Y las directivas se aplican en la vista , por lo que la intención es clara.
Recuerde: no diseñe y luego marque. Debes diseñar, y luego diseñar.
El enlace de datos
Esta es, con mucho, una de las características más impresionantes de AngularJS y elimina la necesidad de realizar los tipos de manipulaciones DOM que mencioné en la sección anterior. AngularJS actualizará automáticamente su vista para que no tenga que hacerlo. En jQuery, respondemos a eventos y luego actualizamos el contenido. Algo como:
Además de mezclar preocupaciones, también tenemos los mismos problemas de intención de significado que mencioné antes. Pero lo que es más importante, tuvimos que hacer referencia y actualizar manualmente un nodo DOM. Y si queremos eliminar una entrada de registro, también tenemos que codificar contra el DOM. ¿Cómo probamos la lógica aparte del DOM? ¿Y si queremos cambiar la presentación?
Esto es un poco desordenado y un poco frágil. Pero en AngularJS, podemos hacer esto:
Pero para el caso, nuestra visión podría verse así:
{{entry.msg}}
Y ahora, en lugar de usar una lista desordenada, estamos usando cuadros de alerta de Bootstrap. ¡Y nunca tuvimos que cambiar el código del controlador! Pero lo más importante, no importa dónde o cómo se actualice el registro, la vista también cambiará. Automáticamente. ¡Ordenado!
Aunque no lo mostré aquí, el enlace de datos es bidireccional. Entonces, esos mensajes de registro también podrían ser editables en la vista simplemente haciendo esto: . Y hubo mucho regocijo.
Capa de modelo distinta
En jQuery, el DOM es algo así como el modelo. Pero en AngularJS, tenemos una capa de modelo separada que podemos administrar de la forma que queramos, completamente independiente de la vista. Esto ayuda para el enlace de datos anterior, mantiene la separación de las preocupaciones e introduce una capacidad de prueba mucho mayor. Otras respuestas mencionaron este punto, así que lo dejaré así.
Separación de intereses
Y todo lo anterior está relacionado con este tema general: mantenga sus preocupaciones separadas. Su punto de vista actúa como el registro oficial de lo que se supone que debe suceder (en su mayor parte); su modelo representa sus datos; tiene una capa de servicio para realizar tareas reutilizables; haces manipulación DOM y aumentas tu punto de vista con directivas; y lo pegas todo junto con los controladores. Esto también se mencionó en otras respuestas, y lo único que agregaría se refiere a la capacidad de prueba, que discuto en otra sección a continuación.
Inyección de dependencia
Para ayudarnos con la separación de preocupaciones es la inyección de dependencia (DI). Si vienes de un lenguaje del lado del servidor (de Java a PHP) probablemente ya estés familiarizado con este concepto, pero si eres un chico del lado del cliente que viene de jQuery, este concepto puede parecer desde tonto hasta superfluo o hipster . Pero no lo es. 🙂
Desde una perspectiva amplia, DI significa que puede declarar componentes con mucha libertad y luego desde cualquier otro componente, solo solicite una instancia de él y se le otorgará. No tiene que saber sobre el orden de carga, ni las ubicaciones de los archivos, ni nada de eso. Es posible que el poder no sea visible de inmediato, pero proporcionaré solo un ejemplo (común): prueba.
Digamos que en nuestra aplicación, requerimos un servicio que implemente el almacenamiento del lado del servidor a través de una API REST y, dependiendo del estado de la aplicación, también el almacenamiento local. Cuando ejecutamos pruebas en nuestros controladores, no queremos tener que comunicarnos con el servidor; después de todo, estamos probando el controlador . Simplemente podemos agregar un servicio simulado con el mismo nombre que nuestro componente original, y el inyector se asegurará de que nuestro controlador obtenga el falso automáticamente; nuestro controlador no sabe y no necesita saber la diferencia.
Hablando de pruebas …
4. Desarrollo basado en pruebas: siempre
Esto es realmente parte de la sección 3 sobre arquitectura, pero es tan importante que lo pongo como su propia sección de nivel superior. De todos los muchos complementos de jQuery que has visto, usado o escrito, ¿cuántos de ellos tenían un conjunto de pruebas? No muchos porque jQuery no es muy susceptible a eso. Pero AngularJS es.
En jQuery, la única forma de probar es a menudo crear el componente de forma independiente con una página de muestra / demostración contra la cual nuestras pruebas pueden realizar la manipulación DOM. Entonces, tenemos que desarrollar un componente por separado y luego integrarlo en nuestra aplicación. ¡Qué inconveniente! Gran parte del tiempo, al desarrollar con jQuery, optamos por un desarrollo iterativo en lugar de un desarrollo basado en pruebas. ¿Y quién podría culparnos?
¡Pero debido a que tenemos una separación de preocupaciones, podemos hacer un desarrollo basado en pruebas de forma iterativa en AngularJS! Por ejemplo, supongamos que queremos que una directiva súper simple indique en nuestro menú cuál es nuestra ruta actual. Podemos declarar lo que queremos en la vista de nuestra aplicación:
Y cuando ejecutamos nuestra prueba, podemos confirmar que falla. Solo ahora deberíamos crear nuestra directiva:
.directive (‘whenActive’, function ($ location) {
regreso {
alcance: verdadero,
enlace: función (alcance, elemento, atributos) {
scope. $ on (‘$ routeChangeSuccess’, function () {
if ($ location.path () == element.attr (‘href’)) {
element.addClass (‘activo’);
}
más {
element.removeClass (‘activo’);
}
});
}
};
});
Nuestra prueba ahora pasa y nuestro menú funciona según lo solicitado. Nuestro desarrollo es tanto iterativo como probado. Genial.
5. Conceptualmente, las directivas no están empaquetadas jQuery
A menudo escuchará “solo manipula DOM en una directiva”. Esto es una necesidad ¡Trátelo con la debida deferencia!
Pero profundicemos un poco más …
Algunas directivas simplemente decoran lo que ya está en la vista (piense en ngClass) y, por lo tanto, a veces realizan la manipulación DOM de inmediato y luego básicamente se hacen. Pero si una directiva es como un “widget” y tiene una plantilla, también debe respetar la separación de preocupaciones. Es decir, la plantilla también debe permanecer en gran medida independiente de su implementación en las funciones de enlace y controlador.
AngularJS viene con un conjunto completo de herramientas para hacer esto muy fácil; Con ngClass podemos actualizar dinámicamente la clase; ngModel permite el enlace de datos bidireccional; ngShow y ngHide muestran u ocultan mediante programación un elemento; y muchos más, incluidos los que escribimos nosotros mismos. En otras palabras, podemos hacer todo tipo de genialidad sin la manipulación DOM. Cuanta menos manipulación DOM, más fáciles de probar las directivas, más fáciles de diseñar, más fáciles de cambiar en el futuro y más reutilizables y distribuibles.
Veo muchos desarrolladores nuevos en AngularJS que usan directivas como el lugar para lanzar un montón de jQuery. En otras palabras, piensan “como no puedo hacer la manipulación DOM en el controlador, tomaré ese código y lo pondré en una directiva”. Si bien eso ciertamente es mucho mejor, a menudo todavía está mal .
Piense en el registrador que programamos en la sección 3. Incluso si lo ponemos en una directiva, todavía queremos hacerlo de la “manera angular”. ¡ Todavía no requiere ninguna manipulación DOM! Hay muchas ocasiones en que es necesaria la manipulación DOM, ¡pero es mucho más raro de lo que piensas! Antes de realizar la manipulación DOM en cualquier parte de su aplicación, pregúntese si realmente lo necesita. Puede haber una mejor manera.
Aquí hay un ejemplo rápido que muestra el patrón que veo con más frecuencia. Queremos un botón que se pueda alternar. (Nota: este ejemplo es un poco ingenioso y un skosh detallado para representar casos más complicados que se resuelven exactamente de la misma manera).
Primero, jQuery nunca fue necesario. ¡No hicimos nada aquí que necesitara jQuery!
Segundo, incluso si ya tenemos jQuery en nuestra página, no hay razón para usarlo aquí; simplemente podemos usar angular.element y nuestro componente seguirá funcionando cuando se angular.element caer en un proyecto que no tenga jQuery.
En tercer lugar, incluso suponiendo que se requiera jQuery para que esta directiva funcione, jqLite ( angular.element ) siempre usará jQuery si se cargó. Por lo tanto, no necesitamos usar $ , solo podemos usar angular.element .
El cuarto, estrechamente relacionado con el tercero, es que los elementos jqLite no necesitan estar envueltos en $ : ¡el element que se pasa a la función de linkya sería un elemento jQuery!
Y quinto, que hemos mencionado en secciones anteriores, ¿por qué estamos mezclando elementos de plantilla en nuestra lógica?
Esta directiva se puede reescribir (¡incluso en casos muy complicados!) Mucho más simplemente así:
Una vez más, el contenido de la plantilla está en la plantilla, por lo que usted (o sus usuarios) pueden cambiarlo fácilmente por uno que cumpla con cualquier estilo necesario, y la lógica nunca tuvo que ser tocada. Reutilización – ¡boom!
Y todavía hay todos esos otros beneficios, como las pruebas, ¡es fácil! No importa lo que haya en la plantilla, la API interna de la directiva nunca se toca, por lo que la refactorización es fácil. Puede cambiar la plantilla tanto como desee sin tocar la directiva. Y no importa lo que cambie, sus pruebas aún pasan.
w00t!
Entonces, si las directivas no son solo colecciones de funciones similares a jQuery, ¿cuáles son? Las directivas son en realidad extensiones de HTML . Si HTML no hace algo que necesita que haga, escriba una directiva para que lo haga por usted y luego lo use como si fuera parte de HTML.
Dicho de otra manera, si AngularJS no hace algo fuera de la caja, piense cómo el equipo lo lograría para encajar perfectamente con ngClick, ngClass, et al.
Resumen
Ni siquiera uses jQuery. Ni siquiera lo incluyas. Te detendrá. Y cuando encuentre un problema que cree que ya sabe cómo resolver en jQuery, antes de alcanzar el $, intente pensar en cómo hacerlo dentro de los límites del AngularJS. Si no lo sabes, ¡pregunta! 19 de cada 20 veces, la mejor manera de hacerlo no necesita jQuery y tratar de resolverlo con jQuery resulta en más trabajo para usted.
Una vez más, estos textos fueron escritos por Josh David Miller en “Thinking in AngularJS” si tengo antecedentes de jQuery?
AngularJS está en uso desde hace bastantes años. Muchos bancos e instituciones financieras están utilizando AngularJS en su aplicación en vivo ahora. Digo Banks porque son conocidos por usar solo las tecnologías antiguas y estables. Este es un gran sello de estabilidad para los fanáticos de AngularJS.
Definitivamente puedes mezclar Angular con jQuery. Ambos se pueden usar juntos en la misma página sin ningún problema. Pero sea cauteloso y no manipule demasiado su aplicación. Angular solo es bueno para SPAs, es decir, aplicaciones de una sola página donde desea toda la funcionalidad en una página, haciendo muchas llamadas de Ajax al servidor. Si eso es algo que desea hacer, entonces Angular es el camino a seguir; de lo contrario, jQuery probablemente sea lo suficientemente bueno para pequeños scripts de validación y animación de JS.
AngularJS es aplicable para el desarrollo de aplicaciones web que funciona con el código HTML y los datos JSON, lo que ayuda a desarrollar aplicaciones interactivas y robustas, pero el uso de las mismas para un desarrollo de sitio web simple resulta en una carga lenta y sitios web bastante erráticos.
Mientras que, jQuery es una biblioteca JavaScript multiplataforma rápida, pequeña y rica en funciones. Tiene funciones integradas como el recorrido y la manipulación de documentos HTML, el manejo de eventos, la animación y el soporte de Ajax con una API fácil de usar que funciona en una multitud de navegadores útiles para simplificar el desarrollo de sitios web hardcore.
AngularJS está diseñado para reemplazar JQuery, Backbone.js o Ember.js o React.js, etc. Está trayendo algunos estándares sobre la interfaz de usuario y las interacciones del servidor. Si compara poco entre JSF y AngularJS, JSF es caras de servidor Java, AngularJS es caras de cliente Javascript.
JQuery tiene todas las cosas para hacer interacciones dentro de la interfaz de usuario o con el servidor, al igual que muchas otras bibliotecas JS. Angular JS es nítido en el manejo de las interacciones del servidor y la visualización de la IU de los datos recuperados. La pregunta debería ser qué angular JS no puede lograr al hacer lo que hace JQuery.
AngularJS es un marco de aplicación que te ayuda a administrar datos y vistas y, por otro lado, jquery es una biblioteca de manipulación de dom que te ayuda a interactuar con dom y hacer cambios en él. Para cosas como arrastrar, soltar, ordenar y delegar eventos, es posible que aún necesite jquery.
Angular es un marco mucho más completo que jquery. Jquery es principalmente un marco para hacer la manipulación DOM. Angular es un marco para construir una aplicación completa de una sola página. Definitivamente creo que es una buena idea aprender más sobre Angular, y sí, jquery se integra con Angular. Sin embargo, siempre recomiendo usar jquery con moderación ya que no promueve buenos patrones de código.
Aquí hay más información: ¿jQuery sigue siendo relevante?
