Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

?id=9544d38a-4572-4b25-b4fa-ca907bf74778

Durandal/Aurelia vs AngularJS - Preguntas frecuentes

Icono de advertencia ATENCIÓN: este contenido tiene más de 2 años de antigüedad y, debido a su temática, podría contener información desactualizada o inexacta en la actualidad.

Aurelia-vs-Angular

AngularJS es un framework de desarrollo para crear SPAs (Single Page Applications) que está creado y soportado por Google. Su éxito ha sido enorme, y lo han adoptado masivamente millones de desarrolladores. Gran parte de este éxito se debe a que Google está detrás, lo cual a priori le daba estabilidad y largo recorrido. La sorpresa surgió hace casi año y medio cuando el equipo de AngularJS anunció que iba a trabajar en una nueva versión 2 del framework (Angular 2), la cual sería escrita desde cero e incompatible con la actual. El nombre causó gran confusión porque parecía que esta nueva versión iba a sustituir a la anterior, condenada a desaparecer, pero no es exactamente así, sino que ambas versiones deben convivir en paralelo. Además, a la nueva versión aún le queda bastante camino por recorrer antes de salir al mercado.

Por otro lado, uno de los grandes contendientes en el mundo de los frameworks de JavaScript es Durandal. Este framework tiene detrás a Rob Eisenberg uno de los programadores JavaScript más prestigiosos. En un momento dado Rob se fué a trabajar a Google en el equipo de AngularJS, ya que pensaba que era el camino a seguir. Una vez allí y viendo lo que estaban preparando con Angular 2 decidió marcharse y volver a Durandal. Viendo la necesidad de cambiar el modelo decidió lanzar un nuevo framework, pero al contrario que Google gestionó el cambio mucho mejor desde el punto de vista de la comunicación. En lugar de llamarle Durandal 2 y confundir a la gente, dejó claro que era una cosa nueva y en paralelo con Durandal llamándole de un modo completamente distinto: Aurelia. Este nuevo framework sigue una filosofía diferente a Angular y la gente lo adora, por lo que se prevé un contendiente importante para llevarse el honor de ser el más popular.

A continuación encontrarás mi opinión respecto a las preguntas más frecuentes sobre estas dos tecnologías, que me plantean los alumnos de mi curso de "Single Page Applications: arquitectura, patrones y buenas prácticas". Desafortunadamente no podré dar "LA respuesta" sobre la "batalla" entre Durandal y Angular pero seguro que podremos intercambiar unos cuantos puntos de vista interesantes... ¡Vamos allá!

1.- ¿Están listas estas tecnologías para crear aplicaciones reales?

Las tecnologías dedicadas al desarrollo SPA en lado cliente aún no están al 100%. Ni las anteriores a Angular 2/Aurelia, ni tampoco estas últimas. Sin embargo, el mundo de las SPA cada vez está cogiendo más tracción y me aventuro a decir que en un futuro no muy lejano será la arquitectura estándar para el desarrollo web (si no lo es ya...).

Angular 2 y Aurelia aún no son recomendables para desarrollo de aplicaciones en producción ya que ambos se encuentran en beta. Además de que el desarrollo del producto aún no está completado, los dos han apostado por desarrollar el framework utilizando ECMAScript 2015 (popularmente conocido como ECMAScript 6) o TypeScript lo que hace que las aplicaciones desarrolladas utilizando alguno de los frameworks tengan restricciones en cuanto a compatibilidad con navegadores. Esto añade otro factor a tener en cuenta a la hora de escoger un framework para un nuevo desarrollo.

También es cierto que con ambos se puede trabajar con ES5, la versión de JavaScript que soportan el 100% de navegadores evergreen, sin embargo es necesario utilizar un "transpilador" de ES6 a ES5 (por ejemplo Traceur) lo que hace que la aplicación pueda tener peor rendimiento y desde luego no es una opción de futuro.

2.- ¿Crees que Aurelia será mejor que Angular2?

En cuanto a la "batalla" Angular vs Aurelia, creo que probablemente Angular acabará teniendo más tirón, dado que Google está detrás respaldando el producto con más mentes trabajando en él y con mejor publicidad.

A pesar de ello, creo que Aurelia parece ser más modular y "developer-friendly" que el nuevo Angular, pero eso es solo una impresión sobre la beta. Aquí hay un buen artículo sobre la comparativa para conocer más detalles. El propio Rob Eisenberg tiene un artículo en dos partes (parte 1 y parte 2) comparando cómo se hacen algunas cosas con ambos frameworks, y las diferencias son muy evidentes (a favor de Aurelia).

Esto ya ocurrió en su momento con Durandal y Angular 1.

