¿Por qué muchos desarrolladores están molestos por los cambios en Angular 2.0?

En mi opinión, las personas reaccionan de forma exagerada a los cambios en Angular 2.0. ¿Son significativos? Si. ¿Los cambios hacen que sea similar a aprender un marco completamente nuevo? No. Los conceptos centrales siguen ahí. El cambio es inevitable.

AngularJS se ha convertido en un marco “corporativo” o “empresarial” para algunas aplicaciones web. Estas implementaciones valoran un cierto nivel de estabilidad en la API y en las características.

La amenaza de cambiar la API y la falta de soporte para la base de código actual es una preocupación para los desarrolladores de aplicaciones empresariales.

Porque:
1. Hay muchas cosas creadas en Angular 1.x, que simplemente no serán compatibles con Angular 2. En el mejor de los casos, habrá algún tipo de herramienta de migración, pero estas nunca funcionan al 100%.
2. Supongo que muchas personas eligieron Angular porque pensaron que “respaldado por Google” == Estable (API).
3. A pesar de lo que podríamos pensar acerca de nosotros mismos, los desarrolladores son humanos y, como la mayoría de los humanoides, nuestra reacción instintiva al cambio suele ser “NO ES LO INCORRECTO”. Lo superaremos.
4. Angular 2 está diseñado para el futuro. Se basa en las características del navegador y el idioma que aún no son convencionales, y probablemente no lo serán durante casi un año. Puede parecer “aterrador” para alguien que no lo ha analizado en profundidad y (ver punto anterior): Parece extraño == Miedo.
5. Creo que hay desarrolladores que comenzaron a hacer desarrollo web con Angular. Para ellos, Angular 2 está cambiando los cimientos, y eso parece una locura.

Solía ​​ser uno de los que odiaban, así que te daré un ejemplo específico. He pasado un año desarrollando aplicaciones de una sola página con AngularJS 1.x con la siguiente pila

• todo el código JS escrito en CoffeeScript
• Código JS incluido usando The Asset Pipeline
• dependiendo de muchos módulos populares: módulos AngularJS, complementos y directivas

Aprendí mucho de las tuercas y tornillos de AngularJS: usar la inyección de dependencia en mis propios componentes, construir directivas, optimizar el rendimiento, etc.

Que los chicos de AngularJS anunciaron la versión 2.0

• sin intención de admitir la rama 1.x más allá de 1.3.x (lo que también significa que ninguno de los complementos de código abierto existentes estará disponible)
• con un nuevo lenguaje requerido para escribir código AngularJS (AtScript – una extensión de Microsoft TypeScript) que ni siquiera existía en este momento sin hablar de ningún recurso para aprenderlo, soporte de herramientas, etc.
• con una revisión masiva de los componentes internos, por lo que la mayoría de las cosas que he aprendido no sirven para nada

Por otro lado, la última actualización de Angular 2.0 no es tan dramática.

• Han configurado su propio sitio web https://angular.io/ y prometen seguir manteniendo la rama 1.x en la medida en que el tráfico al nuevo sitio web sea mayor que el del anterior.
• Han acordado con los muchachos de Microsoft fusionar las adiciones de AtScript directamente en el lenguaje TypeScript

Entonces, después de muchas tormentas, supongo que finalmente van en la dirección correcta. El viaje tomará mucho más tiempo de lo esperado, pero será más amigable para los desarrolladores.

Hay bastantes razones, ¿la razón más importante de todas? La nueva sintaxis es asquerosa. Estaba a bordo de Angular 2 al principio hasta que revelaron la horrible sintaxis vinculante e incluso después de que muchos estaban en contra, el 1% del equipo de Angular fue con su propuesta inicial en primer lugar. Rob Eisenberg (Durandal, Aurelia) fue colaborador durante unos breves meses y fue uno de los oponentes más vocales.

Esta publicación de blog resume la nueva sintaxis, mira lo horrible que es: Angular 2 Template Syntax

