AngularJS agora é ruim???

[hugodutra-zz]

Amigos gostaria de criar um post polêmico ae.

Tem um tempo ae que tenho visto muita gente espinafrando o Angular, tanto 1.x quanto o 2.

Queria saber pq não usar o Angular e quem for #teamangular dizer pq devo usar ainda.

E o que quem não curte Angular tem usado como alternativa para MVC. Ainda Ember e Backbone?

Já dá pra botar fé no Mithril em relação a comunidade e manutenção do projeto e talz?

Enfim, digam ae.

cc: @afonsopacifer @raphamorim

[afonsopacifer]

Então, ainda não mexi com Mithril.

Sobre angular, eu acho que o 1x ainda é muito usável sim, o 2x será ainda mais, porem como o 1x teve uma adoção bizarra, ele vai ficar por ai muitos anos ainda, assim como existe jquery 1x e 2x e eles convivem.

Ember e Backbone tem seu charme, principalmente ember, mas Angular é basicamente uma escolha melhor para estudar (não estou dizendo para usar, mas sim estudar, por ter mais mercado bla bla)

[woliveiras]

Acho que o problema com AngularJS, hoje, é o mesmo do jQuery: A galera usou de qualquer jeito e agora ficam reclamando. kkkkk

Não vai demorar pra alguém começar a reclamar do próximo Framework que estiver na moda.
React mesmo, logo logo o povo começa.

É interessante ver como a comunidade vai do zero a cem com as libs e frameworks e depois começam a falar mal delas e isso nunca vai acabar. E é são até bem vindas essas mudanças, pois sempre vem algo melhor e melhor e melhor... 🙌

A melhor escolha para cada projeto varia de projeto para projeto. Não é Angular algum outro que vai ser bala de prata, que iremos usar pro resto da vida.

Coisas novas e boas nascem todos os dias. Se ficarmos pensando em usar somente um, nunca vamos provar outros sabores da vida pow. 😄

Angular não é ruim, assim como os outros também não são. Só que cada pessoa gosta de algo em específico de cada lib e defende ela com unhas e dentes por isso. O bom mesmo é não defender ninguém e saber tirar proveito de cada uma.

[bernardocs]

Eu discordo (em parte) da sua primeira afirmação, @woliveiras ...
Concordo com o fato de que a comunidade usa os frameworks e/ou libs de forma abusiva e desenfreada.

Agora... dizer que Angular é bom é, na minha opinião, forçar muito a barra...
O Angular tem um problema muito simples e que mata qualquer tipo de framework/lib: inversão de controle.

Você não controla sua aplicação... você fica escravo da estrutura e funcionamento da lib/framework. O Angular é um exímio exemplo disso (fora os problemas estruturais, overheads, etc).

Eu uso no trabalho pois a estrutura do projeto em que trabalho atualmente já usava Angular, mas não suporto quando penso em algo que seria ridicularmente fácil de fazer mas o Angular não me permite pois eu tenho que me render ao Angular way de fazer as coisas.

Note que, uma coisa é você seguir o padrão de uma lib e ainda conseguir usar seus padrões sem muita dificuldade. Outra coisa é você ser obrigado a seguir o padrão pra manter o funcionamento do framework e não poder fazer algo fora do padrão.

Lembre-se sempre que padrão são legais e foram feitos para resolver problemas conhecidos e para serem seguidos... mas não resolvem tudo.

Acho que fundamentei o suficiente para afirmar que aposto bastante nessas microlibs que fazem apenas o necessário e não o deixa preso a toneladas de funcionalidades que você nem usará.

[leonascimento]

@hugodutra já vi muito projeto massa feito com Angular, vejo boas práticas aplicadas neles, mas vejo muitos projetos feios, acho que nenhum framework ou lib não é a bala de prata, não tenho muita experiência só participei de pequenos médios projetos com Angular na empresa, com React participo de um projeto de grande porte e percebi alguns pontos, mas isso depende de alguns parâmetros.

• Prazo
• Performance
• Escalabiliade

