Moja przygoda z Angularem
Moja przygoda z frameworkiem Angular rozpoczęła się 5 lat temu (w roku 2014), kiedy wówczas na rynku webowym dostępna była wersja AngularJS (nie pamiętam, w jakiej dokładnie wersji tworzyłem swoją pierwszą aplikację, ale na pewno było to w przedziale 1.2 – 1.4). AngularJS to framework oparty o język JavaScript oraz HTML, a raczej DOM (Document Object Model, czyli sposób reprezentacji struktury dokumentu oraz określenia w jaki sposób odnosić się do struktury z poziomu skryptu). Pamiętam, że zastosowałem AngularJS i zacząłem się mu bliżej przyglądać, ponieważ potrzebowałem, aby po stronie klienta obsłużyć routing i zastosować standard MVC (Model, View, Controller). Takie rozwiązania pozwalały mi kontrolować dużo bardziej to, co użytkownik robi i ograniczać go już na poziomie przeglądarki bez zaangażowania logiki serwerowej. Oczywiście były to ograniczenia dla standardowych użytkowników, reszta logiki była blokowana serwerowo. To na co dodatkowo pozwolił mi AngularJS to przede wszystkim wygodne zarządzanie danymi i modelami a także tworzenie serwisów do komunikacji z backendem.
Za pomocą AngularaJS zbudowałem dwie duże aplikacje komercyjne, które obsługiwały użytkowników z całej Polski. Głównymi problemami jakie napotykałem przy pracy z AngularJS to przestawienie się na używanie metod i odpowiednich atrybutów logicznych bezpośrednio w szablonie HTML. Tworząc wcześniej skrypty, całość logiki była jednak w plikach skryptowych, a tutaj dużo elementów należało dodawać bezpośrednio w templatce – dzisiaj jest to norma w większości frameworków webowych.
W 2016 roku pojawiła się oficjalna wersja Angular 2, która nie posiadała kompatybilności wstecznej i była już oparta o język stworzony przez Microsoft – TypeScript. Twórcy frameworka (Google) sporo namieszali na rynku, ponieważ większość programistów nie mogła przenieść swoich aplikacji do nowszej wersji frameworka. Google oczywiście nie przestało całkowicie wspierać AngularJS, ale jednak skupiło się na rozwoju jego młodszego brata opartego o TypeScript.
W tamtym czasie zaczynaliśmy nowy projekt, który idealnie wpisywał się w standard MVC, routing i aplikację webową. Miałem jednak kilka wątpliwości czy używać AngularJS, który niedługo może przestać być wspierany, czy zastosować Angular 2, którego specyfika jest całkowicie inna i zupełnie mi nieznana. Z perspektywy czasu podjąłem wtedy jedyną słuszną decyzję – wybrałem Angular 2 i poświęciłem cały wolny czas na przewertowanie dokumentacji, dobrych praktyk i zanim rozpocząłem prace nad właściwym projektem, zbudowałem kilka mniejszych przykładowych aplikacji.
Skupiając się od samego początku na dobrych praktykach oraz implementacji standardów obowiązujących w językach obiektowych, bardzo szybko wypracowałem sobie „idealne” dla mnie architektury aplikacji, które pozwalają na szybki i swobodny rozwój aplikacji, a jednocześnie pozwalają na sprawne wdrożenia kolejnych developerów. Projekt powstał, został przyjęty przez klienta z wielką aprobatą, a co najważniejsze – wraz z całą logiką biznesową został napisany przeze mnie w ciągu 2 miesięcy (dla porównania, estymacja czasowa tego samego projektu przy założeniu użycia czystego JS, albo połączenia PHP + JS, .NET wynosiła ok. 4 miesięcy).
Wdrażając developerów w naszej firmie GBX Soft w framework Angular, zauważyłem, że przy kolejnych projektach i większych zespołach mogą zacząć pojawiać się problemy organizacyjne aplikacji ze względu na różne podejścia architektoniczne developerów. Z tego względu wprowadziłem jeden standard i starałem się go mocno pilnować.
Przy jednym z kolejnych projektów pojawił się problem optymalizacyjny dotyczący list, dynamicznego doładowywania elementów i wykrywania eventów z myszki, czy klawiatury. Ze względu na sposób renderowania DOM’u, Angular renderował go nam zbyt często, co miało wpływ na dużo spadek wydajności aplikacji. Pomimo tego, że na tamten moment miałem styczność z dużo większymi aplikacjami i ilościami danych, specyfika tego projektu pokazała, że ciągle trzeba poszukiwać nowych rozwiązań. To co nam wtedy pomogło to tzw. throttling, ręczne wywoływanie rerenderowania DOM oraz wykonywanie pewnych metod poza ngZone.
Na ten moment w wiodących projektach wykorzystujemy wersję Angulara 7, a w najbliższym projekcie chcemy zastosować Angulara 8. Tworzymy społeczność Angulara w Rzeszowie i jako pierwsi zorganizowaliśmy warsztaty szkoleniowe z tego frameworka w południowej Polsce. Osobiście o wiele wygodniej pracuje mi się z Angularem, niż np. Reactem czy Vue.JS, ponieważ sama struktura plików, dostęp do obiektówki, bardzo dobra dokumentacja i wsparcie społeczności developerskiej, a także wiele gotowych bibliotek pozwala mi na dużo szybsze tworzenie oprogramowania, a później na jego dalszy rozwój.
Jakie macie zdanie na temat frameworków webowych? Z czego najczęściej korzystacie? Co sądzicie o Angularze? 🙂