Para mí acaba de lanzarse pero no está realmente terminado …
Probablemente cometieron el mismo error al nombrar que PlayFramework hizo de la versión 1 a la 2 …
Las herramientas son pobres, pero prometieron mejorarlo en el ángulo 3. No, en realidad 4.
La compilación con AOT es lenta (como realmente lenta), incluso si proporciona comentarios realmente buenos, sobre lo que es bueno o no en sus plantillas.
La mayoría de los nuevos conceptos (incluso los que provienen de angularjs …) no sirven de nada cuando se realiza el desarrollo front-end (al menos tienen uno, lo hacen complejo de aprender).

Por lo tanto, realmente carece de herramientas y simplicidad. No hablaré sobre los 400k de js que liberas cuando haces un simple mundo hola con angular 2 incluso si optimizas como el infierno …
Cuando miras el proyecto como preact por ejemplo, un Hello World tiene un máximo de 9k de js …

La incompatibilidad es definitivamente la n. ° 1. Literalmente, en este momento estoy escribiendo un código que sé que será absolutamente obsoleto y no se puede migrar en cuestión de meses. Más que nada, esa es una posición terrible en la que estar. No solo eso, sino que hay un ecosistema completo de extensiones (servicios) que ya no se mantendrán, o podrían quedar en el limbo. Una ruptura tan grande realmente ha causado mucha angustia sobre si proceder con 1.3 para los proyectos actuales.

Te diré por qué estoy decepcionado, ahora requiere un paso de compilación.

Esto complica las cosas. Un área en particular es con plataformas de depuración como plnkr, jsedit y similares. Habiendo venido de un fondo .Net, fue muy agradable migrar a javascript y poder configurar todo su problema simplemente copiando / pegando 40 líneas de código en un navegador. Luego, espere a que la comunidad generosa duplique y resuelva su problema con precisión.

O, por el contrario, poder descargar el ejemplo * exaaaact * de alguien de una función y descubrir por qué no funcionó para mí. Es tan increíble que cuando alguien publica un ejemplo de plnkr, definitivamente haré que funcione también en cuestión de minutos. No hay variables ambientales misteriosas que puedan complicar las cosas.

Ahora, siento que he vuelto a esos días .Net. Donde alguien dice “aquí están mis 2 líneas de código para que el calendario funcione” y, sin embargo, estoy en mi tercera semana tratando de hacer que las cosas funcionen. Luego, descubra que es una oscura dependencia ambiental.

Intenté usar la versión de plnkr que admite Angular2 y descubrí que no siempre podía duplicar ejemplos alojados allí. Porque algo de eso es invisible para mí ahora. No sé qué interruptores están usando para compilar. No sé qué versión de Node, Express y ninguna otra de las bibliotecas o versiones de las mismas están utilizando.

Puedo trabajar con eso, sí. Pero por qué dar un paso atrás.

Creo que entre las razones por las que los desarrolladores estarían molestos es que el proceso de migración es generalmente un proceso doloroso y prolongado que requiere mucho trabajo mental. Uno no solo tiene que actualizar una base de código, sino que también tiene que crear un nuevo mapa mental sobre cómo pensar en el marco actualizado.

Otra razón sería porque el proceso de actualización no crea una nueva funcionalidad y eso no se percibe necesariamente como valor comercial, por lo que los desarrolladores se verán presionados por los gerentes, lo que generará estrés.

Además, cuando un marco como Angular creado por una institución como Google cambia su forma de pensar tan drásticamente, uno podría cuestionar la confianza que se puso en el marco en primer lugar.

Es un cambio radical, lo que significa que el código escrito en las versiones anteriores del framework deberá ser completamente renovado para adoptar completamente 2.0. Eso significa que se gasta más dinero volviendo a escribir el código de trabajo, más tiempo de desarrollador dedicado a aprender los matices de la nueva funcionalidad y una preocupación adicional por las violaciones de seguridad más antiguas que pueden no solucionarse si una empresa decide no actualizar. En esencia, esta elección del equipo angular le va a costar a mucha gente mucho dinero sin una razón real.