Tudo é feito com um propósito lógico, no meu ponto de vista se você vai fazer um MVP eu adotaria Angular mesmo por ser rápido.
React é muito lindo eu curto porque usando ES6 fica mais lindo ainda, você tem mais liberdade eu me sinto bem quando estou codando usando React+Redux+ES6, mas vejo que por ser uma lib e não framework você tem que implementar mais coisas na mão, então isso custa mais tempo, exige mais da equipe embora você ganha no futuro no quesito performance e escalabilidade.

Admiro muito quando a galera faz componentização e modularização usando Angular, se o cara sabe fazer o bom uso e tirar proveitos dos recursos que o framework tbm admiro muito.

Mas tem coisas que acaba custando caro, concordo em partes com o nosso amigo @bernardocs citou no Angular vc fica muito preso a lógica do framework.

Eu estava discutindo isso com o meu gerente ele falou me ensinou que não existe a melhor tecnologia, existe a tecnologia que se encaixa pra atender uma necessidade que você possui em determinado projeto. Isso vale pra linguagens, ferramentas editores.

Aprendi que antes de adotar uma nova tecnologia pesquise por duas perguntinhas

"why don't I use ____?"
"Why do I use ____?"

você pega os pontos negativos e positivos de cada.

[woliveiras]

Então @bernardocs, mas tem gente que busca exatamente isso em determinados Frameworks.

Obrigar a equipe a usar aqueles padrões da lib, não se preocupar com nada e deixar tudo nas mãos da ferramenta (não que esse tipo de comportamento seja bom, né? kkk).

Tem cara que só de imaginar em ter de controlar Data Binding na unha já entra no modo Danger, então pensa...

Cada Frame atende um perfil de Dev e Projeto.

No caso, a forma como você falou só confirma minha argumentação de que o Frame agrada determinados perfis e projetos.

O Angular, no seu caso, não te agrada. Só por isso ele é ruim?

Esse é justamente o motivo pelo qual a comunidade se perde nessa chuva de libs, por que nós não gostamos de algo e saímos gritando aos ventos que ele não presta. Mas não é que não presta, só não agrada o nosso perfil.

É o mesmo que usar Rails ou Django e falar que eles são ruins por que um dev ou outro não gosta de ter de trabalhar com a forma como eles obrigam a trabalhar.

Quer um exemplo?

Eu detestei a forma como JSX é escrito e odiei a forma de escrever CSS no React. Já sai espalhando aos ventos que o negócio não era tudo isso. Só que acabei percebendo que é uma ferramenta boa sim! Só não me agrada a forma com a qual ela trabalha uai. 😄

Imagina se eu tivesse escrito um post no meu Blog falando mal de React??? Essa comunidade aqui iria me expulsar!! UHAUHAHUAUHA

[raphamorim]

Bem eu acho que ambos são overrated.

Não existe como comparar React com Angular, um é lib para componentes onde seu código chama, outro é Framework e ele próprio chama o código. São vertentes totalmente diferente.

A verdade é que angular surgiu de uma promessa que morreu, o 1.x é estável mas era filho de diversas promessas como usar object observe nativo sem polyfill no futuro. Ele é pesado, porém estável. Agora é aquilo, tu usar um framework que te da liberdade de fazer compile de string e outras críticas pesadas que eu/e uma galera carrega, porque o mercado de trabalho ta usando ta usando é uma opção (pessoalmente não gosto dessa opção).

Mas também não gosto de "cagar" regra em tech, acho sim, o Angularjs 1.x ruim por motivos meus.

Mas cada um tem que aprender a pensar por si só e definir o que é positivo e negativo no uso de ferramenta x.

Ex: Eu acho ruim usar Riot.js pq faz virtualDOM com string, mesmo sendo leve e existe gente que pensa o contrário, pois ganha no pageload.

É errado dizer que qualquer ferramenta é ruim, a menos que faça uso de práticas ruins dentro da linguagem.

[lagden]

Framework foi feito para facilitar no desenvolvimento. Se está ruim é porque aquele framework não serve para aplicação que você está desenvolvendo. É como tentar colocar um parafuso na parede usando o martelo!! Você até enfia na parede, mas vai ficar um 💩!!

