¿Por qué se compara AngularJS con otros marcos?

Angular es el único marco que no hace que MVC parezca poner lápiz labial en un cerdo.

La mayoría de los marcos actuales son simplemente un paquete de herramientas existentes. Son un conjunto de herramientas integrado, pero no muy elegante. Angular es el marco de la próxima generación en el que cada herramienta fue diseñada para trabajar con todas las demás herramientas de forma interconectada.

Aquí hay 10 razones por las que debería usar Angular hoy.

1. MVC hecho bien

La mayoría de los frameworks implementan MVC al pedirle que divida su aplicación en componentes MVC, luego le solicitan que escriba código para encadenarlos nuevamente. Eso es mucho trabajo. Angular implementa MVC pidiéndole que divida su aplicación en componentes MVC, luego simplemente deje que Angular haga el resto. Angular administra sus componentes por usted y también sirve como la tubería que los conecta.

Debido a que Angular actúa como mediador, los desarrolladores tampoco se sentirán tentados a escribir atajos entre componentes que rompan las abstracciones solo para que se ajusten más fácilmente.

2. Una interfaz de usuario declarativa.

Angular usa HTML para definir la interfaz de usuario de la aplicación. HTML es un lenguaje declarativo que es más intuitivo y menos complicado que definir la interfaz de manera procesal en JavaScript. HTML también es menos frágil para reorganizar que una interfaz escrita en JavaScript, lo que significa que es menos probable que las cosas se rompan. Además, puede atraer a muchos más desarrolladores de IU cuando la vista está escrita en HTML.

HTML también se utiliza para determinar la ejecución de la aplicación. Los atributos especiales en el HTML determinan qué controladores usar para cada elemento. Estos atributos determinan “qué” se carga, pero no “cómo”. Este enfoque declarativo simplifica enormemente el desarrollo de aplicaciones en una especie de WYSIWYG (lo que ves es lo que obtienes). En lugar de perder tiempo en cómo fluye el programa y qué debe cargarse primero, simplemente define lo que desea y Angular se encargará de las dependencias.

3. Los modelos de datos son POJO

Los modelos de datos en Angular son simples objetos JavaScript antiguos (POJO) y no requieren funciones de captador y definidor extrañas. Puede agregar y cambiar propiedades directamente en él y recorrer objetos y matrices a voluntad. Su código se verá mucho más limpio y más intuitivo, como pretendía la madre naturaleza.

Los modelos de datos tradicionales son los guardianes de los datos y son responsables de la persistencia de los datos y la sincronización del servidor. Esos modelos de datos se comportan como proveedores de datos inteligentes. Pero dado que los modelos de datos de Angular son objetos simples, se comportan más como un tablero de corcho. Un tablero de corcho no es más que un área de almacenamiento temporal para que las personas puedan poner y recuperar datos. Sin embargo, las placas de corcho de Angular trabajan en estrecha colaboración con un controlador y una vista. Para diferenciarlo del sentido tradicional de los modelos de datos, Angular los llama “ámbitos”.

Angular vincula automáticamente todas las propiedades encontradas en el objeto de alcance. Es decir, Angular observa silenciosamente los cambios en estas propiedades y actualiza la vista automáticamente.

El alcance no tiene datos para comenzar y se basa en el controlador para alimentar los datos de acuerdo con las necesidades de la lógica empresarial.

4. Comportamiento con directivas.

Las directivas son la forma en que Angular aporta funcionalidades adicionales a HTML. Imagine un mundo donde HTML tiene tantos elementos ricos (por ejemplo, , , , etc.) que nunca tenemos que manipular el DOM para simular ellos. Todo lo que nuestra aplicación necesita hacer es asignar atributos a los elementos para sacar cualquier funcionalidad de la caja.

Las directivas logran esto al permitirnos inventar nuestros propios elementos HTML. Al poner todo nuestro código de manipulación DOM en directivas, podemos separarlos de nuestra aplicación MVC. Esto permite que nuestra aplicación MVC solo se preocupe por actualizar la vista con nuevos datos. El comportamiento posterior de la vista depende de las directivas.

