Front end – pojęcia, które mylą się na początku nauki (część 2)

Plugin, wtyczka, rozszerzenie

Każdy zwykle wie, że powyższe rzeczy dają dodatkowe możliwości w ramach jakiegoś narzędzia. Czy zatem plugin (plug-in), wtyczka i rozszerzenie to synonimy?

Właściwie tak. Dochodzi nam jeszcze jedno słowo, które możemy dorzucić do tego kompletu: dodatek. Wszystkie znaczą to samo: dodatkowy moduł rozszerzający możliwości i funkcjonalność oryginalnego programu komputerowego (definicja dla pluginu i wtyczki z WSJP).

Jedyne nieporozumienie, jakie mogłoby wyniknąć – choć zwykle zapobiega temu kontekst – to dwojakie znaczenie dla słowa „rozszerzenie”. Może ono bowiem oznaczać właśnie wtyczkę/plugin (rozszerzenie programu, np. ColorZilla dla przeglądarki Chrome) lub część nazwy pliku komputerowego wskazującą na typ pliku (rozszerzenie pliku, np. .docx lub DOCX dla pliku programu Microsoft Word).

Osobiście nie potrafię wyobrazić sobie sytuacji, w której mogłoby dojść do błędu w komunikacji z powodu „rozszerzenia”. Warto jednak wiedzieć, że słowo to ma w świecie IT dwa znaczenia.

Terminal i konsola

Tym razem to nie do końca synonimy, choć jeśli są używane zamiennie, to zwykle bez szkody dla przekazu (pomaga nam bowiem kontekst).

Terminal

To interfejs umożliwiający komunikację z komputerem. Kiedyś nazywano tak fizyczne urządzenia wejściowe i wyjściowe, czyli klawiaturę i wyświetlacz.

To, co w dzisiejszych czasach nazywamy terminalem, jest tak naprawdę terminalem programowym / emulatorem terminala / aplikacją – czyli dobrze kojarzonym oknem do wpisywania poleceń dla systemu operacyjnego.

Konsola

Kiedyś był to specjalny rodzaj fizycznego terminala. Służył do komunikacji z hostem (host to np. procesor, pamięć, dysk twardy itd.). I o ile jeden komputer mógł mieć wiele terminali, o tyle konsolę miał tylko jedną – przeznaczoną dla administratorów. Jak się zapewne domyślasz, dawała ona więcej uprawnień.

W dzisiejszych komputerach osobistych odzwierciedleniem tego jest możliwość przełączania się między użytkownikiem standardowym a administratorem.

Biblioteka i framework

React daje duże możliwości w tworzeniu aplikacji, dlatego często wrzucany jest do jednego worka z frameworkami, takimi jak Angular. Jest jednak biblioteką. Jaka jest zatem różnica?

Zacznijmy od metafory. Korzystanie z biblioteki przypomina tworzenie np. postaci 3D od zera. Masz własny zamysł, tworzysz szkielet, lecz możesz dla przyspieszenia sobie pracy skorzystać z gotowych elementów, np. zestawu oczu, nosów czy ogonów, lub jakiejś gotowej metody, np. obleczenia szkieletu Twojej postaci w konkretny rodzaj powłoki (lecz to Ty dostarczasz teksturę).

Framework natomiast zapewnia Ci szkielet i gotowe funkcje odpowiedzialne np. za poruszanie się postaci. Tobie pozostaje jedynie dorysować kilka rzeczy i zdecydować o głównych cechach, czasem nawet wybierając je z zestawu opcji proponowanych przez framework.

Zatem w pierwszym przypadku to Ty tworzysz schemat – architekturę aplikacji – i korzystasz jedynie z dodatkowych komponentów, funkcji czy klas zapewnianych przez bibliotekę.

W drugim przypadku schemat zostaje Ci zapewniony przez framework. Dostajesz zestaw instrukcji, dobrych praktyk i gotowe komponenty/funkcjonalności, które uzupełniasz własną logiką biznesową.

W skrócie: biblioteka pozwala na większą elastyczność, a framework – na postawienie bardziej skomplikowanych aplikacji w krótszym czasie niż przy wykorzystaniu biblioteki.

Ciekawym przykładem jest tu React (biblioteka) i Angular (framework). React owszem, zapewnia elastyczność i jest mniej rozbudowany (więc łatwiej się go nauczyć), ale dla optymalizacji jego działania – np. komunikacji z API, routingu czy walidacji formularzy – potrzeba instalacji dodatkowych bibliotek i modułów.

Angular jako framework większość z tych rozwiązań zwiera już w sobie. Dobrze nadaje się zatem do tworzenia rozbudowanych aplikacji, których najważniejszą cechą jest stabilność (bowiem im mniej zewnętrznych zależności, tym mniejsza szansa, że coś się „wysypie”).

JavaScript i jQuery

Pojęcia te dość szybko przestają być mylone (być może nie myliły Ci się nigdy), ale gdy jesteśmy na początku nauki i np. na forach widzimy jQuery, który na dodatek przypomina nam trochę składnię JavaScriptu, powstaje pytanie: czym jest jQuery – jakimś podobnym językiem programowania?

Nie, jQuery to po prostu javascriptowa biblioteka (a zatem coś prostszego niż framework), której zadaniem jest uproszczenie operowania na elementach drzewa DOM i zdarzeniach (interakcjach z użytkownikiem). Ułatwia zatem np. wyszukiwanie elementów, ich kopiowanie, ukrywanie, usuwanie czy animowanie.

Możemy więc używać krótszych instrukcji i uzyskiwać ten sam efekt. Załóżmy, że po kliknięciu w przycisk chcemy zmienić tekst paragrafu. Przycisk i paragraf znajdują się w pliku HTML i wyglądają jak poniżej. Zobacz, jak możemy obsłużyć kliknięcie i ustawienie tekstu w jQuery, a jak wygląda to w JS.

HTML (ten sam dla obu przykładów)

<p class="textElement">This is a paragraph.</p>
<button class="button">Set Text</button>

jQuery

$(".button").click(function() {
    $(".textElement").text("Hello jQuery!");
});

JavaScript

const textEl = document.querySelector(".textElement");
const btnEl = document.querySelector(".button");

btnEl.addEventListener("click", function() {
    textEl.innerText = "Hello jQuery!"
})

W JavaScripcie musimy napisać „trochę” więcej kodu. A mimo to być może słyszałeś już, że używanie jQuery to przeżytek. Dlaczego, skoro teoretycznie oszczędza nam pracy? Chociażby dlatego, że znacząco spowalnia działanie stron – w dzisiejszych czasach (gdy JS jest dość prosty i przyjazny developerom, a kompatybilność kodu między przeglądarkami łatwo uzyskać np. za pomocą Babela) to trochę jak jechanie samochodem do sklepu, który znajduje się 20 m od naszego domu. O tym, dlaczego kiedyś jQuery było przydatne i dlaczego teraz się od niego odchodzi, fajnie opowiada Adam Romański na kanale hello roman.

Chcesz potestować jQuery? Możesz pobawić się np. na stronie W3Schools.

Git i GitHub

Zasadnicza różnica: Git to oprogramowanie, a GitHub to serwis internetowy. Co robią i czy mają ze sobą coś wspólnego oprócz nazwy? Poniżej przedstawiam Ci proste wyjaśnienie, które pochodzi z innego artykułu: Co to jest GitHub i do czego służy.

Git to system kontroli wersji – oznacza to, że pozwala na kontrolę zmian w kodzie. Gdy np. napiszemy coś, co zepsuje naszą dotychczasową pracę, z łatwością wrócimy do poprzedniej działającej wersji. Istotne jest to, że Git działa lokalnie i nie potrzebuje dostępu do sieci – wszystkie zmiany zapisują się na naszym dysku. Mamy też możliwość krótkiego opisywania kolejnych zmian, co nie tylko znacznie ułatwia ich późniejsze odszukanie, ale również dokumentuje nasze postępy.

