An Angular Roadmap – The Past, Present, and Future of Angular

Angular Updates: What’s New in Version 11

Od listopada 2020 roku, Angular w wersji 11.0.0 jest już dostępny. Podczas gdy to wydanie przynosi wiele aktualizacji platformy, najbardziej znaczące funkcje obejmują szybsze budowanie z TypeScript 4.0, wiązki testowe komponentów i aktualizacje ESLint.

Paleolityczny JavaScript – SproutCore

Na początku był SproutCore. Był to pierwszy kompleksowy framework JavaScript, którego celem było ułatwienie budowania jednostronicowych aplikacji internetowych o jakości desktopowej. Nie chodzi o to, że wcześniej nie było to możliwe. Kiedy Google wypuściło Gmaila, pokazało światu, że aplikacje internetowe naprawdę mogą zastąpić złożone aplikacje desktopowe. Google udostępniło nawet zestaw narzędzi Closure – zestaw bibliotek i kompilator optymalizujący, które wykorzystało do zbudowania Gmaila.

Problem polegał na tym, że narzędzia Closure firmy Google nie były zbyt przyjazne dla programistów. Opierały się w dużej mierze na Javie, co zraziło twórców stron internetowych, którzy byli przyzwyczajeni do pracy z JavaScriptem, PHP, Ruby i Pythonem. Gmail był świetną demonstracją tego, co było możliwe, ale tworzenie podobnych aplikacji wciąż było poza zasięgiem dla wielu osób.

Niektórym odważnym programistom udało się połączyć niesamowite aplikacje jednostronicowe przy użyciu kombinacji jQuery, taśmy klejącej i nadziei. Podczas gdy te aplikacje wyglądały niesamowicie dla użytkowników końcowych, dla pracujących nad nimi programistów szybko zamieniły się w ogromne stosy długów technicznych, które sprawiały, że zespół programistów bał się wychodzić rano do pracy.

W rezultacie kilku przedsiębiorczych programistów zaczęło pracować nad frameworkami, które sprawiłyby, że aplikacje podobne do Gmaila znalazłyby się w zasięgu ręki wszystkich twórców stron internetowych. SproutCore był pierwszym z tych frameworków, który wystartował. Zawierał on kompletny zestaw widżetów umożliwiających tworzenie złożonych aplikacji internetowych bez znajomości HTML lub CSS.

Kończyło się to tym, że było to świetne rozwiązanie dla byłych programistów desktopowych, którzy zostali wciągnięci z kopnięciem i krzykiem do sieci. Kilka innych frameworków wyskoczyło z podobnymi celami; GWT i Cappuccino były najbardziej znaczące. Te frameworki nawet unikały JavaScriptu, transponując inne języki do JS. Ponownie, było to świetne rozwiązanie dla programistów desktopowych. Ale zostawiło zapalonych twórców stron internetowych na lodzie i sprawiło, że poczuli się tak, jakby ich ciężko zdobyte umiejętności HTML, CSS i JavaScript nie były wartościowe.

Pozostawiło to pole do popisu dla frameworka, który naprawdę obejmowałby sieć, zamiast próbować ją zatynkować i udawać, że jest czymś innym. Pojawiło się kilka wczesnych frameworków (Backbone i Knockout), które odniosły umiarkowany sukces. Mniej więcej w tym czasie pojawił się też Ember. Wziął on SproutCore, rozebrał go do kości i próbował przebudować w coś naprawdę przyjaznego dla sieci. Ember chciał być Six Million Dollar Man świata JavaScript: przebudowany lepiej, mocniej i szybciej.

Żaden z tych frameworków nie zdobył popularności. Świat czekał na coś lepszego. W 2010 r. pojawiło się to coś lepszego – nazwano to Angular.

Złota era Angular

Nawet przed wydaniem wersji 1.0 Angular szturmem zdobył świat front-end developmentu. Wreszcie mieliśmy łatwy w użyciu framework JavaScript, który traktował HTML jak obywatela pierwszej klasy. Programiści i projektanci mogli teraz współpracować przy tworzeniu niesamowitych aplikacji typu single-page. Przyniosło to ulgę projektantom, którzy byli zirytowani i obrażeni, ponieważ starsze frameworki traktowały HTML i CSS jak narzędzia dla barbarzyńców, narzędzia, których żaden cywilizowany programista nie powinien dotykać.