Las directivas vienen en forma de elementos HTML personalizados

atributos personalizados

y nombres de clase personalizados

lo que les permite ser utilizados como elementos HTML normales.

Las directivas están diseñadas para ser elementos reutilizables independientes separados de su aplicación. De hecho, si el estándar HTML5 adopta un elemento en particular, debería ser tan simple como eliminar su directiva personalizada, y su aplicación debería comportarse exactamente igual sin necesidad de cambiarla.

Recuerde, como regla general, su controlador no debe manipular el DOM directamente. Todas las manipulaciones DOM deben ser realizadas por directivas.

5. Flexibilidad con filtros

Los filtros filtran los datos antes de que lleguen a la vista y pueden incluir algo tan simple como formatear lugares decimales en un número, invertir el orden de una matriz, filtrar una matriz en función de un parámetro o implementar la paginación. Los filtros están diseñados para ser funciones independientes que son independientes de su aplicación, similares a las Directivas, pero solo se preocupan por las transformaciones de datos.

Los filtros son tan ingeniosos que es posible crear una tabla HTML ordenable usando solo filtros sin escribir JavaScript.

6. Escribe menos código

Todos los puntos hasta ahora significan que puedes escribir menos código. No tiene que escribir su propia tubería MVC. La vista se define usando HTML, que es más conciso. Los modelos de datos son más simples de escribir sin captadores / definidores. El enlace de datos significa que no tiene que poner los datos en la vista manualmente. Dado que las directivas son independientes del código de la aplicación, otro equipo puede escribirlas en paralelo con problemas mínimos de integración. Los filtros le permiten manipular datos en el nivel de vista sin cambiar sus controladores. Sí, esto es una especie de viñeta de resumen, ¡pero escribir menos código es un gran problema!

7. Manipulaciones DOM donde pertenecen

Tradicionalmente, la vista modifica el DOM para presentar datos y manipula el DOM (o invoca jQuery) para agregar comportamiento. Con Angular, el código de manipulación DOM debe estar dentro de las directivas y no en la vista. Angular ve la vista como otra página HTML con marcadores de posición para los datos. Esta forma de ver la vista se combina muy bien con los diseñadores de interfaces de usuario.

Al abstraer las manipulaciones DOM y las llamadas jQuery, los diseñadores de interfaces de usuario pueden enfocarse en la vista sin esas distracciones.

Al hacer que su aplicación MVC se limite a presentar datos comerciales en vistas y no tener que preocuparse por manipular DOM, el desarrollo de aplicaciones web de repente se volvió más divertido.

8. Proveedores de servicios a los que pertenecen

Los controladores en Angular son funciones simples que tienen un solo trabajo, que es manipular el alcance. Por ejemplo, puede usarlo para completar previamente los datos en el ámbito desde el servidor o implementar validaciones de lógica de negocios. A diferencia de otros marcos, los controladores no son objetos y no heredan de nada.

Si los controladores son tan simples, ¿dónde se debe realizar todo el trabajo pesado? Angular presenta Servicios para hacer precisamente eso.

Los servicios son exactamente como suenan. No se involucran con el MVC de su aplicación, sino que simplemente proporcionan una API externa para exponer lo que quiera que exponga. La mayoría de las veces se sincroniza con un servidor para mantener un almacén de datos fuera de línea y expone métodos para empujar y extraer datos hacia y desde un servidor. O puede usarse para crear un servicio de intercambio de recursos que permita que múltiples controladores compartan los mismos recursos.

Los servicios están diseñados para ser objetos independientes separados de su aplicación y permitir que su controlador permanezca delgado y dedicado a la vista y el alcance al que está asignado. Por supuesto, no se requieren servicios de implementación y es perfectamente aceptable levantar un poco de luz dentro de su controlador para evitar una complejidad excesiva.

9. Comunicación consciente del contexto

