Skip to content

Instantly share code, notes, and snippets.

@dgieselaar
Created October 11, 2014 14:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dgieselaar/5f588394a84aac569201 to your computer and use it in GitHub Desktop.
Save dgieselaar/5f588394a84aac569201 to your computer and use it in GitHub Desktop.

App logic and structure expressed in HTML, which is enchanting for beginners (Look’ma no JS, magic!), but terrible for real development. We are developers, we write and debug code. But Angular is HTML parser. I really don’t want to debug any string based parser instead of my code. HTML should be just a projection of app state, not a source of truth!

Te veel logica in je template zetten is inderdaad geen goed idee. Wat dat betreft is Angular zijn expression parser misschien te vergevend. Assignments in je click handlers in de HTML zetten (bijv ng-click="state='open'") of iets dergelijks is een slecht idee en zou eigenlijk niet ondersteund moeten worden.

Dat gezegd hebbende, ik heb bij mijn huidige werkgever een brok javascript geërfd waarbij functionaliteit op basis van aanwezige classes wordt toegevoegd. Dit is verschrikkelijk om te debuggen. Bij Angular kijk je welke directives (attributes) op de button zitten waar je op klikt, of het element wat getoond wordt, en je hebt binnen no time het verantwoordelijke stukje JavaScript gevonden.

Two way databinding is an anti-pattern. There are too much what-if situations. Binding from model to view is ok, but from view to model, it’s completely different story!

Dit is een van de dingen (geldt misschien ook voor het eerste punt) die in de praktijk uiteindelijk niet zo handig lijken als het op eerste oog. Mijn ervaring leert dat je voornamelijk een change handler gebruikt. Maar, voor simpele forms, en de beginnende Angular gebruiker, is het heel handig.

Wat ik zelf heb geconstateerd is dat Angular voor de beginnende developer een aantal grote quick wins heeft, die voor de gevorderde gebruiker misschien minder interessant zijn, omdat die een specifiekere oplossing nodig heeft. De meeste Angular Sucks verhalen gaan over die features voor beginners.

Dirty checking, accessors (Ember and Backbone), Object.observe and all that stuff. Wrong! It’s slow and brittle and it will consume mobile battery like hungry dog, for no reason. You don’t need it. Use Facebook Flux rather. Also, you should never model app data flow with several events spreaded over x classes, where everything listen everything. Be explicit.

Ik kom zelf bijna nooit performance issues tegen. Alleen bij enorme hoeveelheden data op het scherm. Ik vind het bijzonder prettig dat je één data-bron kan hanteren, en verschillende getter functies kan schrijven die die data bron gebruiken. Daarmee voorkom je dat als die data-bron verandert, je zelf alle onderdelen van je applicaties moet notifien dat die data is veranderd. De laatste zin snap ik niet. Maar events voorkom je dus door dirty checking in de Angular $apply loop.

Duplicated app structure with obsolete angular.module. Almost for every app feature you have to 1) change HTML 2) change its controller.

Ik snap werkelijk waar niet waar dit over gaat.

Angular is slow. And with dirty checking and HTML parsing always will be. You can’t fix broken design. Do I have to tell something about consequences for mobile web apps? I guess not.

Zie eerder antwoord.

No server side rendering without obscure hacks. Never. You can’t fix broken design. Bye bye isomorphic web apps.

Hier ben ik het wel mee eens, maar ik bouw geen applicatie waar server-side rendering voor nodig is.

Angular is hard to learn. It’s irony because Angular itself is promoted as easy framework for beginners. But it’s very complicated kind of easiness. You have to learn a lot of Angular specific patterns useful only in Angular world. Yeah, it’s result of bad design. This is both sad and ridiculous. Abstract layer can solve many problems, except problem of having too many abstract layers.

Dit geldt voor alles en iedereen, tenzij je assembly schrijft.

Google does not use Angular in production for their flag apps like Gmail or Gplus.

Dit zijn applicaties die al volwassen waren voordat Angular uberhaupt was ontwikkeld.

Vendor lock. And because Google does not use Angular in production, they can kill Angular anytime. You know that Google is still kind of agile company, not having a problem to kill any project despite it’s used by milions people.

Angular is open source. Hoezo vendor lock?

Will be rewriten entirely soon, which is a good thing for framework, but pain for you.

Daarom heet het ook 2.0 :) Dit vind ik niet per se een slecht ding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment