5. • Logiczny podział części aplikacji
• Łatwość developmentu
• Ograniczenie udziału programistów w sprawach UI
• Relatywnie niewysoki próg wejścia w projekt
• Nie chciałem “zwariować”
8. • Zmieniające się założenia biznesowe
• Zmieniający się UI
• Zmieniający się zestaw modułów
• Utrzymanie wydajności
• Estetyka kodu
19. Two way data binding
• DIY
https://gist.github.com/austinhyde/4321f22a476e1cb
ee65f
• ♥ formularze
• “ktoś”, “gdzieś”, “kiedyś” musi przekazać dane
Połączenie 2 firm.
Nowa firma. Nowe projekty. Nowa jakość.
Nowa poczta.
Backend
Dalej mówię o tym jak to wygląda w części frontend. o2, wp. Co chciałem uzyskać.
Dlaczego Angular?
W wp.pl - GWT, jQuery
W o2.pl - Backbone, prototype
Dlaczego powiedziałem, że nie chcę zwariować?
Biznes wie, że nie ma “bo to stare i nikt tego nie ruszy”
Chcemy testować rzeczy
Wszyscy mają pomysły
CoffeeScript. hoisting, ES6, flow, atScript
Jade: słaby kompilator, wolny.
Gulp / Make / Jake: nie ma rozwiązania idealnego
Karam / Protractor: jak wywalilismy browserify to jest okej ;)
Dlaczego podział aplikacji jest ważny.
Dlaczego w końcu skończy się z takim podziałem.
Widoki są rerenderowane cały czas.
Cache jest na szablon, dane ale nie wygenerowany html.
Feel jest słaby przy skomplikowanych widokach.
Powidzieć o czasie.
Czasami ilość danych które trzeba wyrenderować jest za duża dla Angulara.
Jak wygląda to w praktyce. Co można na to poradzić?
Karol Jastrzębowski z GoldenLine
No server side rendering without obscure hacks. Google does not use Angular in production for their flag apps like Gmail or Gplus. Vendor lock. And because Google does not use Angular in production, they can kill Angular anytime.