¿Es el artículo ‘has arruinado JavaScript’ un argumento sólido contra Angular.js?

Angular está bien.

Sí, estoy de acuerdo con el artículo original de que Angular tiene una herencia Java obvia que es más fuerte de lo que necesita y debería ser. Fábricas (patrón de método de fábrica) es un patrón que es muy común en la mayoría de Java debido a su naturaleza muy estructural, pero en JavaScript es raro que necesite usarlos, y en realidad es más un olor a código si se encuentra haciendo fábricas. Sin embargo, este es solo un aspecto de Angular y, en general, es mucho mejor que lo anterior y Angular es un paso necesario para evolucionar JavaScript.

Lo bueno de JavaScript es que es increíblemente elástico. Puede codificarlo de la forma que desee. Son pocos los idiomas donde realmente implementas la clase.
Este es también uno de los aspectos más problemáticos de JavaScript: a diferencia de Java o .NET, no existe una forma idiomática obvia de codificar JavaScript. Cuando alguien nuevo en JavaScript pregunta “¿Cómo se hace una clase?” la respuesta es algo así como “¿Cómo quieres hacer una clase? ¿Y tal vez no quieres hacer una clase en absoluto ?”

Angular es mejor que lo anterior y Angular es un paso necesario para desarrollar JavaScript.

JavaScript tiene un reinado aparentemente inevitable como el rey de los lenguajes de scripting, por lo que muchas personas acuden a él. El problema es que JavaScript en sí mismo no ofrece orientación sobre cómo escribirlo, por lo que las personas buscan en otro lado al comenzar. Aquí es donde ingresó Google, con Angular. Ofrece una forma clara y familiar de lidiar con la creación de aplicaciones JavaScript. Está construido por Google, lleno de reyes de Java de ingeniería excesiva, por lo que seguramente tendrá al menos algunos FactoryProviderProviders, pero está bastante bien. Angular ofrece una forma decente de estructurar sus aplicaciones. Al menos es un gran paso adelante de Google Web Toolkit (GWT), su antiguo monstruo de Java. También es un paso adelante de Backbone, que antes tenía esta corona, que prometía minimalismo pero en realidad tendía a dar como resultado bases de código sorprendentemente grandes.

Al igual que pasamos del hackeo aleatorio a los complementos de jQuery a Backbone a Angular, creo que la cultura en torno a JavaScript evolucionará nuevamente en un año o dos, y dejará atrás nuestros servicios AngularFactoryProviderFactoryEnterpriseServices.

Plug descarado: si te gustan mis divagaciones sobre la programación en Quora, puedes disfrutar de mi programa de YouTube: Fun Fun Function

Una de las cosas que sobresale de ese artículo, y quizás un poco de las respuestas de Stack Overflow, es lo que podría interpretarse como una falta de comprensión de para qué sirven las tres cosas en cuestión.

Después de todo, como Rob tomó de “los malditos documentos angulares”, “para hacer un mundo hola, primero debes crear un servicio hello world para crear la fábrica hello world para crear el servicio hello world [sic] para que puedas imprimir hola mundo en la pantalla “.

Eso, por supuesto, no es obligatorio en absoluto. Puede inyectar el texto “hola mundo” en cualquier capa de su aplicación que desee. La mayoría de las aplicaciones elegirían obtener el texto de un servicio , que obtendría el texto de una llamada HTTP (usando el servicio $ http).

Las capas adicionales, a saber, las fábricas y los proveedores , se incluyen, según mi estimación, para facilitar la arquitectura de una escala más amplia y, a falta de una mejor palabra, escala empresarial solicitud.

Suerte. Puede usar fábricas como definiciones de clase, para crear instancias de servicios con diferentes datos de origen. Los servicios creados de esa manera serían instancias únicas que comparten una interfaz común.

Proveedores. Si desea diseñar su aplicación como un módulo reutilizable, con una API interna, puede usar proveedores para hacerlo. Puede (y debe) diseñar que su proveedor se pueda configurar a través de una interfaz estándar, donde sea que se use. Las aplicaciones que utilizan su módulo elegirán la interfaz real de las fábricas (y / o servicios) que su proveedor … proporciona .

