react español desventajas javascript frameworks backbone.js ember.js angularjs

javascript - español - angularjs vs angular



Angular.js Backbone.js o que tiene un mejor rendimiento (8)

Soy un desarrollador web y estoy empezando a desarrollar una aplicación web a gran escala, pero no estoy seguro de qué marco utilizar. Estaba pensando en Angular.js, pero también consideré Backbone.js. Para ti, ¿cuál sería el mejor marco? o al menos tener una comparación entre los dos para ver el rendimiento.

echa un vistazo a knockoutjs también. Mire el video para comprender cómo funciona MVVM en el mundo javascript.

http://knockoutjs.com/

Lo he usado para algunos proyectos y estoy muy contento con él. Lo veo como parte de la nueva ASP.NET MVC 4 (SPA) y respaldado por Microsoft.

no necesariamente una respuesta sino otro enlace de recursos con pros / contra genéricos para cada marco. Creo que lo que dijo Igor Minar es realmente importante, concéntrese en lo que es fácil de aprender, fácil de implementar y no interfiere con su productividad en lugar de obsesionarse con el rendimiento.

http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/

Por lo que vale, Angular JS y Ember JS me atraen principalmente porque su uso de enlace es muy parecido al mecanismo de enlace de Flex (en un nivel alto) Y deja el HTML desacoplado principalmente de la lógica del controlador / modelo.

Hay otra comparación de rendimiento entre Angular, Ember y KO aquí:

http://jsperf.com/angular-vs-knockout-vs-ember/2

El ganador claro en este caso es Angular, pero como se dijo anteriormente, las pruebas de rendimiento rara vez son sencillas o justas.

No referenciada Backbone y Angular. Todavía comparto mi experiencia real que tuve con ambos en la misma aplicación: una aplicación de tamaño mediano, con SPA. Primero usamos Backbone , y completamos muchas funciones. Código más productivo y claro que la escritura directa en JS / jQuery . Después de un año, nos mudamos a angularjs . Reescribí todo en angular, ahora tenemos alrededor de 140 directivas, controladores y servicios mixtos. Codifica la calidad y la productividad mucho mejor. Pero no es tan rápido como la misma aplicación en la red troncal. Ahora solo está mirando para Object.Observe para ser lanzado en Chrome para perf boost. El equipo de Angularjs debe estar mirando la esquina de rendimiento.

Antes de elegir un marco, realmente debería leer bien sobre dónde se ajusta. Si su respuesta json es pesada con demasiados atributos, y demasiados de esos objetos estarán vivos en cualquier momento, angular será lenta. Allí Backbone gana, pero una vez más, necesita administrar muchas cosas, calidad de código y patrones con Backbone.

Puede hacer que la red troncal sea más fácil si lo reduce al mínimo. Eliminé el guión bajo de dependencia o lodash de la columna vertebral, haciéndolo más claro y modifiqué sus eventos para usar bean y casi enderjs libs menos morpheus. Lo cambié para la luz interpolada.

Te diré que esto es wayyyyy más rápido que angular. Las páginas se cargan en milisegundos frente a segundos.

Lo angular es que el patrón de diseño MVVM es lento porque tienes una tonelada de interacción DOM directa. JavaScript es rápido sin el DOM. Entonces use el DOM lo menos posible, y eso es imposible con MVVM.

Lo mejor es que su lógica se separe con referencias DOM muy rápidas y livianas, el uso de punteros siempre que pueda es siempre una mejor opción. He usado y revisado cada línea del marco bye line. Stock obtendrá aproximadamente el mismo rendimiento, modificado es una historia diferente.

El stock de Backbone está hinchado y la mayoría de los motores de plantilla son lentos. Así que use dotjs para plantillas, use ender y no jQuery, use bean para eventos personalizados.

Angular tiene un motor de plantillas extremadamente lento que se calienta y su uso intenso de DOM lo hace aún más lento ... Sin mencionar que todas las uniones declarativas mezcladas en el marcado son difíciles de mantener y leer.

He hecho jsperfs en casi todos los frameworks y bibliotecas conocidos por JS I build frameworks for a living. Sí, hay un montón de variables involucradas, pero si se hace bien, elegiría la columna vertebral cualquier día de la semana. MVVM morirá ... MVP es donde está en lo que respecta a los marcos de front-end.

Cualquiera que afirme que una solución es más rápida o más lenta que otras, no sabe mucho sobre ninguna de estas bibliotecas o marcos (o pruebas de perfusión en general) o es una mentirosa.

El rendimiento es una característica muy difícil de medir debido a tantas variables que lo afectan. Solo por nombrar algunos:

  • calidad del código de prueba / punto de referencia
  • calidad del código de biblioteca / marco
  • tipo de aplicacion
  • calidad del código de la aplicación
  • navegador utilizado
  • cliente hw
  • otros procesos que se ejecutan al mismo tiempo en el cliente hw
  • calidad y velocidad de la conexión a internet
  • carga del servidor y rendimiento del servidor
  • Y la lista sigue y sigue...

pero, lo que es más importante, ¿a qué se refiere exactamente por desempeño? el rendimiento es un término muy amplio que cubre demasiadas cosas, que incluyen:

  • tiempo que tarda en arrancar la aplicación
  • el tiempo que toma responder a una acción del usuario
  • utilización de recursos (cpu / memory / network)
  • rendimiento de la manipulación del dom hecho por el código de la biblioteca / marco / aplicación
  • la amistad del recolector de basura
  • y de nuevo la lista sigue y sigue ...

La mejor manera de responder a su pregunta es crear una aplicación que sea bien representativa de la aplicación que tiene la intención de compilar e implementar con las bibliotecas / frameworks que compiten entre sí. Luego, escriba un benchark de calidad que los compare cara a cara en un entorno estable.

