Czym różnią się biblioteki JavaScript od platform?

W tym artykule przedstawiamy różnice między platformami i bibliotekami w kontekście środowiska JavaScript po stronie klienta, czyli kodu działającego w przeglądarce. Jednak niektóre z punktów przedstawionych w tym artykule dotyczą również innych środowisk, ponieważ biblioteki i platformy są częścią wielu dziedzin inżynierii oprogramowania, np. tworzenia natywnych aplikacji mobilnych.

Dyskusje w tym poście skupiają się na różnicach jakościowych, a nie ilościowych między bibliotekami a platformami. Na przykład:

  • Dane ilościowe: struktury są zwykle zgodne z zasadą odwrócenia kontroli.
  • Jakość: środowisko pracy może być atrakcyjniejsze dla przyszłych pracodawców, gdy szukają pracy.

Dlaczego warto dowiedzieć się więcej o bibliotekach i platformach?

Biblioteka i platforma JavaScript często zyskują popularność w internecie. Wygląda na to, że wszystkie pozostałe witryny wykorzystują kod innej firmy w ramach swoich zasobów JavaScript. Waga strony internetowej nasila się z upływem czasu, co ma wpływ na użytkowników. JavaScript ma duży wpływ na ogólną wagę strony. To ten sam kod JavaScript, który często składa się z bibliotek i platform innych firm.

Nie wystarczy powiedzieć „Przestań używać platform JavaScript”, ponieważ są one bardzo przydatne dla programistów. Platformy pomagają między innymi sprawnie kodować i udostępniać funkcje. Lepiej się uczyć, żeby móc podejmować bardziej świadome decyzje w odpowiednim czasie.

„Czy powinienem dziś skorzystać z biblioteki lub ramówki?” to pytanie, które należy sobie zadać rzadko. Biblioteki i platformy to 2 bardzo różne rzeczy. Biblioteki i platformy często się jednak przenikają i im więcej masz informacji na ten temat, tym większe jest prawdopodobieństwo, że będziesz podejmować przemyślane decyzje dotyczące ich wykorzystania.

Przykłady bibliotek i platform

Możesz zauważyć kod innej firmy pod innymi nazwami, takimi jak widżety, wtyczki, polyfills czy pakiety. Wszystkie należą jednak zazwyczaj do kategorii biblioteki lub struktury. Ogólnie różnice między nimi można podsumować tak:

Biblioteka

Biblioteki są zazwyczaj prostsze niż platformy i mają ograniczony zakres funkcji. Jeśli przekażesz dane wejściowe do metody i otrzymasz wynik, prawdopodobnie używasz biblioteki.

Spójrz na ten przykład biblioteki lodash:

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

Podobnie jak w przypadku wielu bibliotek warto przeczytać ten kod i dowiedzieć się, do czego on służy. Działa w nim niewiele magii:

  1. Instrukcja import importuje bibliotekę lodash do programu JavaScript.
  2. Metoda capitalize() jest wywoływana.
  3. Do metody jest przekazywany pojedynczy argument.
  4. Zwracana wartość jest rejestrowana w zmiennej.

Platforma

Platformy są zazwyczaj większe niż biblioteki i mają większy wpływ na ogólną wagę strony. Platforma może zawierać bibliotekę.

Ten przykład przedstawia prostą platformę bez biblioteki i korzysta z Vuepopularnej platformy JavaScript:

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

W porównaniu z wcześniejszym przykładem z biblioteką możesz zauważyć te różnice:

  • Ten kod obejmuje wiele technik i wyodrębnia ich do własnego wypracowanego interfejsu API.
  • Deweloperzy nie mają pełnej kontroli nad tym, jak i kiedy odbywają się operacje. Na przykład w jaki sposób i kiedy Vue zapisuje na stronie ciąg znaków 'Hello, world', jest on wyodrębniony z Twojej strony.
  • Utworzenie instancji klasy Vue wiąże się z pewnymi efektami ubocznymi, które są częste w przypadku korzystania z platform, natomiast biblioteka może oferować czyste funkcje.
  • Platforma wymusza stosowanie określonego systemu szablonów HTML, zamiast korzystać z własnego.
  • Zapoznaj się z dokumentacją platformy Vue lub większością innych dokumentów, aby się dowiedzieć, jak z nich przepisują wzorce architektoniczne, które możesz wykorzystać. Platformy JavaScript pochłaniają trochę pracy poznawczej, ponieważ nie trzeba o tym mówić samodzielnie.