Pierwszą rzeczą, która wydała się magiczna programistom próbującym Angulara po raz pierwszy, było dwukierunkowe wiązanie danych. Przedtem większość programistów widziała ten rodzaj wiązania danych tylko w desktopowych frameworkach, takich jak WPF i Windows Forms. Wspaniale było móc powiązać formularze i inne elementy UI z obiektami modeli JavaScript. Podczas gdy dwukierunkowe wiązanie danych mogło powodować problemy z wydajnością, gdy było nadużywane, zespoły, które używały go rozsądnie, odkryły, że Angular umożliwił im tworzenie złożonych aplikacji front-endowych znacznie szybciej niż kiedykolwiek wcześniej.

Angular okazał się popularny nie tylko ze względu na łatwe wiązanie danych z elementami HTML. Dyrektywy Angular zapewniły łatwy sposób na tworzenie komponentów HTML + CSS wielokrotnego użytku. Chociaż inne frameworki JavaScript zapewniały to przed Angular, Angular był pierwszym, który stał się niezwykle popularny. Komponenty wielokrotnego użytku od dawna były używane w frameworkach po stronie serwera. Kontrolki użytkownika ASP.NET i częściowe szablony w Rails i Django to tylko kilka
przykładów.

Wreszcie Angular sprawił, że wstrzykiwanie zależności stało się popularne w świecie programowania front-end. Wstrzykiwanie zależności od dawna było popularne w aplikacjach korporacyjnych, być może dlatego nie przyciągnęło uwagi w świecie JavaScript. Programiści front-end od dawna mają awersję do tego, co postrzegają jako niepotrzebnie skomplikowane wzorce projektowe oprogramowania korporacyjnego. Te obawy nie są bezpodstawne. Czy kiedykolwiek, w trakcie pisania aplikacji, powiedziałeś sobie „To czego naprawdę potrzebuję to „SimpleBeanFactoryAwareAspectInstanceFactory?”

Wstrzykiwanie zależności, jednak, udowodniło swoją wartość. A Angular sprawił, że wtrysk zależności stał się łatwy w użyciu dla publiczności, która nie używała go zbyt często w przeszłości. Potrzebujesz klienta HTTP? A może chciałbyś zrobić jakąś animację? Nie ma problemu. Angular miał wbudowane usługi dla tych rzeczy. Wystarczyło o nie poprosić, a Angular wstrzyknąłby je do twoich komponentów. Nie trzeba było niczego samodzielnie instancjonować.

A może chciałeś użyć obiektów window lub location przeglądarki bez uniemożliwiania testowania jednostkowego twoich komponentów poza przeglądarką? Angular miał cię tam również, dzięki wbudowanym usługom $window i $location. Podczas runtime, otrzymywałeś obiekty przeglądarki, których oczekiwałeś. A podczas uruchamiania testów jednostkowych po stronie serwera w Node.js, mogłeś przekazać mock services do swoich komponentów, aby upewnić się, że zachowują się one zgodnie z oczekiwaniami w różnych scenariuszach.

Jeśli to wszystko nie wystarczyło, Angular ułatwił również rejestrowanie i wstrzykiwanie własnych usług. Dla programistów, którzy byli przyzwyczajeni do wiązania wszystkich swoich danych do DOM i liczenia na najlepsze, było to niesamowite. Jeśli pisałeś nową aplikację front-endową, która wywoływała API, które kosztowałyby twoją firmę dużo pieniędzy, gdyby były nadużywane, prawdopodobnie wolałbyś mieć możliwość pisania testów z wyprzedzeniem, aby upewnić się, że twoja aplikacja nie próbuje zrobić czegoś takiego, jak wywołanie API Twilio 800 milionów razy.

Tak więc utworzyłbyś usługę Twilio, która zostanie wstrzyknięta w czasie wykonywania. W czasie testowania utworzyłbyś usługę mock, która rejestruje koszt każdego wywołania API, które próbuje wykonać twoja aplikacja. Napisałbyś testy, które obejmują typowe scenariusze użycia i upewniłbyś się, że te scenariusze nie spowodują, że Twoja firma otrzyma 7-cyfrowy rachunek. Ogólnie rzecz biorąc, większość programistów stwierdziła, że dyrektywy Angulara w połączeniu z wstrzykiwaniem zależności umożliwiły pisanie modularnych, testowalnych aplikacji front-endowych przy użyciu sprawdzonych technik inżynierii oprogramowania. Wiele zespołów deweloperskich uznało, że jest to szczęśliwy stan rzeczy i zdecydowało się na Angulara.