Si todo lo que quiere es un SPA simple con enlace bidireccional, enrutamiento y quizás algunas de las otras características (inyección de dependencia, separación de preocupaciones), puede hacerlo. Solo usa los servicios .

Si desea crear un módulo empresarial robusto y altamente configurable para ser reutilizado en su empresa global, bueno, también puede hacerlo. Querrás usar proveedores .

Sí, pero el artículo no es una racionalización sólida. Sin embargo, su base para la objeción es sólida.

Para ampliar las observaciones de los autores:

Principalmente, ECMA Script (JS) es ampliamente accesible debido a las características únicas y vanguardistas de OO que casi nadie entiende con un legado clásico de OOP (independientemente de la lengua). Estas mismas características hacen que el lenguaje sea bastante exitoso debido a un factor de simplificación “aparente” inicial, que se encuentra en una inmersión más profunda, bastante complejo desde una perspectiva de POO basada en la clase. El lenguaje de secuencia de comandos ECMA proporciona un modelo de herencia prototípico con todas las funciones, acoplamiento flexible y escritura dinámica que admite objetos sin clases. Tienes que comprender los problemas con los constructores y el modelo clásico antes de que todo esto tenga sentido para ti. La motivación central de un modelo de herencia nuevo y diferente es evitar que los desarrolladores se diseñen en una pequeña caja de vidrio. Esta es una sutileza de diseño de SLDC rara vez observada por los desarrolladores que construyen y caminan de microproyecto a microproyecto.

Muchas lunas antes que tú y yo, los problemas del desarrollo de aplicaciones enriquecidas con lenguajes de programación clásicos fueron abordados por una larga lista de nombres altamente respetables en el mundo de la ingeniería de software. Fundaron conceptos de programación orientados a objetos como Abstraction of Concerns, MVC, Close Coupling; todo dentro de las limitaciones de los lenguajes clásicos, y expuso una serie de limitaciones dentro del modelo clásico. Prácticamente rogando por Prototypal. Luego vino JavaScript (nota: “Java” en el nombre original era solo para fines de marketing, y no tiene nada que ver con los conceptos básicos de lang). Angular parece estar haciendo un esfuerzo valiente (o insensato) para demostrar que todos están equivocados.

Angular, ha ganado el 90% de su popularidad porque proporciona una vía férrea para que los desarrolladores creen una aplicación web sobre quién de otra forma tendría dificultades sin una guía precisa. Su popularidad tiene poco que ver con los patrones apalancados centrales o los antipatrones y su cuestionable conveniencia. Angular, en su estado actual, honestamente debería escribirse en Ruby.

Un síntoma de la resistencia natural al cambio.

Adopta NUEVA tecnología y adopta el modelo de herencia prototípica. Hay algunas observaciones bastante astutas en el mantra funcional. Deseche el constructor y la clase, y use objetos dinámicos como se pretendían. O no, y nunca aspires a algo mejor.

PD: Cualquier marco que vincula las manos de un desarrollador, está implícitamente diciendo al desarrollador “eres demasiado estúpido para saber lo que estás haciendo aquí”. Lo cual es cierto y aceptable para muchos desarrolladores sin experiencia.

Servicio, Fábrica y Proveedor son palabras utilizadas dentro de la informática para describir ciertos conceptos. Al igual que un lingüista usa palabras como “verbo” y “sustantivo” para describir conceptos dentro de un lenguaje natural. El escritor Rob Ashton ahora dice: “Siempre usé bien el inglés, y ahora alguien está hablando de estos verbos y sustantivos. Al diablo con ustedes, me voy a casa”.

AngularJS está muy bien hecho y es muy inteligente. Puede suponer fácilmente que los fabricantes saben de qué están hablando. Creo que Rob Ashton se está rebelando contra las personas que obtuvieron un título en informática.