La razón principal es que la mayoría de las inversiones realizadas por el desarrollador individual (aprendizaje, escritura de aplicaciones, implementación y envío de productos) desarrolladas en la versión pre 2.0 no serían * completamente * compatibles con la implementación planificada para AngularJS. Eso significa: cambio (independientemente de si es realmente para mejor), que viene junto con él, nuevas curvas de aprendizaje, muchos escenarios de rascarse la cabeza durante el desarrollo y la idea de mantener productos construidos en un marco que debería haber sido similar, pero es probable muy diferente.

La gente generalmente tiene miedo al cambio, pero creo que la transición será más suave de lo que la gente teme. De acuerdo, hay varios cambios importantes … He agregado algunas ideas más aquí: Pensamientos sobre Angular 2.0
Siempre adopto el enfoque de limitar mi dependencia a un marco específico para casos en los que agrega valor directo. Mantener la mayor parte de su lógica de dominio en JavaScript simple hace que el código sea más portátil, incluso entre marcos.

La gente está molesta porque el equipo de Angular se está acercando a esto al tratar de forzar a las personas a migrar de 1.xa 2.x (es decir, lentamente no admite 1.x). Angular 1.x ha crecido enormemente en los últimos años y muchas corporaciones / compañías lo han adoptado para realizar inversiones a largo plazo en sus proyectos y en su base de código, y este cambio básicamente indica una pérdida de fe en el equipo de Angular al poder apoyar esa estabilidad del marco.

Personalmente, creo que el mejor enfoque aquí podría ser continuar apoyando Angular 1.x (con su marco actual, sintaxis y JS obstinado). Y para llamar al nuevo Angular 2.0 algún otro nombre de marco. No estoy seguro de por qué Google tomó la ruta de Python 2.0 / 3.0 (de hecho, creo que el cambio Angular 1.x / 2.x tiene cambios mucho más drásticos que Python 2.0 / 3.0). Cambiar el nombre a otro nuevo marco podría haber llevado a una publicidad menos negativa hacia este problema y mantener un mayor nivel de confianza con el equipo de Angular.

Quizás, Google sabe que Angular es tan exitoso y quiere llevar su buen éxito a la próxima generación. En general, mi plan es seguir construyendo proyectos en 1.xy cuando se anuncie Angular 2.0 a fines de 2015-2016, lo aprenderé y lo usaré como un ‘nuevo’ marco. Afortunadamente, la solución real a este problema es el soporte continuo de 1.x, mientras que Angular 2.0 se vuelve a anunciar como un “nuevo” marco.

Creo que en su mayoría solo las personas se quejan porque es nuevo.

Las personas detrás de Angular son muy inteligentes y se preocupan profundamente de que continúe viendo una adopción generalizada. Personalmente, confío en que ahora están tomando buenas (y difíciles) decisiones, que fortalecerán el marco a largo plazo.

Mucha gente se quejó de Angular cuando recién estaba comenzando, específicamente que había mucho marcado en las plantillas. Con el tiempo, los desarrolladores tuvieron la idea de extender html con directivas de estilo declarativo. Creo que sucederá algo similar con Angular 2.0 con los mismos tipos de quejas.

Angular Team debe renombrar Angular 2 con otro nombre que no sea “Angular” porque es totalmente diferente, aprender Angular 2 es como aprender un nuevo marco para aquellos que comenzaron con Angular 1.x …

Angular 2 es tan complejo y totalmente diferente si lo comparamos con Angular 1.x, y la mayoría de los desarrolladores corren el riesgo de cambiar o abandonar Angular por otro Framework Javascript …

Después de las noticias sobre Angular 2, los desarrolladores de Angular 1.x no están asegurados y el riesgo es que Angular pierda popularidad y confianza