Kiedy korzystać z biblioteki, a kiedy z platformy

Po zapoznaniu się z porównaniami między bibliotekami i platformami możesz dowiedzieć się, kiedy używać jednej z nich:

  • Dla Ciebie, dewelopera, platforma może uprościć pracę. Jak już wspomnieliśmy, struktura może odizolować logikę, zachowanie, a nawet wzorce architektoniczne. Jest to szczególnie przydatne, gdy rozpoczynasz nowy projekt. Biblioteka może pomóc w zwiększeniu złożoności, ale zazwyczaj koncentruje się na ponownym wykorzystaniu kodu.
  • Autorzy forów chcą, aby twórcy koncentrowali się na swojej produktywności i często opracowują dodatkowe narzędzia, oprogramowanie do debugowania oraz wszechstronne przewodniki i inne materiały, które pomogą skutecznie korzystać z platformy. Autorzy biblioteczne także oczekują Twojej produktywności, ale specjalistyczne narzędzia są rzadko spotykane w bibliotekach.
  • Większość platform udostępnia funkcjonalny punkt wyjścia, na przykład szkielet lub stały element, który ułatwia szybkie tworzenie aplikacji internetowych. Biblioteka staje się częścią istniejącej bazy kodu.
  • Ogólnie rzecz biorąc, platformy wprowadzają pewien poziom złożoności dla Twojej bazy kodu. Złożoność nie zawsze jest oczywista na początku, ale z czasem może się ujawnić.

Przypominamy, że biblioteki raczej nie porównuje się z platformą, ponieważ są to różne rzeczy, które służą do realizacji różnych zadań. Jednak im lepiej znasz te 2 usługi, tym większe masz szanse na podjęcie decyzji, która z nich będzie dla Ciebie najlepsza. Decyzja o skorzystaniu z platformy lub biblioteki zależy od Twoich wymagań.

Wymiana

Nie będziesz zmieniać biblioteki ani platformy co tydzień. Warto jednak poznać wady pakietu, który zamyka Cię w jego ekosystemie. Pamiętaj też, że deweloper, który decyduje się na użycie takiego pakietu, jest w pewnym stopniu odpowiedzialny za utworzenie luźnego powiązania między pakietem a kodem źródłowym aplikacji.

Pakietu powiązanego z kodem źródłowym trudniej jest usunąć i zastąpić innym pakietem. Wymiana pakietu może być konieczna, gdy:

  • Musisz zaktualizować pakiet, który nie jest już obsługiwany.
  • Okazuje się, że pakiet nie pozwala na pracę.
  • Poznajesz nowy pakiet, który lepiej odpowiada Twoim potrzebom.
  • Wymagania dotyczące produktu ulegną zmianie i pakiet nie jest już potrzebny.

Przeanalizuj ten przykład:

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

W poprzednim przykładzie użyto pakietu @package/set-color innej firmy w 3 osobnych plikach. Jeśli pracujesz nad tym kodem i chcesz zastąpić pakiet innej firmy, musisz zaktualizować kod w 3 miejscach.

Możesz też uprościć obsługę i wyodrębnić wykorzystanie biblioteki w jednym miejscu, jak widać w tym przykładzie:

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

W poprzednim przykładzie bezpośrednie korzystanie z biblioteki zostało wyodrębnione. Jeśli więc musisz wymienić taki pakiet, wystarczy, że zaktualizujesz tylko jeden plik. Dodatkowo praca z kodem jest teraz łatwiejsza, ponieważ wewnętrzny plik set-color.js ustawia domyślny motyw kolorystyczny.

Łatwość używania

Platforma może mieć złożony interfejs API, ale może zawierać narzędzia dla programistów, które ułatwiają korzystanie z nich. Zależy ona od wielu czynników i może być wysoce subiektywna. Korzystanie z platformy może być trudne, ponieważ:

  • Platforma ma z założenia złożony interfejs API.
  • Platforma jest słabo udokumentowana, a rozwiązywanie problemów wymaga wielu prób i błędów.
  • Platforma korzysta z technik, których Ty i Twój zespół nie znasz.