En mi opinión, el artículo al que se hace referencia es material de baja calidad, y no dice mucho más allá del argumento habitual que usan los desarrolladores de JavaScript menos calificados cuando atacan AngularJS (o cualquier otro marco / herramienta más avanzado).

Es un hecho que la mayoría de los desarrolladores de Javascript no tienen una formación adecuada en ingeniería de software, ya que el lenguaje les ha dado los medios para arrancar aplicaciones simples de manera rápida y fácil, y la mayoría de ellos están contentos de poder intentar piratear todo sin pensar nunca en una estructura adecuada o diseño de software.

Esto es perfectamente aceptable para pequeñas aplicaciones de interfaz de usuario o proyectos personales, pero en el mundo corporativo generó hordas de bases de código de aplicaciones altamente inconsistentes y poco mantenibles que nunca pueden ser refactorizadas adecuadamente.

Esto planteó enormes inquietudes a los departamentos de TI e ingeniería de todo el mundo y le dio al lenguaje Javascript (uno de los IL más potentes que existen [sí, considero que JS es un IL]) una mala reputación.

Los marcos como Angular aparecieron porque, aunque piratear la interfaz de usuario es simple y puede parecer gratificante a corto plazo, con la creciente complejidad de las aplicaciones de interfaz de usuario, y muchas empresas utilizan sus aplicaciones web como una herramienta para obtener una ventaja frente a la competencia, al tener bases de código que impiden (o ralentizar) el negocio de agregar nuevas características críticas no es una opción.

Es divertido porque aunque piratear la interfaz de usuario es bastante simple, a menudo sucede que las aplicaciones de la interfaz de usuario son mucho más complejas que sus contrapartes de back-end. Cuando se combina un enfoque de diseño simple / inconsistente con un problema altamente complejo, es exactamente cuando aparecen bases de código desastrosas.

Las IU tienen estado por naturaleza, ya que el estado de la IU es lo que el usuario está mirando y cambiando cuando usa una aplicación web (o cualquier otra IU). Las aplicaciones de fondo no tienen estado en un gran porcentaje de los casos, con el estado de fondo viviendo en la base de datos, por lo que administrar la complejidad de los cambios de estado se convierte en el problema principal de las aplicaciones de IU grandes.

Las estrategias / herramientas de administración de estado como ui-router, redux o mobx se han introducido con el tiempo a medida que más y más desarrolladores se dan cuenta de que las aplicaciones de interfaz de usuario complejas necesitan orden y no caos. Estos también tienen curvas de aprendizaje empinadas para desarrolladores aficionados, no solo AngularJS.

Para finalizar, no se trata de OOP vs FP, ya que Angular (especialmente combinado con TypeScript) brinda a los desarrolladores la capacidad de sacar lo mejor de OOP cuando es necesario, sino también de sacar lo mejor del paradigma FP. Diferentes problemas pueden tener diferentes soluciones y es bueno poder tener más herramientas en su haber como desarrollador, lo que me hace pensar que los desarrolladores que no quieren tener más opciones son simplemente vagos y temen aprender cosas nuevas.

En general, depende del caso de uso, pero si la construcción de una aplicación que necesita tener su base de código escalable, mejores herramientas, como la que ofrecen Typecript, Angular (u otros marcos / bibliotecas de interfaz de usuario) y Redux (u otras estrategias de administración de estado) funcionan excelente a largo plazo, incluso para aplicaciones masivas, por lo que es muy recomendable.

No. No estoy de acuerdo con ese argumento.

La razón principal por la que JavaScript es tan popular para las secuencias de comandos es por su elasticidad. Convenido. Pero hay una limitación sobre qué tan elástico puedes ser. Siempre hay una necesidad de coherencia cuando codifica sin importar lo que codifique. Si bien agregar fractory a su código está mal. Ese es solo uno de los muchos aspectos de angular.

Una de las cosas más importantes sobre angular es que mejora el HTML ya utilizable.

