-
Código fonte, apesar de fuzzy, não trás risco. Passou no Lint, e pela minha análise não possui pontes para memory leak interna.
-
Smelly Controller API. Porém, a sua API parte do princípio que as controllers são uma Closure JavaScript ( function ). Isso tráz consigo alguns riscos:
- Fere a orientação a objeto, oferencendo um modelo contextual ( baseado em Closure Stack ) para definir o escopo, diminuindo o reaproveitamento dos comportamentos das Views.
- Quando se tem mais de um nó DOM para se manipular, uma prática muito comum é computar o nó pai mais próximo do nós em questão. Assim, a busca fica condicionada a um escopo menor, oferencendo melhor performance na interação da tela à hardwares mais fracos. Usando uma Closure somos obrigados a guardar o estado em váriaveis globais ou na variavel escopo. Se salvo na variavel de escopo, deve-se ater a possíveis conflitos com nomes que possa ficar exposto, podendo trazer efeitos colaterais no comportamento da tela.
-
Impede que seja utilizado o XHTML como forma de template no server-side, uma vez que infringe uma regra da marcação que diz que todo atributo deve ter um valor, mesmo que vazio.
<!doctype html>
<html ng-app>
...
</html>
- Infringe o conceito básico de Logic-Free Markup "nao misturar lógicas de programação com a marcação que define a view".
<!doctype html>
<html ng-app>
<head>
<script src="http://code.angularjs.org/1.2.0-rc.2/angular.min.js"></script>
</head>
<body>
<div ng-init="list = ['Chrome', 'Safari', 'Firefox', 'IE'] ">
<input ng-model="list" ng-list> <br>
<input ng-model="list" ng-list> <br>
<pre>list={{list}}</pre> <br>
<ol>
<li ng-repeat="item in list">
{{item}}
</li>
</ol>
</div>
</body>
</html>
- O modelo de roteamento infringe faz com que nós repitamos o roteamento, para amarrar view ao código.
Podiamos usar de Natural Routing do Logic-Free Markup: "Utilizamos Natuzal Routing toda vez que, para buscar uma view ( html, mustache, freemarker, etc..), ou uma view parcial, do servidor e não for necessária intervenção de uma lógica de negócio para obtê-la."
Ao inves de termos que alimentar frequentemente uma lógica JavaScript para amarrar módulos e controllers a uma view, é mais fácil criar um componente XHTML ( ou algo que o modelo de template do server-side forneça ) para fazer isso de maneira centralizada.
-
Modelo de modularização dele é muito fraco. No mundo JavaScript existe um movimento chamado CommonsJS que define uma boa prática para trabalhar com módulos, de maneira assincrona e organizada, a este modelo foi dado o nome do AMD ( Asynchronous Module Definition ). O RequireJS é a melhor ferramenta até o momento para isso.
-
O modelo de DataBinding dele é muito bom, com rápida responsividade. Pena que ele também se responsibiliza pela manipulação de eventos DOM como todo, oferencendo-se como uma alterativa ao MooTools Selector, Sizzle, JQuery-Sizzle-Selector, Zepto e tantos outros que já possuem otimização necessária para tratar estes comportamentos.
-
Tras consigo um fork do JQuery ( jqLite ).
- Ele consegue coexistir com o JQuery tradicional mas ainda teremos um outro jQuery lá aumentando o tamanho da aplicação a ser trafegada
- A versão do JQuery que acompanha o framework não é a mais recente, e com isso, mantém alguns bugs/gaps que as versões novas não possuem mais.
-
Duck Tale: "A duck can swim, walk and fly. But an eagle flies faster and more skillfully, fish are better swimmers and just about anything on legs can outrun a duck."