Limitações
Usei bastante o Symfony na era PHP, as vezes passava raiva por causa de um componente do framework que não fazia a coisa mais idiota do mundo!!

Client Side
Apenas fiz alguns labs utilizando Angular e React, ou seja, nada em produção!!
E pra falar a verdade eu não gostei muito, pois sempre acabava chegando nos mesmos problemas que tive no Symfony (coisa simples se tornava a coisa mais trabalhosa de se fazer).

Well, VanillaJS rulezz!! 🤘
E só pra vocês não acharem que eu sou xiita, eu curto um Meteor

PS... com Meteor você pode utilizar Angular, React, Vue, etc...
PS2... e somente（。 ㅅ 。） são polêmicos!!!
PS3... e só para provar que estou certo sobre o Vanilla https://aerotwist.com/blog/the-cost-of-frameworks/

[kazzkiq]

To aproveitando muito com a discussão e as opiniões! Muito boas!

Continuando na mesma linha do @raphamorim, eu também acho que cada caso é um caso e não existe bala de prata. As vezes uma determinada tecnologia se encaixa melhor no seu projeto, e em outro caso outra tecnologia "rival" seria mais interessante naquele contexto.

Eu particularmente odeio frameworks e bibliotecas que levam o conceito de convention over configuration ao extremo. Eu não gosto de ficar amarrado as metodologias do framework. Gosto de poder usar o que imagino ser mais eficiente para a tarefa. Por isso, no meu caso libs mais minimalistas como o Vue.js ou Riot.js são mais interessantes já que elas não ficam introduzindo sintaxes, metodologias e arquiteturas próprias. Usando libs menos "engessadas" eu consigo ter mais liberdade de decisão sobre a arquitetura do meu projeto.

O problema que eu vejo é que o Angular e React caíram nas graças das startups, e isso acaba "forçando" a gente a aprender essas ferramentas e todo o contexto que as rodeia. Se não fosse por isso, acho que eu nunca me forçaria a aprender React e sua horrível maravilhosa sintaxe JSX, por exemplo.

(assumir não gostar de React deve ser algo profano e perigoso de se fazer hoje em dia, mas sou v1d4lok4 mesmo hauahua)

[lagden]

@kazzkiq na verdade não é que caíram nas graças...
é que os dois são projetos das empresas top (Google e Facebook)...

by the way... eu adorava escrever em CoffeeScript

[woliveiras]

O artigo que você compartilhou é do caraio ein @lagden! Show de bola.

[bernardodiasc]

Bom mesmo é Elm 🔥

[danilovaz]

Eu compartilho da opinião de que não existe bala de prata. Cada projeto um projeto, cada caso um caso.

Nesse contexto, ser "ruim" é muito subjetivo. Existem N fatores e para cada projeto esses fatores mudam, então não acho saudável as opiniões que se baseiam em usar apenas 1 framework para tudo, mas opinião é igual...time de futebol, cada um tem o seu de coração 😄

Eu particularmente gosto de fazer um estudo das possibilidades de uso dos frameworks disponíveis para o meu projeto. Hoje, na empresa onde eu trabalho, estamos em processo de migração de uma arquitetura Rails full naquele famoso MVC surubão, para uma arquitetura API + Ember.js. E durante meus estudos para escolher o melhor framework para o nosso projeto chegamos em algumas conclusões:

1 - Ember.js tem um jeito Rails like na hora de programar, o que no nosso caso é benéfico por conta da cultura de Rails dentro da empresa;

2 - O Ember.js "suja" menos o HTML e queríamos montar nosso projeto de tal maneira que se fosse necessário uma migração daqui alguns anos (por qualquer motivo que seja) o esforço gasto em migrar deveria ser o mínimo possível e nisso o Ember (na nossa opinião) ganhou dos demais porque eu posso migrar meu HTML para qualquer outro framework (um control+c / control+v mesmo) apenas removendo {{ code }} e substituindo pelo padrão do outro framework. E isso possibilita focar apenas na camada lógica da aplicação para migrar. "Ah, mas então você já está pensando em migração antes mesmo de migrar para o Ember? Então ele é ruim". Não é isso, considero que é meu dever não engessar um projeto (no nosso caso, uma empresa inteira) por conta do meu ego. Nessa nossa migração de Rails para Ember eu aproveitei 0 da estrutura Rails, ou seja, retrabalho. Agora, estamos montando uma estrutura que no futuro eu possa migrar para qualquer outra tecnologia sem esforço desnecessário.