Como cualquier desarrollador web sabe, HTML es estructura, CSS es diseño y JS es interacción del usuario y hace uso de la estructura real. Pero incluso el JS tiene que depender del HTML y eso es lo que angular nos ayuda a hacer. Nos permite manipular HTML y aprovechar lo mejor de casi todos los elementos que componen su página.

Y más que cualquier otra cosa. Es un marco que está destinado a agregar el JS. Si no es algo que desea, no lo use. No se le puede obligar a usar un marco. Cuando JQuery entró por primera vez, todos lo odiaban. Ahora, a la gente le encanta y no puede prescindir de él. La industria evoluciona y usted tiene que evolucionar con ella.

Angular es bueno si quieres crear una aplicación web compleja

AgularJS es un FW donde, como JavaScript, es un lenguaje que el navegador puede entender.

Si está hablando de JS, ¡entonces qué puede pensar de TypeScript! ?

Todos son buenos / malos dependiendo del contexto y la aplicación que elija los correctos.

No hay forma de comparar un marco con un idioma.

No estoy de acuerdo con los argumentos presentados en el artículo.
Los marcos angulares y otros similares han aportado una estructura muy necesaria a las aplicaciones de JavaScript. Di lo que quieras sobre las fábricas u otras construcciones angulares, pero creo que los beneficios superan con creces las desventajas. Un concepto clave en Angular y otros marcos MVC es JavaScript desacoplado que simplifica enormemente las pruebas unitarias. Es decir, el JavaScript se desacopla de la vista y es tan fácil de consumir desde una prueba unitaria como una vista.

A medida que las aplicaciones crecen en complejidad, las pruebas unitarias se vuelven increíblemente importantes para garantizar una aplicación exitosa a lo largo del tiempo. Ir con una arquitectura desacoplada hace que sea mucho más fácil escribir pruebas unitarias realistas. El principal beneficio es que puede escribir pruebas que usan su JavaScript de una manera muy similar a la que usará la vista.
Este es un cambio en la comunidad de JavaScript donde escribir código teniendo en cuenta las pruebas unitarias es un concepto relativamente nuevo. Sin embargo, estoy muy contento de ver que cada vez más personas lo aceptan.

Lenguajes como Java y C # han adoptado código comprobable durante 10-15 años y los patrones de esas comunidades se prueban realmente en batalla. Estoy básicamente en desacuerdo con la idea de que JavaScript es un hombre extraño y de alguna manera no es compatible con patrones como MVC e ideas de Java o lenguajes similares.

JavaScript ciertamente tiene algunas características únicas, pero ninguna que nos impide tratarlo como cualquier otro lenguaje de programación. De hecho, las adiciones a JavaScript desde ES6 están empujando a JavaScript aún más en la dirección de Java.

Adoptar la idea de escribir JavaScript con las pruebas en mente ha sido el factor más importante para mejorar la calidad de mi código JavaScript. Esta idea no es exclusiva de Angular, pero seguir Angular lo lleva en esta dirección.

No.

Lo que este tipo se está quejando tiene poco que ver con Angular, más con el uso de lenguajes sin tipo y sin entender DI. Ah, y agrego un poco de frustración con el software Enterprise (que generalmente está hinchado, BS loco la mayor parte del tiempo, estoy de acuerdo)

Primero, el artículo se centra en un aspecto estrecho de Angular JS, es decir, algunos patrones utilizados en la DI. Puede que le guste o no la inyección de dependencias, pero le permite a uno crear aplicaciones modulares en lenguajes como JS y Java * y * saber en el momento del inicio, antes de ejecutar la aplicación, si está conectada correctamente. Entonces, hay una buena razón para las fábricas, etc.

Y honestamente, tengo un problema con Angular, que es similar a los problemas que tengo con Django. A saber: la gran cantidad de ‘magia’ que necesitas entender, o decir, es otra forma, necesitas aprender mucho antes de que puedas ser completamente competente con Angular.

