DSP2017 – O tym jak powstanie aplikacja konkursowa

Zaczynam dziś pracę nad tematem konkursowym mimo, iż zapisy do konkursu zostały przedłużone do 12 marca br. Na razie jeszcze trochę teoretycznego wstępu, ale coraz bliżej już do ekscytujących etapów technicznych. Chciałbym teraz pokrótce omówić elementy, z których będę składał aplikację.

HTML

Niektórzy mówią, że bez HTML w sieci to jak bez ciepłych skarpet w zimę. Jeżeli ktoś z obecnie żyjących jeszcze nie wie czym jest HyperText Markup Language to przypomnę, że jest to język znacznikowy służący do opisywania dokumentów internetowych (stron, po ludzku) w sposób zrozumiały dla przeglądarek internetowych wszelkiej maści. Nie jest to język programowania jak to zaskakująco wiele osób mylnie powtarza. Domyślnie moja aplikacja będzie więc skierowana na platformę Web.

BlazeCSS + sass + BEM

Dlaczego nie zwykły CSS? Developer to człowiek zazwyczaj leniwy, ale i pomysłowy. Blaze to jeden z tysięcy frameworków css, które dostarczają zestaw gotowych Styli do użycia na stronie internetowej. Dostępne funkcjonalności są zazwyczaj pogrupowane w tematyczne komponenty jak na przykład przyciski, alerty, kontenery czy okna dialogowe.
Dlaczego więc Blaze? Kilka powodów. Jest to relatywnie mała i lekka biblioteka. Jest to również projekt open source więc pasuje tematycznie do konkursu. Jest dosyć mało znany i uważam, że zasługuje na większą popularność. Ciekawostką jest również, że twórcy tej biblioteki korzystają z Flexbox, czyli alternatywnego podejścia do układania elementów w dokumencie html. Osobiście jestem już znudzony Bootstrap’em, z którego korzysta większość świata więc chętnie wypróbuję coś nowego. Jedynym minusem jaki mi przychodzi do głowy to dosyć zagadkową kompatybilność pośród przeglądarek, ponieważ nie udało mi się dostać do informacji na ten temat.
Sass jest to niejako rozszerzenie css. Dzięki specjalnie opracowanej składni web developerzy są w stanie sprawniej tworzyć arkusze stylów a zarządzanie dużą ich ilością staje się mniej bolesne. Sam „kod” tychże arkuszy zyskuje również na czytelności dzięki m.in. dzięki możliwości zagnieżdżania reguł. Jedną z ważniejszych funkcjonalności są również zmienne. Dzięki temu możemy używać tej samej wartości (np. długości marginesu) w wielu miejscach i żyć bez obaw gdy przyjdzie nam ją zmienić, albowiem zmieniamy ją wtedy w jednym miejscu.
Oczywiście przeglądarki nie rozumieją żadnego z dostępnych tego typu języków (np. alternatywnego Less’a). Oprócz języka sass dostarcza również preprocesor, czyli narzędzie, które zamieni nasz kod w zwykły CSS, zrozumiały dla normalnej przeglądarki. Wilk syty i owca cała!
BEM to już moje własne upodobanie i jest to metodologia dotycząca sposobu formatowania arkuszy stylów CSS. Jest to niezwykle prosta zasadą i warto chociaż wiedzieć o jej istnieniu. Więcej na oficjalnej stronie.

Angular2 + typescript

Odsiedziałem już swój czas z AngularJS, a w międzyczasie pojawiła się już druga, różniąca się w wielu aspektach, wersja tego narzędzia. Chociaż korzystam już z obu wersji na codzień to nadal uważam, że przyda mi się dodatkowy trening. Ponieważ uczyć nie przestajemy się nigdy.
Czym jest angular, niezależnie od wersji? Znowu, jak wiele z setek dostępnych alternatyw, Angular to biblioteka, która dosłownie ożywia i rozszerza zwyczajny kod HTML. Narzędzie to pozwala nam definiować zachowanie domyślnych znaczników języka lub tworzyć nowe. Biblioteka promuje tworzenie dynamicznych Single Page Apps, czyli po polsku aplikacji zawartych na jednej stronie, bez potrzeby przeładowywania strony przy każdej jednej akcji użytkownika. I tak jak pierwsza wersja Angulara była rzeczywiście skupiona na ożywianiu htmlu, tak wersja druga to już praktycznie nowa filozofia tworzenia rzeczywistych aplikacji, a html brzmi tu bardziej jak ozdoba niż jak podstawą.
Angular w wersji drugiej wykorzystuje język TypeScript, który jest rozszerzeniem języka JavaScript. Pewnie w tym momencie myślisz, że web development opiera się na ciągłym tworzeniu rozszerzeń i dodatków. Masz rację, a wynika to jak sądzę z naszej ludzkiej natury. Prawie nigdy nie robimy nic dobrze za pierwszy razem. 🙂
Co daje nam TypeScript? Jest to spełnienie marzeń jeżeli ktoś programuje w JavaScript i tęskni do Javy lub C#. Dzięki uściśleniu typów i kilku innych cech wymienionych przed chwilą języków programowania tworzony kod staje się solidniejszy, bezpieczniejszy i bardziej przewidywalny kosztem pociesznej swobody i elastyczności języka JavaScript. Wiele popularnych czy zwyczajnie głupich błędów zostanie prawdopodobnie wyłapanych podczas kompilacji. Nie zawsze jednak TypeScript to dobre rozwiązanie. Czasem oczywistym wydaje się możliwość skorzystania z pewnych elastycznych puntów JavaScript, dlatego wszystko zależy od tego co dokładnie chcemy osiągnąć.

Gulp

Na koniec coś, co zlepi wszystkie powyższe elementy w całość – gotową aplikację. Jest to narzędzie, które zaprojektowane jest do wykonywania zadań. Są to zwykle nudne zadania, które każdy developer wykonuje kilka czy nawet kilkaset razy dziennie. Dzięki ogromnej bazie wtyczek jego możliwości są praktycznie nieograniczone. Ja na ten przykład mam zamiar użyć Gulp do kompilacji wszelkich użytych rozszerzeń (typescript, sass) i do łączenia poszczególnych grup plików w jedne w celu optymalizacji rozmiaru aplikacji. Na końcu można te pliki jeszcze zminimalizować usuwając odstępy czy znaki nowej linii.

Co jeszcze? Można iść dalej i użyć wtyczki do sprawdzania poprawności składni pisanego kodu JavaScript czy do odpalenia istniejących w projekcie testów jednostkowych i wygenerowania raportu. Mam nadzieję, że i to zdążę zaprezentować w praktyce.

Słowo końcowe

Jak widać jest tego całkiem niezły stos, a to tylko część frontową aplikacji. Jeżeli ktoś jest w temacie to chyba nie dziwi go już jednak to ile rzeczy robi się obecnie po drodze, z jeszcze nie tak dawno prostym w użyciu, programowaniem webowym. Kompilacje? Preprocesory? Optymalizacja? Niegdyś domena języków niskopoziomowych a obecnie chleb powszedni tworzenia stron internetowych. My ludzie przecież tak bardzo lubimy komplikować najprostsze rzeczy. 🙂