3 - Apesar de ser Rails like, o Ember não usa o MVC padrão. Ele traz o conceito de components e isso no nosso caso também era muito benéfico. Diria que o Ember está mais para Model Routes Components 😂

Eu levei em consideração os seguintes critérios:

• Performance
• Rotas
• Tamanho (kb)
• Documentação
• Curva de aprendizagem
• Sintaxe
• Manutenção
• Comunidade
• Danilopêndencia

Esse ultímo critério, pode parecer bem idiota, mas tem um fundo lógico e diria que até filosófico. Aqui na empresa, eu sou responsável pelo front. E conto com mais 2 funcionários: Eu e Eu mesmo. Portanto, eu me preocupei bastante em não escolher um framework por gosto próprio e usar da parcimônia para chegar à melhor escolha para o projeto. Não sou um fanboy, eu uso o que tiver que usar para o melhor do projeto.

No nosso total score desses critérios, o Angular ficou com 30 pontos, Ember.js com 36 e React (até porque, React é uma lib, não tem tudo do que precisávamos) com 25 pontos, no total eram 40 pontos e cada critério tinha uma relevância maior ou menor.

"Então você quer dizer que o Ember.js é melhor do que o Angular e o React?". Definitivamente, não. Mas ele foi a melhor escolha para o nosso projeto e creio que esse seja o caminho mais saudável de escolha de um framework do que ir pelos Trendings.

Obviamente, o Angular tem muito mais conteúdo disponível em português do que Ember e a comunidade no Brasil é muito maior, mas não encontrei maiores dificuldades na documentação e nem na comunidade que tem um Discuss: discuss.emberjs.com e esse critério, no atual momento, não tem como "ganhar" do Angular.

Mas nem tudo são flores. O Ember.js possui um ember-cli que te obriga a utilizar o Broccoli e isso é um pé no saco no meu build, prefiro ser livre para escolher o que usar. Mas isso são coisas que já tinha conhecimento prévio por conta dessa "definição de critérios" que citei acima.

O importante, é o que importa! 😂 zoeira, o importante é tentar não ser pego de surpresa pelo framework. Ele trabalha pra você e não você para ele.

[lagden]

@woliveiras o Paul Lewis (Google) é muito xiita, uma vez vi um vídeo dele falando "bem do polymer", só faltou ele dizer: - o polymer é bom, mas prefiro vanilla!!
😆

[hugodutra-zz]

Galera, primeiramente muito obrigado pelas respostas ae, realmente acrescentaram bastante pra mim.

Outra coisa que queria perguntar, ainda sobre AngularJS, é o que vcs acham sobre esse lance dele tá de forçando a usar o typescript nos tutoriais.

Particularmente isso me irrita muito, mas queria ouvir a opinião de mais pessoas.

[diessica]

Nem tudo depende de caso, de projeto, de quem desenvolve... Então nenhuma ferramenta é ruim, ela é do jeito que deveria ser, e depende apenas das pessoas que vão usá-la?

Não entendo por que tudo está sendo tão relativizado. Ciência da Computação não é uma ciência humana para ser tratada com tamanha subjetividade e relativização.

Já produtividade, sim, é um conceito relativo! Você pode ser mais produtivo com A ou com B, e isso é importante na hora de decidir qual framework usar. Aí, pode entrar uma série de fatores, como simplesmente o fato de você gostar mais de A.

...Mas Engenharia de Software não é. Existem ferramentas ruins, que encorajam anti-patterns, implementam conceitos da engenharia de software erroneamente – e isso é independente de projeto ou desenvolvedor.

Se está ruim é porque aquele framework não serve para aplicação que você está desenvolvendo.

Se está ruim, na verdade, existem duas possibilidades:

• Você escolheu errado.
• É ruim.

E reitero que é totalmente possível resolver problemas com uma ferramenta A, mesmo ela sendo ruim.