Spadek Angulara? The Rise of React

Choć w świecie Angulara sprawy miały się w większości świetnie, nie było to wszystko słońce i lizaki. Programiści zaczęli napotykać poważne problemy z wydajnością, gdy próbowali powiązać zbyt wiele obiektów modelu ze zbyt wieloma elementami DOM. Niektóre aplikacje zwalniały do pełzania. Bezpośrednie wywołania do $digest i inne czary-mary zaczęły być konieczne do osiągnięcia akceptowalnej wydajności. Mniej więcej w tym samym czasie pojawił się nowy konkurent: React. Na początku, React nie wydawał się stanowić zbyt dużego zagrożenia dla Angulara. W końcu ci dziwacy z Reacta zadali sobie trud wymyślenia JSX, który wyglądał jak sposób na wmieszanie znaczników do kodu. Czy nie zadaliśmy sobie wiele trudu, aby wymyślić języki szablonów z wyraźnego powodu, aby uniknąć mieszania znaczników z kodem?

Jak się okazało, podejście Reacta było całkiem popularne w społeczności programistów front-end. Nie było to jednak rakieta do popularności. Angular wciąż dominował i wyglądało na to, że tak pozostanie. Do czasu, gdy popularność Angulara dostała niezłego kopa w zęby z nieoczekiwanego źródła: od samego zespołu Angulara.

Wprowadzenie Angular 2

Angular 2 został po raz pierwszy ogłoszony na konferencji ng-europe w 2014 roku. Plany zespołu Angulara były szokiem dla społeczności Angulara, delikatnie mówiąc. Reakcja ze strony deweloperów Angular była szybka i negatywna… i nie bez powodu. Angular 2 miał pozbyć się wielu znanych koncepcji z Angular 1, wprowadzając nowy, niekompatybilny język szablonów (a przy okazji), miał być również programowany przy użyciu zupełnie nowego języka.

AngularJS

Ale chociaż zarówno Angular 1, jak i Angular 2 były nazywane „Angular”, w rzeczywistości były to bardzo różne frameworki z kilkoma rzeczami wspólnymi. Aby zapobiec zamieszaniu, zespół Angular zaczął odnosić się do starej wersji Angular jako „AngularJS”, a nowa wersja jako po prostu „Angular”. Ma to intuicyjny sens, ponieważ AngularJS został napisany w JavaScript, a Angular nie. Aby zachować jasne rozróżnienie między frameworkami, będę odnosił się do Angular 1 jako AngularJS od tego momentu.

W wyniku tego wszystkiego, deweloperzy AngularJS stracili wiarę w przyszłość frameworka. Zagrozili, że w przyszłych projektach przejdą na nowy framework i właśnie to wielu z nich zrobiło. React był największym beneficjentem masowego exodusu z AngularJS.

Ale chociaż React nie zrobił tak wiele jak AngularJS, w pewnym sensie było to pozytywne. Jeśli używasz biblioteki widoku, która nie próbuje zawrzeć wszystkiego plus zlew kuchenny, o wiele trudniej jest twórcom tej biblioteki wyciągnąć dywan spod ciebie w przyszłości. Na początku używanie Reacta było nieco bolesne w porównaniu do AngularJS. Musiałeś brukać razem patchwork bibliotek tylko po to, aby pokryć funkcjonalność, którą AngularJS dostarczył po wyjęciu z pudełka.

Wiele zespołów widziało to jako dobry sposób na zmniejszenie ryzyka, ponieważ było mało prawdopodobne, że twórcy wszystkich tych bibliotek zdecydują się na dokonanie niekompatybilnych wstecz zmian łamiących w tym samym czasie, co jest zasadniczo tym, co zrobił Angular.

Wyłonienie się Vue

Aby spotęgować nieszczęścia AngularJS, inny framework o nazwie Vue pojawił się mniej więcej w tym samym czasie, gdy rozgrywał się dramat związany z Angular 2. Vue było inspirowane AngularJS, ale miało na celu uproszczenie go i pozbycie się tego, co twórca Vue widział jako niepotrzebną złożoność (więc Vue czuło się bardzo znajome dla istniejących programistów AngularJS). Vue stanowiło bezpieczną przystań dla wielu programistów AngularJS, którzy nie chcieli przenieść się do React.