GitHub to serwis, który pozwala na przechowywanie (hostowanie) repozytoriów. Na potrzeby prostego wyjaśnienia można przyjąć, że repozytorium to odpowiednik katalogu z projektem, wewnątrz którego śledzimy zmiany w kodzie za pomocą Gita.

Na GitHubie mamy więc repozytorium zdalne, a na swoim komputerze – repozytorium lokalne. Nad kodem pracujemy zatem w repozytorium lokalnym (czyli w wybranym edytorze kodu, np. VS Code), a potem wprowadzone i zapisane przez Git zmiany wysyłamy (pushujemy) do repozytorium zdalnego (na GitHuba).

Podsumowując i upraszczając: Git pozwala kontrolować zmiany w kodzie, a GitHub zabezpiecza nas przed utratą kodu (np. w razie awarii dysku nasz kod jest bezpieczny na repozytorium zdalnym).

Sass i SaaS

Sass i SaaS właściwie nie mają ze sobą nic wspólnego prócz podobnych nazw – mylić się więc mogą tylko one. Sądzę jednak, że warto poznać ich rozwinięcie i uchronić się przed jakąś wtopą np. na rozmowie rekrutacyjnej. Rozwińmy więc te skrótowce, by zmniejszyć ryzyko popełnienia literówek:

• Sass – Syntactically Awesome Style Sheets
• SaaS – software as a service.

Szersze wyjaśnienie znajdziesz pod linkami powyżej, lecz w skrócie: Sass to preprocesor CSS-a, czyli narzędzie ułatwiającego tworzenie stylów.

SaaS to, po przetłumaczeniu rozwinięcia na j. polski, „oprogramowanie jako usługa”. To teraz bardzo popularny model, z którego korzystają już tacy giganci jak np. Netflix czy Adobe Creative Cloud. Dobrym przykładem jest przemiana produktów Miscrosoftu – jeszcze do niedawna kupowało się pakiety z programami, które instalowało się na swoim dysku. Teraz mamy możliwość wykupienia abonamentu i w ten sposób uzyskania dostępu do programów i ich najnowszych aktualizacji.

Jeżeli zainteresował Cię temat SaaS (software as a service), to zapraszam Cię do odsłuchania odcinka mojego podcastu: „Jak wystartować z SaaS?” ze specem w tej dziedzinie – Boguszem Pękalskim.

UI a UX

Często występują w parze – np. w sformułowaniu „UI/UX designer”, które widujemy pośród ogłoszeń o pracę. Trzeba przyznać, że ukośnik sugeruje podobieństwo definicji tych wyrażeń, możemy to bowiem odczytać tak: „UI lub UX designer”. W rzeczywistości jednak chodzi o stanowisko, które łączy obowiązki user experience designera i user interface designera.

User experience do działka zajmująca się doświadczeniami użytkownika: od badania jego potrzeb i zachowań, po związane z tym wytyczne dla interfejsu.

Przykładowo więc UX designer może zbadać, że użytkownicy na stronie długo szukają zakładki „Kontakt”. By skrócić ten czas i tym samym polepszyć doświadczenia użytkowników, zasugeruje zmianę w interfejsie, np. dodanie przycisku „Kontakt” w prawym górnym rogu strony.

User interface odpowiada za design i sposób interakcji między użytkownikiem a stroną/programem. Do UI designera należy więc zaprojektowanie widoków aplikacji, przejść, animacji itd. – z zastosowaniem wytycznych od UX designera.

Wszystko potem zaś trafia do front-end developera, który musi to zaprogramować 😉

Jeśli zainteresował Cię ten temat, to zapraszam do odsłuchania odcinka podcastu „UX & UI Design. Co programista powinien wiedzieć o designie”.