Vocês lembram por que todos pararam de usar o Prototype.js? Será que é porque "a galera usou de qualquer jeito e agora ficam reclamando. kkkkk"? Não, tal como não é o problema do jQuery ou do Angular. É plenamente possível que uma ferramenta ruim resolva problemas (não é indireta para o jQuery ou Angular), e esse era o Prototype em sua primeira versão: ele estendia objetos nativos do JavaScript, e isso foi uma péssima decisão. Será que é relativo também? Será que é uma boa decisão na opinião de alguém? Pode ser. Mas definitivamente não foi uma boa decisão se pensarmos no ponto de vista do Prototype como uma ferramenta usada em massa, em diversos projetos.

No mais, tenho aversão a cagação de regras. Acredito em escolhas, e o post do @danilovaz é um bom ponto de partida para fazer boas escolhas! :)

[woliveiras]

A comunidade de Front End amadureceu muito desde o ano passado.
Lembro de já ter ouvido respostas bem ignorantes em algumas perguntas que eu postei no passado.
Só tenho crescido, cada dia mais, com esse grupo. 😄
A @diessica me fez repensar um pouco meu conceito do bom para o Projeto/Pessoa e o bom de verdade.
Achava que nada era ruim, de fato, por conta dos aumentos das pessoas sempre serem pessoais contra as ferramentas (como aquele meu caso com React).
Muito foda.

Ainda não vejo males no Angular, mas, depois dessa conversa, fiquei bem mais crítico quanto a bom e ruim.

[napalmdev]

@lfeh, então cara, a impressão que eu tenho é que desde que o grupo mudou-se pra cá(Github), ao menos nas issues que eu acompenhei eu realmente não vi nenhum desrespeito até então, seria a falta de respeito um mal do Facebook?? kkk Zueras a parte, mudar o grupo pra cá foi a melhor decisão já tomada pela comunidade, parabéns a vcs q idealizaram isto, e aos colega que criaram essa rica discussão aqui, que pra mim, tbm foi de grande ajuda.

[yuricamara]

Um problema que tem é que a pessoa usa uma tecnologia e se apaixona. Aí depois fica atacando as "concorrentes" mesmo sem conhecê-las bem. Tb tem os que se fazem de manjador de tudo. E por aí vai!

Eu só considero análises e comparações técnicas, que eu vejo que a pessoa parece manjar mesmo, quando vou analisar qualquer tecnologia antes de começar a estudá-la.

[felipecodes]

Tive uma pequena experiência com Angular 2 e o que eu realmente não gostei foi do TypeScript.

Não entra na minha cabeça essa coisa de tipagem no JavaScript. Mas, o mais sem sentido foi quando eu tentei pegar o .value de um event.target e o TypeScript reclamava por não saber se o objeto event tinha a propriedade value.

A solução era criar uma interface contendo a propriedade e depois implementar a interface no objeto.

Puta trampo sem sentido!

/*
 * custom.typings.d.ts
 * DOM Types
 */

interface DatasetElementAttribute {
  rule: string;
}

interface InputValueEventTarget extends EventTarget {
  value: string;
  dataset: DatasetElementAttribute;
}

interface InputValueEvent extends Event {
  target: InputValueEventTarget;
  getMessage(): string;
}

// on-event handler
_onChange(event: InputValueEvent): void {
    const rule: string = event.target.dataset.rule;
    const value: string = event.target.value;
}

[lagden]

@yuricamara disagree!!
acho que o love faz mal, pois você irá defender com almas e dentes algo que não tem futuro!!

Tecnologia é ir pro lado que dá certo, por exemplo:
O Steve fez o iPhone, mas antes dele existia um SmartPhone feito pela Microsoft + HP, acho que se chamava Pocket PC, que a tecnologia aplicada não pegou! Existem vários exemplos...

Se eles focassem no ES6 faria muito mais sucesso que TS...
Veja a dificuldade do @FelipOliveira no comment acima #174 (comment)
1 linha em puro js se torna um inferno no TS!!!

[yuricamara]

Como assim @lagden ? Não defendi nenhuma. hahahah!