Nie oznacza to, że programiści AngularJS nie czekali cierpliwie na pojawienie się Angular 2. Ale jasne jest, że nastąpił masowy exodus z AngularJS do React i Vue ze względu na niepewność spowodowaną planami dla Angular 2.

Rising From the Ashes with Angular 2

W końcu Angular 2 został wydany. Zgodnie z oczekiwaniami, pozbył się wielu znanych koncepcji z AngularJS, ale zachował kilka najlepszych kawałków, takich jak usługi i wstrzykiwanie zależności. Na szczęście dla zdrowego rozsądku programistów, Angular używa zwykłego TypeScript, a nie widelca, jak pierwotnie planowano.

Aby jeszcze bardziej zagmatwać sprawy, zespół Angular utrzymywał widelec nowego frameworka, który używał języka programowania Dart zamiast TypeScript. Początkowo wersje TypeScript i Dart były rozwijane w synchronizacji, generowane z jednej bazy kodu. Ostatecznie wersje TS i Dart Angulara postanowiły pójść swoją drogą, a Angular Dart istnieje teraz samodzielnie.

Nawet z tym zamieszaniem, popularność Angulara zaczęła ponownie rosnąć po wydaniu Angulara 2. Działo się to powoli. Jak to często bywa w rozwoju oprogramowania, trendy się zmieniały. Programiści zdali sobie sprawę, że duży, dołączony do baterii framework może być faktycznie przydatny. W końcu, kiedy twoja aplikacja staje się wystarczająco duża, w końcu potrzebujesz tych wszystkich baterii.

Deweloperzy korporacyjni, w szczególności, zaczęli przenosić się z powrotem do Angulara. To ma sens. Zazwyczaj, gdy zaczynasz aplikację internetową dla przedsiębiorstw, wiesz, że będzie ona złożona. Nie ma sensu zaczynać od malutkiego MVP, gdy od początku wiesz, że wszystkie 87 rzeczy, których będzie się oczekiwać od Twojej aplikacji, będzie robić.

Where’s Angular 3?

Although Angular 2 was not perfect, many developers of complex web applications began to realize that the new-and-improved Angular was a good fit for their needs. Na szczęście dla nich, Angular miał kilka ekscytujących ulepszeń w zanadrzu. Co ważniejsze, zespół Angulara pokazał, że może konsekwentnie publikować nowe wersje frameworka z niewielką ilością zmian pomiędzy wersjami

W ruchu, który w tamtym czasie wydawał się dziwny, zespół Angulara postanowił całkowicie pominąć wersję 3 i przejść do wersji 4. Zrobiono to z dobrego powodu: zespół pracujący nad pakietem routerów Angulara już popchnął do przodu i wydał wersję 3, podczas gdy reszta Angulara była wciąż w wersji 2.3. Postanowili oni utrzymać wszystkie wersje pakietów Angulara w synchronizacji, a podniesienie wszystkiego do wersji 4 dla następnego wydania było najłatwiejszym sposobem na osiągnięcie tego.

Angular 4

Angular 4 miał kilka znaczących zmian, w tym dodano kompilację z wyprzedzeniem, co zaowocowało małymi produkcyjnymi pakietami JavaScript i krótszym czasem ładowania aplikacji. Dodano wsparcie dla renderowania po stronie serwera, co stanowiło impuls dla zespołów, które chciały renderować swoją aplikację z wyprzedzeniem, aby poprawić wydajność początkowego ładowania. Wiele innych ulepszeń zostało dodanych w całym frameworku, ale aktualizacja aplikacji z Angular 2 do 4 była szybka i bezbolesna w większości przypadków.

Angular 4.3 i Angular 5

Angular 4.3 dodał nowego klienta HTTP, który był łatwiejszy w użyciu niż stara usługa HTTP. W Angular 5, stara usługa HTTP została zdeprecjonowana i zostanie porzucona w następnym wydaniu. Pomimo tej niedogodności, było stosunkowo mało narzekania, ponieważ aktualizacja w większości przypadków była prosta. Angular 5 dodał także lepszą obsługę internacjonalizacji i dalsze optymalizacje budowania.

Angular 6 i 7