Zasady mogą im przeciwdziałać, stosując popularne sprawdzone metody, takie jak:

  • Platforma udostępnia narzędzia dla programistów i narzędzia diagnostyczne, które ułatwiają debugowanie.
  • Platforma tworzy aktywną społeczność programistów, którzy wspólnie tworzą bezpłatną dokumentację, przewodniki, samouczki i filmy. Po zapoznaniu się z tymi treściami zaczynasz pracować wydajnie.
  • Platforma udostępnia interfejs API zgodny z popularnymi konwencjami kodowania. Pracujesz wydajnie w ramach tej struktury, ponieważ omówiłeś(-aś) już wcześniej takie konwencje i bardziej znasz style kodowania.

Punkty te są zwykle przypisywane do platform, ale można je też przypisywać do bibliotek. Na przykład biblioteka JavaScript D3.js jest zaawansowana i ma duży ekosystem, który obejmuje m.in. warsztaty, przewodniki i dokumentację. Wszystkie te zasoby wpływają na łatwość użytkowania.

Dodatkowo platforma zwykle określa architekturę aplikacji internetowej, natomiast biblioteka jest zazwyczaj zgodna z dotychczasową architekturą, niezależnie od tego, co może być.

Występy

Ogólnie rzecz biorąc, platformy mogą wpływać na wydajność bardziej niż biblioteki, ale istnieją wyjątki w tym przypadku. Wydajność sieci to ogromny obszar, który obejmuje wiele zagadnień, dlatego w tych sekcjach omawiamy 2 główne tematy: trzęsienie drzew i aktualizacje oprogramowania.

Drżenie drzew

Łączenie w pakiety to tylko jeden aspekt wydajności internetowej, ale ma duży wpływ na wydajność, zwłaszcza w przypadku dużych bibliotek. Wykorzystanie drżenia drzew podczas importu i eksportu poprawia wydajność, ponieważ znajduje i przycina kod, który jest niepotrzebny dla aplikacji.

Gdy łączysz kod JavaScript w pakiecie, możesz skorzystać z tego przydatnego etapu o nazwie „Trzęsienie drzew”. Jest to cenne narzędzie do optymalizacji wydajności, które możesz wprowadzić w swoim kodzie. Jednak biblioteki te są łatwiejsze do zrobienia w przypadku bibliotek niż platform.

Gdy importujesz kod innej firmy do kodu źródłowego, zwykle musisz go połączyć w co najmniej 1 plik wyjściowy. Na przykład pliki header.js, footer.js i sidebar.js zostaną połączone w plik output.js, który jest plikiem wyjściowym wczytanym w aplikacji internetowej.

Aby lepiej zrozumieć drżenie drzew, zapoznaj się z tymi przykładami kodu:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

Dla celów demonstracji przykładowy kod library.js jest celowo ukazany w porównaniu z kodem, który można znaleźć w świecie rzeczywistym, gdzie biblioteka może liczyć tysiące wierszy.

Naiwny proces pakietu może wyeksportować kod z takimi danymi wyjściowymi:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

Funkcja subtract() nie jest potrzebna w tej aplikacji, ale w dalszym ciągu znajduje się w ostatecznym pakiecie. Taki kod zwiększa rozmiar pobieranego pliku, czas analizowania i kompilowania, a także koszty wykonania, które ponoszą użytkownicy. Podstawowe podejście do potrząsania drzewem usuwa martwy kod i daje takie wyniki:

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

Zwróć uwagę, że kod jest krótszy i bardziej zwięzły. W tym przykładzie wzrost wydajności jest nieistotny, ale w rzeczywistej aplikacji, w której biblioteka liczy tysiące wierszy, wpływ na wydajność może być znacznie większy. Co ciekawe, nowoczesne narzędzia pakietu, takie jak Parcel, Webpack i Rollup, idą o krok dalej, ponieważ łączą minifikację i potrząsanie drzewem w celu utworzenia wysoce zoptymalizowanego pakietu. Aby zademonstrować skuteczność narzędzi pakietu, użyliśmy Parcel do utworzenia pliku pakietu z poprzednimi przykładami kodu. Pakiet usunął cały nieużywany kod i wyeksportowano ten pojedynczy moduł:

console.log(7+10);

Pakiet jest na tyle inteligentny, że może usunąć instrukcje importowania, definicje funkcji i inne elementy, aby utworzyć wysoce zoptymalizowany kod.

Łączenie w pakiety to tylko jeden aspekt wydajności internetowej, ale ma duży wpływ na wydajność, zwłaszcza w przypadku dużych bibliotek. Drżenie drzew jest zwykle łatwiejsze przy użyciu bibliotek niż platform.

Aktualizacje oprogramowania

W przypadku wielu bibliotek i platform aktualizacje oprogramowania dodają nowe funkcje i naprawiają błędy, a w ostatecznym rozrachunku stają się coraz większe. Nie zawsze trzeba pobierać aktualizacje, ale jeśli zawierają one poprawki błędów, ulepszenia funkcji lub poprawki zabezpieczeń, prawdopodobnie warto przeprowadzić aktualizację. Jednak im więcej danych przekażesz przewodowo, tym mniej wydajna będzie Twoja aplikacja i tym większy będzie wpływ na wygodę użytkowników.

Jeśli biblioteka się rozrosnie, możesz złagodzić jej przyrost, używając drżenia drzew. Możesz też użyć mniejszej alternatywy dla biblioteki JavaScript. Więcej informacji znajdziesz w artykule Wymienność.

Gdy platforma się powiększy, nie tylko będzie to większe wyzwanie, ale też trudniej będzie zastąpić je innym. Więcej informacji znajdziesz w artykule Wymienność.

Oferty pracy

To trochę otwarty sekret, że wiele firm ma trudne wymagania wobec deweloperów znających konkretną strukturę. Mogą oni zignorować Twoją wiedzę o podstawach tworzenia stron internetowych i skupić się tylko na znajomości konkretnej struktury JavaScriptu. Tak czy inaczej, tak jest w wielu zawodach.

Znajomość kilku bibliotek JavaScript nie zaszkodzi Twojej aplikacji, ale nie ma żadnej gwarancji, że wyróżni Cię na tle konkurencji. Jeśli znasz kilka popularnych platform JavaScript, jest duża szansa, że pracodawcy uznają ją za pozytywną na obecnym rynku pracy programistów stron internetowych. Niektóre duże organizacje utknęły w bardzo starych platformach JavaScript i mogą nawet rozmyślać się o kandydatach, którzy dobrze radzą sobie z takimi platformami.

Możesz wykorzystać ten jawny sekret na swoją korzyść. Należy jednak podchodzić do rynku pracy z rozwagą i pamiętając o tych kwestiach:

  • Pamiętaj, że jeśli przez dłuższy czas w swojej karierze będziesz poświęcać tylko jeden rodzaj struktury, możesz utracić możliwość zdobywania wiedzy z użyciem innych, bardziej nowoczesnych platform.
  • Weźmy programistę, który nie zna podstaw tworzenia oprogramowania ani tworzenia stron internetowych, ale został zatrudniony jako programista. Ten programista nie pisze skutecznego kodu, a praca nad taką bazą kodu może być zniechęcająca lub przytłaczająca. W niektórych przypadkach ten scenariusz może prowadzić do wypalenia zawodowego. Na przykład może być konieczna refaktoryzacja kodu lub dostrojenie go pod kątem wydajności, ponieważ jest on powolny.
  • Gdy uczysz się tworzenia stron internetowych, najlepiej zacząć od skupienie się na podstawach tworzenia stron internetowych, tworzenia oprogramowania i inżynierii oprogramowania. Takie mocne podstawy pomagają w szybkim i efektywnym korzystaniu z platformy JavaScript.

Podsumowanie

Gratulujemy ciężkiej pracy w zrozumieniu, jak platformy JavaScript i biblioteki wypadają na tle innych. Nie będziesz często wybierać platform ani bibliotek, chyba że pracujesz nad projektami greenfield lub jako konsultant. Jeśli jednak zajdą takie decyzje, im większa wiedza na dany temat, tym łatwiej będzie nam podjąć decyzję.

Jak już wiesz, wybór platformy – a w niektórych przypadkach – wybór biblioteki – może w znacznym stopniu wpłynąć na proces programowania i użytkowników, np. na wydajność.