Si no te gusta esto, prueba Reaccionar. Es comparable, pero conceptualmente mucho más simple. Todo es solo código. También hay Polymer que resuelve los problemas de espaciado de nombres HTML / CSS y, al mismo tiempo, agrega enlaces de datos reactivos.

Llegando al punto principal, una y otra vez el código * declarativo * ha demostrado ser más comprensible y mantenible a largo plazo. Puede quejarse de las fábricas de proveedores, claro, pero luego usar STFU y usar un lenguaje con * posibilidades reales * de abstracción * y * compatibilidad con el compilador para verificarlas (verificación de tipo potente), como Haskell.

Si no lo hace, aparecen elementos como proveedores porque su idioma no puede expresar una función que devuelve una función que crea un foo.

Bueno, tal vez sí, pero ¿puede verificar su tiempo de ejecución si se usa correctamente? En JS puede expresar esto, pero no hacer que lo compruebe el compilador.

Tal vez también es el estilo de programación en el que se escribe mucho angular. Tiendo a necesitar raramente construcciones tan locas, porque generalmente escribo en un estilo inmutable y funcional, evitando OO, etc.

FWIW mi consejo para ese autor debería ser simplemente aprender más Angular y posiblemente reaccionar y dejar de quejarse de estos detalles.

Estoy de acuerdo en que Angular apesta un poco, pero es una de las formas más increíbles de poner en marcha los front-end modernos. ¡Me ahorra mucho trabajo!

No es más un argumento sólido contra AngularJS que “C ++ le permite perder memoria si lo usa mal” es un argumento sólido contra C ++. El autor señala las respuestas de stackoverflow para construir la carne de su punto original, pero no aborda la tecnología directamente. No intentaré afirmar que AngularJS es un bastión perfectamente diseñado de bondad de JavaScript, pero escribir que ha arruinado JavaScript es juvenil y muestra una falta de visión. Después de todo, nadie realmente lo está obligando a usar Angular, y si está obteniendo suficiente tracción para ser un tema de discusión cotidiana, entonces, tal como con betamax, la popularidad de la adopción está desafiando la excelencia técnica (o la falta de ella) del producto.

En general, me recuerda mucho a esto:

Absolutamente no. Como muchos sabrán quién lee mi blog, solía ser dulce en Angular a pesar de que era abusivo. En estos días encuentro que los frameworks de nueva generación como Aurelia e incluso bibliotecas como React.js son mucho mejores.

A menos que me equivoque, la especificación de Javascript no busca inspiración en Angular cuando se trata de ideas de propuestas de especificación (excepto tal vez Object.observe, que recientemente se eliminó de la especificación). Sí, Angular definitivamente alienta algunas cosas malas y sí, es un marco intrincado que ha vuelto algunas de nuestras cabezas: ¿arruinar Javascript? Ningún marco puede hacer eso.

Las únicas personas que pueden arruinar Javascript son las del comité TC39 responsables de la especificación ECMAScript. Pero el proceso es largo y las propuestas están sujetas a escrutinio en cada paso del camino. Dudo que suceda alguna vez (a menos que le preguntes a algunas personas sus opiniones sobre las clases de ES2015).

Angular apesta en comparación con las opciones más modernas, pero no dañó Javascript. En todo caso, creo que ayudó a dirigir Javascript en la dirección que está yendo ahora al mostrar que podría hacer más en el lado del cliente y menos en el lado del servidor.

Realmente no. Por supuesto, usar servicios y proveedores para una aplicación sencilla de hello world sería una locura, pero si estás usando AngularJS para una aplicación con este nivel de complejidad, ¡estás loco!

Los marcos se crean para facilitar la tarea. AngularJS está aquí para facilitar la creación de aplicaciones front-end y una aplicación tiene componentes y partes que pueden tener el mismo aspecto pero con propiedades diferentes. Por lo tanto, necesitaría una identidad básica y una configuración para personalizarla. Si bien estas configuraciones son realmente útiles en este nivel de complejidad, no es aconsejable usarlas en proyectos más simples.