Esta es obviamente una tarea muy laboriosa y solo alguien con mucho en juego la emprendería.

Sin embargo, hay una solución diferente a este problema: comprender el marco / biblioteca que está utilizando y específicamente:

  • aprende los flujos centrales y los algoritmos que usa el framework / biblioteca internamente. Aunque normalmente no debería preocuparse, cuando se encuentre en un problema de rendimiento, comprender cómo se ejecuta su aplicación le permitirá identificar y corregir los problemas de desempeño.
  • comprobar si el rendimiento es algo en lo que los escritores de la biblioteca / marco tienen experiencia en
  • compruebe si el marco / la biblioteca lo ayuda a identificar problemas de rendimiento y solucionarlos

En cuanto a la comparación real entre Backbone y AngularJS, estás comparando dos soluciones muy diferentes.

El Backbone no hace ninguna manipulación dom para usted, por lo que la velocidad de su aplicación dependerá en gran medida de qué tan bien puede hacer dom manipulación (es su experiencia?).

AngularJS hace la mayor parte de la manipulación del dom para usted y tenemos mucha experiencia en esta área, así que a menos que sea realmente bueno, tendrá dificultades para emparejarnos.

En segundo lugar, la observación de la mutación del modelo de la red troncal se basa en eventos, envoltorios de modelos y uso de getters y setters artificiales. No solo eso puede ser muy ineficiente debido a la falta de fusión de eventos (puede haber una solución para esto en las últimas versiones de red troncal), pero el uso de captadores y configuradores artificiales también interfiere con el compilador JIT en su navegador.

Misko escribió una larga publicación sobre cómo Angular hace su observación de la mutación del modelo mágico. Entonces no voy a repetirlo aquí. Pero, básicamente, el rendimiento de una aplicación AngularJS está directamente relacionado con el número y la complejidad de los enlaces utilizados en la vista actual de la aplicación. Con esto en mente, puede predecir fácilmente el rendimiento de Angular. Aún mejor es que con herramientas como la extensión AngularJS Batarang para Chrome, le permitimos instrumentar fácilmente su aplicación y entender qué enlaces en la página son lentos y esto le permite concentrarse en arreglar las partes de su código que realmente importan.

Concluiré diciendo que ninguna biblioteca o marco será la mejor solución para todos sus casos de uso, por lo que debería aprender más sobre las herramientas con las que construye sus aplicaciones y, cuando realmente importa, decidir cuál es la mejor. para un caso de uso dado. Mi apuesta es que para la mayoría de las aplicaciones que va a escribir, el rendimiento no cambiará notablemente si cambia de marco o biblioteca. Así que pondría más peso en otros factores como la productividad, facilidad de uso, capacidad de prueba, comunidad y documentación antes de preocuparme por el rendimiento.

Y lo último: los puntos de referencia a menudo son engañosos, pero echa un vistazo a estos y tómalos con un grano de sal.

Información tangencial, pero relevante además de lo que @ igor-minar ya dijo en https://.com/a/11498872/850996

Hubo varios ejemplos en los que encontré problemas de rendimiento que están relacionados con lo que se discute aquí. Y estos ejemplos no implicaron ningún marco (más allá de jQuery core para acceder al DOM).

Teníamos varios componentes de UI que estábamos construyendo, diseñando y renderizando en un árbol DOM que consistía en una gran cantidad de elementos. Javascript y DOM tienen la característica de rendimiento inherente que al leer DOM atribuye bloques a las actualizaciones pendientes del DOM [1]. Por ejemplo, si cambia 5 atributos CSS de un elemento, que el navegador puede poner en cola y ejecutar más tarde, y luego intenta leer un atributo CSS, debe completar las escrituras DOM pendientes antes de que le devuelva el atributo que usted acabo de leer. Por ejemplo, los escenarios simples como leer un elemento.offsetHeight pueden ser costosos porque requiere que el DOM complete las actualizaciones pendientes y luego mida y diseñe los elementos antes de que pueda determinar la altura del elemento en particular.

Tuvimos muchos códigos que se escribieron sin tener en cuenta esta característica básica. Repararlo requería optimizarlo de tal forma que se minimizaran las lecturas de bloqueo de DOM. Además, la creación de subárboles DOM fuera de línea antes de adjuntarlos al documento ayudó en algunos casos.

Con todos estos ajustes, no pudimos obtener el tipo de rendimiento que necesitábamos para escenarios como grandes listas (por ejemplo, una vista de lista de desplazamiento que podría tener varios miles de elementos de lista, cada uno compuesto de múltiples elementos DOM para obtener el estilo visual deseado) . Aquí, tuvimos que cambiar el código para virtualizar la lista y solo renderizar el subconjunto de elementos DOM que eran realmente visibles en la lista [2].

El principal comentario que quería agregar a este tema es decir que el marco que elija no resolverá todos los problemas de rendimiento que pueda encontrar en su aplicación. Entonces, como lo señalan otras respuestas, saber cómo su marco elegido implementa su magia y elegir un marco que le permita ver lo que está haciendo (a través de la instrumentación de rendimiento) dará sus frutos al final. Y el marco no es un sustituto para comprender las características centrales de las implementaciones modernas de los navegadores. El libro de alto rendimiento de JavaScript que se escribió hace muchos años sigue siendo un gran recurso. Y aprenda a utilizar las numerosas herramientas de creación de perfiles disponibles para que pueda ver rápidamente dónde están los cuellos de botella en su aplicación.

mejor,

-

Referencias

[1] http://shop.oreilly.com/product/9780596802806.do Lea el capítulo 3 sobre DOM scripting

[2] https://github.com/shyam-habarakada/js-virtual-list-view