Un sistema PubSub es una herramienta bastante común que permite la comunicación desacoplada. La mayoría de las implementaciones de PubSub en la web no son conscientes del contexto. A veces, desea que un mensaje de PubSub sea legible solo por los hijos de un nodo en particular, o solo por los antepasados ​​de un niño en particular. En otras palabras, a veces no desea que los componentes MVC no relacionados estén leyendo sus mensajes.

El sistema PubSub en Angular es precisamente eso. broadcast() enviará un mensaje a todos los controladores secundarios, mientras que emit() enviará un mensaje a todos los antepasados.

Pero PubSub no es la única forma de comunicarse entre controladores. De hecho, si todo lo que está haciendo es decirle a otros controladores que actualicen sus vistas cuando cambia una propiedad, debe confiar en el enlace de datos. Ya sabemos que la vista puede estar vinculada a propiedades en el ámbito actual. Pero lo que no le dije es que los ámbitos heredan las propiedades de sus ámbitos principales. Eso significa que si existe una propiedad en el ámbito primario, y un ámbito secundario la modifica, ¡todos los demás ámbitos que hereden del mismo elemento primario también verán la misma modificación y Angular actualizará sus vistas automáticamente! Esta forma automática supera el uso de PubSub cualquier día.

10. Prueba de unidad lista

¿Qué descripción de Angular estaría completa sin hablar de su preparación para pruebas unitarias? El conjunto de Angular está unido entre sí por Dependency Injection (DI). Es lo que usa para administrar sus controladores y ámbitos. Debido a que todos sus controladores dependen de DI para pasarle información, las pruebas unitarias de Angular pueden usurpar DI para realizar pruebas unitarias al inyectar datos simulados en su controlador y medir la salida y el comportamiento. De hecho, Angular ya tiene un proveedor HTTP falso para inyectar respuestas falsas del servidor en los controladores.

Esto supera la forma más tradicional de probar aplicaciones web creando páginas de prueba individuales que invocan un componente y luego interactuando con él para ver si funciona.

Estas 10 razones deberían darle una idea de por qué Angular es tan poderoso. No todas las aplicaciones web deberían usar Angular. Por ejemplo, si está escribiendo un juego o un programa matemático computacionalmente intensivo, no hay razón para que Angular se ajuste a su dominio de problema particular. Pero para las aplicaciones web genéricas, debería servir como un marco viable para construir.

Fuente: 10 razones por las que debe usar AngularJS

Para más detalles: http://www.angularjs.org/

Unas pocas cosas:

  • Angular es obstinado. En lugar de tener que elegir cada biblioteca, Angular le dice qué hacer. Esto reduce la carga cognitiva y el tiempo de inicio.
  • En relación con el primer punto, cuando hay varios desarrolladores trabajando en un proyecto, hay menos motivos para discutir.
  • Siguiendo ese tema, es más fácil para un nuevo desarrollador ponerse al día en un proyecto Angular.
  • En comparación con los otros marcos enumerados, Angular 2 es más rápido.
  • En comparación con Bootstrap + JQuery, Angular 2 es más seguro.
  • En comparación con React, algunas cosas son más fáciles de hacer en Angular. [1]

Entonces, si tiene un proyecto de desarrollador pequeño y único que no necesita preocuparse por contratar a otros desarrolladores para mantener, Angular es mucho menos convincente.

Para un juego que estoy creando, quería que la interfaz de usuario fuera súper rápida, pero quería una sobrecarga mucho más baja que Angular. Para eso estoy usando Mithril, que es más rápido que Angular 2 y menos de 10k comprimido. [2]

Es un juego, por lo que los desarrolladores no serán “intercambiables” pase lo que pase. Y lo estoy usando más estrictamente como una capa de vista, por lo que podría haber usado React, pero nuevamente Mithril es más pequeño y más rápido, ¿por qué?

Diferentes proyectos tienen diferentes requisitos. Mire los requisitos de su proyecto y vea qué se adapta mejor a su proyecto.

Notas al pie

[1] Angular es fácil. Reaccionar es difícil.

[2] http://mithril.js.org