JavaScript solía ser un pequeño lenguaje de secuencias de comandos que la gente solía mostrar esquinas redondeadas y animaciones y, por lo demás, no tenía ningún estándar sobre cómo usarlo (creo que en algún lugar en el camino alguien dijo “son solo 50 líneas de código , ¡atorníllelo! “) pero ahora mismo realmente necesitamos algún estándar para guiar a los recién llegados a cómo escribirlo

No. El artículo exagera la complejidad del proveedor, servicio y fábrica, y en particular el proveedor Proveedor y proveedor Fábrica. Básicamente, no existe un proveedorProveedor y un proveedorFactory. Solo hay proveedores. El servicio y la fábrica son atajos para exactamente lo mismo.

Detrás de cada cosa inyectable hay un proveedor que lo proporciona. Cuando declara un proveedor, describe todo lo que lo inyecta (que puede configurar en el momento de la configuración antes de que la aplicación se haya iniciado por completo). Cuando declara un servicio o una fábrica, simplemente describe lo que desea inyectar, y Angular crea el proveedor para usted (que ni siquiera sabrá, a menos que un mensaje de error lo mencione).

Eso es básicamente eso. El artículo entra en pánico sobre mucha confusión innecesaria.

¡Angular es asombroso!

Pero, trae demasiados conceptos de OOP a la tabla que podrían no ser necesarios en javascript . Y no estoy hablando de un simple ejemplo de hola mundo.

Supongo que todos sabemos que cualquier aplicación de JavaScript compleja de tamaño mediano requerirá ciertas abstracciones para que el código sea más fácil de mantener y escalable. Pero algunas de las características angulares (como la forma en que la DI implementada) es demasiado.

Me gustaría que no intentaran resolver el problema de la dependencia , creo sinceramente que commonJS + Browserify funciona mejor en ese sentido: proporciona un código más limpio sin una sintaxis de matriz incómoda para las dependencias.

Las pruebas unitarias con commonJS son tan agradables y simples como con AngularDI, sin la necesidad de un contenedor DI.

Supongo que los conceptos no son el problema, tal vez la forma en que se usan / hacen cumplir.

Me gustaría que el equipo angular adopte los patrones de módulos commonJS como lo hace React. Supongo que se darán cuenta de cuánto trabajo innecesario están haciendo.

¿Quizás Rob Ashton pueda aconsejar al equipo angular de JS diciéndoles cómo mejorarlo?
Mi vida se vuelve más fácil con Angular JS, como lo que hizo jQuery anteriormente.
Respeto su opinión, pero no es lo suficientemente válida como para evitar que la comunidad la use 🙂 o yo … Como Mattias Petter Johansson dijo que JS es elástico, y que a veces no se puede restringir, solo son pautas.

No estoy de acuerdo y ningún marco puede arruinar Javascript, ya que es una plataforma de construcción para cada marco.

A pesar de que aparecieron muchos marcos, JS tendrá su propia característica única de personalización.

“¿Qué puedes construir con JS?”

“¿Qué no?”

T&C Apply.

No creo que sea el argumento correcto. Ningún marco está arruinando JavaScript. Son las personas que son superficiales, obstinadas, que no pueden superar las deficiencias y aprovechar el idioma que lo hacen.

Para ser caritativo, en el pasado la documentación de Angular en ocasiones me hizo sentir ganas de escribir blogs similares. Me abstuve, porque mi frustración estaba con los documentos , no con la biblioteca . De hecho, los claros beneficios de Angular probablemente aumentaron la frustración.

En estos días, los documentos parecen mejores de lo que eran. O tal vez acabo de superar esa curva de aprendizaje inicial.

Creo que estos artículos provienen del sentido en que la gente tiene que el lugar de Angular en el ecosistema JS está muy por encima de sus méritos técnicos. Para mí, no fue el Angular lo que arruinó Javascript, sino la gente de administración que se metió en este carro de Google y forzó el proyecto en el que trabajé. Esa podría ser otra razón para este tipo de artículos.