[hugodutra-zz]

Pra agregar:

O @alanhr me passou esse artigo que achei bem foda

http://blog.ng-book.com/introduction-to-redux-with-typescript-and-angular-2/?utm_source=javascriptweekly&utm_medium=email

[lagden]

@yuricamara não disse que vc defende alguma tecnologia!!
estava fazendo um extend!! mas viajei no disagree!!

[alanhr]

@FelipOliveira eu acho que eles estão tentando trazer o melhor da OO para o JavaScript e Interface não é coisa sem sentido é a forma de você ter um contrato com o sua class obrigando que os seus métodos sejam implementados.

@lagden eu não vejo o TS como um inferno, ele tenta bota ordem nas coisas assim como o ES6.

https://johnpapa.net/es5-es2015-typescript/

[AbraaoAlves]

Bom ou ruim, é apenas um ponto de vista em contextos diferentes.

Não que ele seja ruim, mas existem concorrentes melhores agora.

Exemplo:

Hoje não basta apenas um sistema de injeção de dependência, ele tem de não ser verboso.
Hoje não basa ter diretivas, precisamos de um forte incetivo a componentes
Hoje não basta apenas ser testável, ele tem de extensível e facilmente integrável
Hoje não basta ES5, tem de olhar para o futuro
Hoje não basta ...
AngularJS adicionou muita coisa boa em nossa cultura e isso foi muito bom. Quem viveu esse tempo aprendeu muito e agora está partindo para novos desafios que demandam novas soluções.

E sim, penso que ainda vale a pena usar AngularJS 1.x. Principalmente para quem não viveu no começo da era two-way-bind dos frameworks.

[marcioarp]

Estou um tanto atrasado aqui, mas vou dar minha opinião, gosto muito do angular 1.x, e acredito que as versões mais novas devem ser bem melhor, porém me recusei a "digerir" o typescript que eles empurram junto.

[felipefialho]

@marcioarp curiosidade, porque não curtiu TypeScript?

[aranhaagency]

Obrigado por essa issue!

[fabiomirandaa]

Sim, agora em finais de 2019 o AgularJs é ruim. Use Angular 2+(Nesse momento, o 8) e seja feliz.

[bernardocs]

Bem interessante eu voltar nessa thread 4 anos depois e ler meu comentário bem resentido sobre o assunto.

Não acredito que mudaria de opinião para aquele caso específico (Angular 1.x). Mas acho que faltou humildade ali na retórica IUHAEUIHAEUIA
Justificável though... kind of...

Era o primeiro trampo que eu me assumi "pleno", assumindo um projeto sozinho no início (depois houveram contratações). Lembro-me de estar tendo uma experiência bem frustrante com Angular por estar trabalhando num editor WYSIWYG (produto esse com muitas questões específicas) e sentir bastante a falta de flexibilidade do framework. Depois de chorar sangue eu consegui configurar o Webpack no projeto pra usar babel e poder usar ES6. Lembro-me também de ter sido bem ruim a presença de jQuery em pequenas libraries... conflitava com o jqLite (or something... não lembro o nome) que era build-in do Angular e dava umas zikas.

Com o tempo, of course, já olharia pra meu eu do passado e falaria "deal with it"... É meio perigoso formar uma opinião com base em seu contexto ao invés de avaliar a tecnologia canônicamente.

Minha approach hoje é muito mais (o que as pessoas chamam de) pragmática: Eu penso em aspectos como facilidade pra escrever, modularizar e testar.
Gosto muito de ferramentas mais simples possível... ferramentas que me digam "cara... vc é burro! que m*&#@ de código é esse? (build fail)".
E, acima de tudo, a ferramenta tem que servir os requisitos (e não o contrário).

Exemplo mais recente de discussão que consigo pensar: Usar ElasticSearch esperando que ele seja um banco de dados relacional.
ElasticSearch é lindo... tem infinitas features... mas ele tem um propósito um pouco mais específico do que ser só um banco. Se é esperado algo além disso dele, você, com certeza, terá problemas.

Mto massa fazer essa retrospectiva enquanto estava limpando minhas notificações IUHAEIUHAEUIHA