Angular 6 i 7 były rozczarowujące dla niektórych programistów. Nie było dużych zmian, ale było wiele małych ulepszeń jakości życia, szczególnie w narzędziach Angular CLI. Zmniejszająca się liczba widocznych zmian nie wskazuje na to, że zespół Angulara przestał wprowadzać innowacje. Zamiast tego pokazuje, że framework jest dojrzały, więc zespół programistów jest teraz wolny, aby wykonać więcej pracy za kulisami, naprawiając błędy i poprawiając wydajność.

Stabilność frameworka od czasu wydania Angular 2 przyciągnęła niektórych old-schoolowych deweloperów AngularJS z powrotem do świata Angular. Przyciągnął on również uwagę zespołów programistów korporacyjnych. Kiedy budujesz aplikacje korporacyjne, które mogą żyć przez dziesięciolecia, idealnie jest używać frameworka, który dostaje nowe wersje w przewidywalnym harmonogramie, ale nie zmienia się zbyt szybko. Programista, który korzystał tylko z Angular 2, może być gotowy do pracy i współtworzyć aplikację Angular 7 w ciągu kilku minut.

Angular 8 i Angular Ivy

I to prowadzi nas do dzisiaj. Jak już widzieliśmy, Angular przeszedł długą drogę. Przeszedł od uwielbianego przez web deweloperów, poprzez bycie znienawidzonym, aż do bycia podziwianym, chociaż nie jest jeszcze kochany tak jak w swoich początkach.

Na horyzoncie mamy Angular 8. Tona pracy została wykonana w Angular 8, aby uczynić go łatwym w użyciu z systemem budowania Bazel, co jest absolutnie niesamowitą wiadomością dla wszystkich 3 deweloperów, którzy używają go poza Google. Przeczytaj o zmianach w Angular 8.

Najbardziej ekscytujące jest jednak to, że zespół Angular ciężko pracuje nad nowym rendererem o nazwie Angular Ivy. Ma to być drop-in replacement dla obecnego renderingu. W przeważającej części, obecne aplikacje nie będą musiały wprowadzać żadnych zmian, aby korzystać z Angular Ivy.

Jeśli Angular Ivy jest zamiennikiem drop-in, dlaczego deweloperzy powinni się tym przejmować? Dwa ważne powody: szybkość i rozmiar pakietu – dwa bardzo ważne problemy. Przez kilka lat wydawało się, że twórcy stron internetowych trochę zwariowali. Zespoły wysyłały pakiety JavaScript, które miały 5MB, 10MB, a nawet więcej i myślały, że nie ma z tym problemu. W końcu, aplikacje działały doskonale na MacBookach Pros z procesorem i7, więc powinny działać dobrze dla każdego, prawda?

Niestety, w prawdziwym świecie, nie każdy ma najnowszy i najwspanialszy sprzęt. Setki milionów ludzi ma dostęp do internetu wyłącznie na starszych telefonach z Androidem z mocą obliczeniową nieco większą niż ziemniak, poprzez połączenie internetowe tylko trochę szybsze niż dial-up. Dla tych użytkowników, ogromny pakiet JavaScript zajmuje wieki, aby się załadować, a jeszcze dłużej dla ich urządzenia, aby go przetworzyć i uruchomić. Nawet w mniej ekstremalnych przypadkach, istnieje niezliczona ilość użytkowników na całym świecie, którzy nie używają najnowszego i najwspanialszego sprzętu. Dla nich, masywne aplikacje JavaScript są użyteczne (ale bolesne).

Angular Ivy

Renderer Angular Ivy pomoże na kilka sposobów:

1. Jest pisany z myślą o wydajności, więc będzie wykonywał te same zadania, wykonując znacznie mniej instrukcji procesora. Poprawi to zarówno żywotność baterii, jak i rozsądek użytkowników z mniej niż potężnymi urządzeniami.
2. Renderer będzie napisany w znacznie bardziej modułowy sposób niż obecny renderer. To sprawi, że będzie on znacznie bardziej podatny na wstrząsanie drzewami i eliminację martwego kodu. W rezultacie, twój produkcyjny pakiet JavaScript będzie zawierał tylko ten kod, który jest potrzebny do uruchomienia twojej aplikacji, zamiast łączyć ze sobą wszystko plus zlew kuchenny, jak to się często dzieje z obecnym rendererem.
3. Oprócz zmniejszenia rozmiaru pakietu i poprawy szybkości renderowania, Angular Ivy ma jeszcze kilka innych ulepszeń jakości życia dla programistów Angular. Czasy rebuildingu są znacznie szybsze. Jeśli więc uruchamiasz swoją aplikację w trybie deweloperskim i czekasz na pojawienie się swoich zmian, teraz będziesz spędzał o wiele mniej czasu na czekaniu.
4. Sprawdzanie typów szablonów zostało poprawione, co oznacza, że wyłapiesz więcej błędów w czasie kompilacji zamiast w czasie uruchamiania. Błędy szablonów w czasie działania są denerwujące, ponieważ albo gryzą cię podczas testowania, albo gryzą twoich użytkowników, gdy próbują korzystać z twojej aplikacji.
5. Kompilator szablonów Angular Ivy wygeneruje kod, który jest czytelny dla człowieka, czego nie robi obecny kompilator View Engine. Przyda się to, gdy będziesz próbował wytropić trudne błędy w szablonach.

Wynik netto: mniejsze aplikacje, szybsze aplikacje, szczęśliwsi deweloperzy i szczęśliwsi użytkownicy.

Angular 9

Tutaj znajduje się przegląd Angular 9.

Główne atrakcje obejmują:

• Built-in Angular Features
• Mature Development with Angular
• Understanding Angular View Engines
• Angular Ivy Solves Long-Standing Problems
• Angular Ivy and Mobile
• Selector-less Directives
• Angular Diagnostics Improvements
• Internationalization with Angular Ivy
• DI and Type-Safe in Angular 9
• Dependency Injection Changes in Angular Core
• Angular Benchmarks (Angular 8.2.7 vs. 9.0.0-next.5)

Angular 10

Angular w wersji 10.0.0 został wydany pod koniec czerwca 2020 roku. Główne wydanie, Angular 10 zawiera zmiany takie jak nowy selektor zakresu dat w Angular Material, aktualizacje wersji TypeScript, aktualizacje wersji bibliotek i wiele innych.

Nowe funkcje obejmują:

• Ngtsc Compiler Interface
• Configure Async Timeouts
• Stale Lock File Reporting
• Lazy Computation of basePaths

.

• Merging Translation Files
• Explicit Mapping

Angular 11

Angular w wersji 11.0.0 została wydana w listopadzie 2020 roku. Główne wydanie Angular 11 zapewnia aktualizacje na całej platformie, w tym CLI i ramy komponentów.

Ważne funkcje obejmują:

• Szybsze kompilacje z TypeScript 4.0
• Wiązki do testowania komponentów
• AktualizacjeESLint
• Uaktualniony podgląd usług językowych
• Uaktualniona obsługa Hot Module Replacement (HMR)
• Ulepszone raporty i logowanie
• Automatyczne wstawianie czcionek

Przeszłość Angulara, Present, and Future

Jeśli używasz Angulara od jego wczesnych dni aż do teraz, to gratuluję! Chociaż było wiele trudnych momentów, udało nam się stworzyć szybki, nowoczesny framework, który jest przyjemny w użyciu.

Jeśli byłeś programistą AngularJS, ale przeszedłeś na React, Vue, lub coś innego, zachęcam cię do ponownego przyjrzenia się Angularowi. To jest warte twojego czasu, nawet jeśli zdecydujesz się pozostać przy tym, czego używasz teraz.

A jeśli nigdy nie używałeś Angulara, dlaczego nie spróbować?

Właśnie byliśmy na wycieczce przez przeszłość, teraźniejszość i przyszłość Angulara. Bez wątpienia, to była niezła jazda. Niezależnie od twojego doświadczenia z Angular, mam nadzieję, że podobała ci się ta wycieczka!

Z jakim frameworkiem pracujesz i dlaczego? Jeśli masz pytania lub komentarze, upewnij się, że wpisałeś je poniżej.

Szukasz komponentów UI niezależnych od frameworka? GrapeCity posiada kompletny zestaw komponentów UI JavaScript, w tym siatki danych, wykresy, wskaźniki i kontrolki wejściowe. Oferujemy również potężne komponenty arkuszy kalkulacyjnych, kontrolki raportowania i ulepszone widoki prezentacji. Mamy głębokie wsparcie dla Angular (jak również React i Vue) i jesteśmy oddani rozszerzaniu naszych komponentów do użytku w nowoczesnych frameworkach JavaScript.