Durandal es un framework, desde mi punto de vista, más sencillo de utilizar y que tiene una arquitectura muy correcta y razonable respecto a Angular 1. La primera versión de Angular es muy potente pero muy oscura a la vez, algunos conceptos son difíciles de entender y en muchas ocasiones acaban utilizándose mal por falta de entendimiento. A pesar de ser más fácil de aprender y utilizar, Durandal no ha tenido tanta cuota de mercado como Angular 1. En mi opinión eso se debe a quien hay detrás de cada producto, teniendo Google más capacidad para atraer a desarrolladores que Durandal.

3.- Puestos a tener que dedicar tiempo de aprendizaje, ¿le ves futuro a Durandal respecto a Angular?

El Durandal inicial acabará desapareciendo en favor de Aurelia, del mismo modo que Angular 1 acabará desapareciendo para dar paso a Angular 2, aunque de momento van a coexistir durante bastante tiempo.

En cuanto a aprendizaje, creo que Durandal es una muy buena opción para aprender cómo funcionan las SPA desde el punto de vista de arquitectura, más que de cómo funciona el framework a fondo. Creo que aprender a desarrollar una aplicación en Durandal es una buena inversión de tu tiempo ya que te hará comprender los conceptos de Aurelia y Angular 2 mucho mejor y probablemente en más profundidad.

4.- En qué producto/versión crees que es más interesante focalizar los esfuerzos?

Creo que, para aprender, es importante empezar a desarrollar una SPA desde cero, con los menos frameworks posibles y por tanto aprendiendo cómo se construye una aplicación a base de JavaScript y HTML puros. Alguna gente se tirará de los pelos al escuchar esto último, pero yo soy de los que creen que los buenos programadores saben hacer frameworks, no usar frameworks.

A pesar de que como programadores tendemos a buscar un mínimo nivel de abstracción que nos haga las cosas más fáciles y llevaderas, creo que en este caso es importante entender qué pasa realmente detrás de uno de estos frameworks.

Durandal puede ser un buen segundo paso en tu aprendizaje para aprender aspectos más complejos como los módulos AMD, templates, estructura de aplicación, etc... 

Una vez tengas la base, si el objetivo es desarrollar una aplicación, es momento de profundizar en un framework para sacarle el mayor partido. Ahí recomendaría escoger entre Aurelia y Angular 2 pero no me atrevería a decir tajantemente cuál de los dos utilizar.

Para dar una respuesta más concreta y decantarme por uno u otro tendría que tener en cuenta el contexto y las necesidades. Probablemente para desarrollar una aplicación empresarial de tamaño considerable (sobre todo si es de carácter crítico), optaría por Angular 2 (una vez no sea beta y todos los navegadores soporten EcmaScript 2015), ya que el soporte y la comunidad que tengan detrás pueden ser decisivos para el éxito del proyecto. Para una aplicación menos crítica, probablemente utilizaría Aurelia. El aprendizaje sería más rápido y el factor soporte/comunidad no serían tan decisivos.

Fecha de publicación:
Albert Margarit Albert Margarit es ingeniero técnico informático apasionado de las últimas tecnologías y del desarrollo tanto en el frontend como en el backend. Está especializado en tecnologías Microsoft. Su carrera como desarrollador le ha llevado a trabajar profesionalmente con sistemas orientados a servicios, aunque está centrado sobre todo en el desarrollo web. Fanático del estudio e implantación de arquitecturas y patrones de diseño en sistemas. Puedes seguirlo en Twitter o en StackOverflow. Ver todos los posts de Albert Margarit
Archivado en: Desarrollo Web

Boletín campusMVP.es

Solo cosas útiles. Una vez al mes.

🚀 Únete a miles de desarrolladores

DATE DE ALTA

x No me interesa | x Ya soy suscriptor

La mejor formación online para desarrolladores como tú

Comentarios (6) -

Discrepo bastante. Considero que el enfoque más adecuado es introducir el HTML en el JavaScript, como hace React.

Conozco bien Angular 1, pero no Angular 2 y Aurelia. Quizás hayan adoptado alguna forma de desarrollar como en React, pero ojeando un poco me parece que no es así.

Me cabrea bastante el uso que hace Angular del MVVM. A estas alturas ya lo considero un antipatrón en general e incluso ando analizando como evitarlo en WPF. Las actualizaciones en cascada son desconcertantes y dificultan mucho seguir el flujo de la información.

Después está el tema de la sobreingeniería. ¿Para qué crear toneladas de nuevas instrucciones en un "framework" si la funcionalidad ya está ofrecida por JavaScript directamente o por alguna librería muy simple?

Personalmente ya no creo en los "frameworks" todo en uno. Prefiero aumentar mucho la modularidad.

Creo que la gente debería dar más oportunidad a React. Les cambiará totalmente la percepción del desarrollo "frontend".

Responder

José Manuel Alarcón
Spain José Manuel Alarcón

Hola Jonás:

Tu opinión está bastante generalizada en el mundillo, y de hecho el post de Albert no la contradice. Más bien al contrario ya que habla de ir a los orígenes sin usar un framework, etc....

Lo que ocurre es que lo que se trata en el artículo no es sobre si Angular o Aurelia o la biblioteca o framework "x" son lo mejor, lo peor o diferente. Se discuten las preguntas frecuentes que le hacen los alumnos sobre este tema en particular, que es lo que él ha tratado de contestar. Y esas preguntas se circunscriben a estos frameworks en particular.

Lo de React y compañía daría para hablar largo y tendido, y a lo mejor algún día hacemos algún post al respecto.

Yo personalmente soy partidario de usar bibliotecas pequeñas diferentes y modulares en lugar de un framework grande, y también opino que Angular está excesivamente "sobre-ingenierado" (como diría Miguel de Icaza), pero lo cierto es que nos guste más o menos, lo utilizan miles (o cientos de miles) de desarrolladores, y está presente en miles de empresas, por lo que conviene conocerlo.

A lo mejor Albert tiene algo que comentar al respecto también.

¡Gracias por comentar!

Saludos.

Responder

Albert Margarit
Spain Albert Margarit

Hola Jonás,

Entiendo perfectamente tu opinión sobre las librerías vs frameworks. Este post simplemente refleja las preguntas que muchos alumnos se hacen cuando tienen que escoger entre Angular 1, Angular 2, Durandal y Aurelia ya sea para aprender algo nuevo o para crear un proyecto empresarial.

Como bien dice José Manuel, y he tratado de reflejar en el post, yo soy partidario de aprender a construir tus propias aplicaciones desde cero. Creo que es la mejor manera de aprender sobre el flujo de ejecución, estructura y funcionamiento general de una SPA.

En mi opinión, la discusión entre librerías y frameworks y sobre lo que es mejor utilizar en cada caso es muy interesante y requeriría otro post. React merecería su propia sección también, sin duda una librería muy interesante.

¡Gracias por compartir tus ideas!

Responder

Hola, recientemente he cursado en la universidad la asignatura de Lenguajes y Estándares Web, al profundizar en HTML y CSS he visto que si un código esta semánticamente bien construido ya es de por si es Responsive y no hace falta usar ningún framework. Imagino que con Javascript ocurrira lo mismo, quien lo domine no tendrá necesidad de usar frameworks.

saludos.

Responder

José Manuel Alarcón
Spain José Manuel Alarcón

Estimado Clyde:

Lo que comentas no es de esa manera. En HTML aunque tengas un código semánticamente bien construido, NO es de por sí Responsive. Una cosa no tiene nada que ver con la otra. De hecho son conceptos contrapuestos. Lo que esté semánticamente bien construido se refiere exclusivamente al contenido y su significado. Lo de que sea Responsive (o no lo sea) es una decisión de diseño, es decir, de cómo se va a visualizar dicho contenido. Una página semánticamente bien construida quiere decir que está claramente separado el contenido de su representación.
Para que sea Responsive hay técnicas concretas, basadas en CSS, y no tienen nada que ver con que además la web esté semánticamente construida.

En cuanto a JavaScript, dominar sus fundamentos es indispensable. Pero eso no quita que para muchas cosas sea necesario usar bibliotecas para no tener que "reinventar la rueda", ya que existen tareas muy complejas que no merece la pena volver a pensar y construir. Un framework como por ejemplo AngularJS o EmberJS, lo que trata es de darte ya hechas muchas decisiones de arquitectura y muchas funcionalidades específicas que se apoyan en esa arquitectura. Esto hará que tus aplicaciones sean más robustas, estables, fáciles de mantener, y que puedas programar más rápido.

Saludos y gracias por comentar.

Responder

Hola José,  aciertas en tu comentario en lo referente a que semánticamenete bien construido no es igual a responsive, no me exprese con claridad. Quise hacer referencia a que por lo menos en lo que a maquetación se refiere, no es necesario el uso de Frameworks como Bootstrap para hacer un diseño responsive. Con Css y las reglas @media puedes lograr lo mismo.

En cuanto a JavaScript no puedo opinar mucho, pero entiendo lo que dices.

Lo que da algo de inseguridad al usar Frameworks en general es por si te encuentres con algún problema particular, estas atado de pies y manos a la espera de que un tercero te lo solucione, o bien vas a invertir un montón de horas en averiguar como resolverlo, y temiendo por que las futuras actualizaciones no te inhabiliten los cambios. (Aplicable también a los CMS).

saludos!


Responder

Agregar comentario

Los datos anteriores se utilizarán exclusivamente para permitirte hacer el comentario y, si lo seleccionas, notificarte de nuevos comentarios en este artículo, pero no se procesarán ni se utilizarán para ningún otro propósito. Lee nuestra política de privacidad.