Ta strona została przetłumaczona przez Cloud Translation API.

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

Umar Hansa

Z tego artykułu dowiesz się, czym różnią się frameworki od bibliotek w kontekście środowiska JavaScript po stronie klienta, czyli kodu, który działa w przeglądarce. Niektóre kwestie omawiane w tym artykule dotyczą jednak także innych środowisk, ponieważ biblioteki i ramy są wykorzystywane w wielu dziedzinach inżynierii oprogramowania, np. w przypadku tworzenia natywnych aplikacji mobilnych.

W tym poście skupiamy się na różnicach jakościowych, a nie ilościowych między bibliotekami i ramami. Na przykład:

Ilościowe: frameworki zwykle przestrzegają zasady inwersji kontroli.
Jakościowa: znajomość frameworku może przydać się w przyszłości podczas poszukiwania pracy.

Dlaczego warto poznać biblioteki i ramy?

Biblioteki i platformy JavaScript są powszechnie używane w internecie. Każda witryna używa kodu zewnętrznego w ramach swoich zasobów JavaScriptu. Waga strony internetowej staje się coraz mniejsza, co wpływa na użytkowników. JavaScript ma duży wpływ na ogólną wagę strony. Często zawiera on biblioteki i platformy innych firm.

Nie wystarczy powiedzieć: „Przestań używać platform JavaScriptu”, ponieważ platformy przynoszą deweloperom wiele korzyści. Frameworki mogą Ci pomóc w skutecznym tworzeniu kodu i szybkim udostępnianiu funkcji. Zamiast tego powinieneś zapoznać się z informacjami, aby móc podjąć świadomą decyzję, gdy zajdzie taka potrzeba.

Pytanie „Czy mam dziś korzystać z biblioteki czy platformy?” to rzadkie pytanie. Biblioteki i ramy to 2 zupełnie różne rzeczy. Biblioteki i ramy są jednak często mylone, a im więcej wiesz o jednych i drugich, tym większa szansa, że podejmiesz świadome decyzje dotyczące ich użycia.

Przykłady bibliotek i ramek

Kod firm zewnętrznych może występować pod innymi nazwami, takimi jak widżety, wtyczki, polyfille czy pakiety. Zazwyczaj należą one jednak do kategorii biblioteki lub platformy. Różnice między tymi 2 elementami można podsumować w ten sposób:

W przypadku biblioteki kod aplikacji wywołuje kod biblioteki.
W przypadku frameworka kod aplikacji jest wywoływany przez framework.

Biblioteka

Biblioteki są zwykle prostsze niż frameworki i oferują ograniczony zakres funkcji. Jeśli przekazujesz dane wejściowe do metody i otrzymujesz dane wyjściowe, 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 zrozumieć, do czego służy. W tym przypadku magia nie jest potrzebna:

Instrukcja import importuje do programu JavaScript bibliotekę lodash.
Wywoływana jest metoda capitalize().
Metoda otrzymuje 1 argument.
Wartość zwracana jest przechwytywana w zmiennej.

Platforma

Frameworki są zwykle większe niż biblioteki i w większym stopniu wpływają na łączną wagę strony. Framework może zawierać bibliotekę.

Ten przykład pokazuje zwykłą platformę bez biblioteki i korzysta z Vue, która jest popularną platformą 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>

Porównując ten przykład frameworka z wcześniejszym przykładem biblioteki, możesz zauważyć te różnice:

Kod frameworka obejmuje wiele technik i przekształca je w własny interfejs API.
Deweloperzy nie mają pełnej kontroli nad tym, jak i kiedy operacje są wykonywane. Na przykład sposób i czas zapisywania przez Vue ciągu 'Hello, world' na stronie są abstrakcyjne.
Tworzenie instancji klasy Vue powoduje pewne efekty uboczne, które są typowe podczas korzystania z ramek, podczas gdy biblioteka może zawierać czyste funkcje.
Framework określa konkretny system szablonów HTML, zamiast korzystania z Twojego własnego.
Jeśli przeczytasz dokumentację frameworka Vue lub dokumentację większości innych frameworków, dowiesz się, jakie wzorce architektoniczne możesz wykorzystać. Frameworki JavaScripta odciążają Cię od konieczności samodzielnego rozwiązywania problemów, ponieważ nie musisz tego robić samodzielnie.

Kiedy korzystać z biblioteki, a kiedy z platformy

Gdy zapoznasz się z porównaniami bibliotek i platform, możesz się dowiedzieć, kiedy używać jednej z tych platform:

Framework może uprościć Ci, jako deweloperowi, pracę. Jak już wspomnieliśmy, framework może abstrahować logikę, zachowanie, a nawet wzorce architektoniczne. Jest to szczególnie przydatne, gdy zaczynasz nowy projekt. Biblioteka może pomóc w zredukowaniu złożoności, ale zwykle skupia się na ponownym wykorzystywaniu kodu.
Autorzy frameworków chcą, abyś był/aś jak najbardziej wydajny/a, dlatego często opracowują dodatkowe narzędzia, oprogramowanie do debugowania i pełne instrukcje, które ułatwiają skuteczne korzystanie z frameworku. Autorzy bibliotek również chcą, abyś był/aś wydajny/a, ale specjalistyczne narzędzia są w bibliotekach rzadkością.
Większość platform zapewnia funkcjonalny punkt wyjścia, taki jak szkielet lub schemat, który umożliwia szybkie tworzenie aplikacji internetowych. Biblioteka stanie się częścią już istniejącej bazy kodu.
Ogólnie rzecz biorąc, frameworki zwiększają złożoność bazy kodu. Złożoność nie jest zawsze oczywista na początku, ale może się ujawnić z czasem.

Przypominamy, że zwykle nie porównujesz biblioteki z platformą, ponieważ są to różne rzeczy, które realizują różne zadania. Im więcej jednak wiesz o tych dwóch opcjach, tym łatwiej Ci będzie zdecydować, która z nich jest dla Ciebie najlepsza. Decyzja o użyciu frameworku lub biblioteki zależy od Twoich wymagań.

Wymienne

Biblioteki ani frameworka nie zmienia się co tydzień. Warto jednak poznać wady pakietu, który zmusza Cię do korzystania z jego ekosystemu. Należy też pamiętać, że deweloper, który zdecyduje się użyć pakietu innej firmy, ponosi pewną odpowiedzialność za stworzenie luźnego połączenia między pakietem a kodem źródłowym aplikacji.

Pakiet powiązany z kodem źródłowym jest trudniejszy do usunięcia i wymiany na inny pakiet. Zmiana pakietu może być konieczna, gdy:

Musisz wprowadzić aktualizacje w pakiecie, który nie jest już obsługiwany.
Okazuje się, że pakiet ma zbyt dużo błędów, aby można było z niego korzystać.
dowiesz się o nowym pakiecie, który lepiej odpowiada Twoim potrzebom;
wymagania dotyczące produktu ulegają 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 pakiet zewnętrzny @package/set-color jest używany w 3 osobnych plikach. Jeśli pracujesz nad tym kodem i musisz zastąpić pakiet zewnętrzny, musisz zaktualizować kod w 3 miejscach.

Możesz też uprościć konserwację i użyć biblioteki w jednym miejscu, jak 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 użycie biblioteki jest abstrakcyjne. Jeśli więc musisz zastąpić pakiet zewnętrzny, wystarczy zaktualizować tylko jeden plik. Ponadto kod jest teraz łatwiejszy w użyciu, ponieważ wewnętrzny plik set-color.js ustawia domyślny motyw kolorów.

Łatwość używania

Framework może mieć złożony interfejs API, ale może też udostępniać narzędzia dla programistów, które ułatwiają jego ogólne używanie. Łatwość obsługi zależy od wielu czynników i może być bardzo subiektywna. Framework może być trudny w użyciu z tych powodów:

Platforma ma z założenia złożony interfejs API.
Platforma jest słabo udokumentowana i wymaga wielu prób i błędów, aby rozwiązać problemy.
Framework używa technik, które są nieznane Tobie i Twojemu zespołowi.

Ramy te mogą pomóc w rozwiązaniu tych problemów dzięki sprawdzonym metodom, takim jak:

Framework udostępnia narzędzia dla programistów i narzędzia diagnostyczne, które ułatwiają debugowanie.
Framework ma aktywną społeczność deweloperów, którzy współpracują przy tworzeniu bezpłatnej dokumentacji, przewodników, samouczków i filmów. Po zapoznaniu się z tymi treściami możesz efektywnie korzystać z ramy.
Platforma udostępnia interfejs API zgodny z popularnymi konwencjami kodowania. Framework jest wydajny, ponieważ wcześniej nauczyłeś się takich konwencji i znasz lepiej style kodowania.

Te punkty są zwykle przypisywane frameworkom, ale można je też przypisać bibliotekom. Na przykład biblioteka JavaScript D3.js jest wydajna i ma duży ekosystem, w którym można znaleźć warsztaty, przewodniki i dokumentację, z których każdy jest łatwy w użyciu.

Dodatkowo platforma zazwyczaj określa architekturę aplikacji internetowej, podczas gdy biblioteka jest zwykle zgodna z dotychczasową architekturą – cokolwiek to jest.

Wyniki

Ogólnie rzecz biorąc, frameworky mogą mieć większy wpływ na wydajność niż biblioteki, ale są od tego wyjątki. Wydajność stron internetowych to ogromny obszar obejmujący wiele zagadnień, dlatego w tych sekcjach omówiliśmy 2 ważne tematy: wstrząsanie drzew i aktualizacje oprogramowania.

potrząsanie drzewem

Łączenie w pakiety to tylko jeden z aspektów wydajności stron internetowych, ale może mieć duży wpływ na wydajność, zwłaszcza w przypadku dużych bibliotek. Użycie redukcji drzewa podczas importowania i eksportowania pomaga zwiększyć wydajność, ponieważ znajduje i usuwanie kodu, który jest niepotrzebny w aplikacji.

Gdy tworzysz pakiet kodu JavaScript, możesz wykonać przydatny krok, tzw. usuwanie zbędących elementów drzewa, który stanowi cenną optymalizację kodu, choć łatwiej jest go wykonać w przypadku bibliotek niż frameworków.

Podczas importowania kodu innej firmy do kodu źródłowego zwykle umieszczasz go w jednym lub kilku plikach wyjściowych. Na przykład pliki header.js, footer.js i sidebar.js są łączone w pliku output.js, który jest plikiem wyjściowym wczytywanym w aplikacji internetowej.

Aby lepiej zrozumieć wstrząsanie drzewa, 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));

W celu demonstracji przykład kodu library.js jest celowo mały w porównaniu z tym, co można znaleźć w rzeczywistych bibliotekach, które mogą zawierać tysiące linii kodu.

Naiwny proces tworzenia pakietu może wyeksportować kod z takimi wynikami:

// 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 i tak znajduje się w ostatecznym pakiecie. Niepotrzebny kod, taki jak ten, zwiększa rozmiar pobierania, czas analizowania i kompilacji oraz koszty wykonywania, które ponoszą użytkownicy. Podstawowe podejście do usuwania niepotrzebnego kodu usuwa martwy kod i generuje ten wynik:

// 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 znikomy, ale w rzeczywistej aplikacji, w której biblioteka ma tysiące wierszy, efekt może być znacznie większy. Co ciekawe, nowoczesne narzędzia do tworzenia pakietów, takie jak Parcel, Webpack i Rollup, idą o krok dalej, ponieważ łączą minifikację i tree shaking, aby utworzyć bardzo zoptymalizowany pakiet. Aby zademonstrować skuteczność narzędzi pakietów, skorzystaliśmy z narzędzia Parcel i utworzyliśmy plik pakietu z poprzednimi przykładami kodu. Parcel usunął cały nieużywany kod i wyeksportował ten pojedynczy moduł:

console.log(7+10);

Parcel jest na tyle inteligentny, że usuwa instrukcje importu, definicje funkcji i zachowanie, aby utworzyć w pełni zoptymalizowany kod.

Pakowanie to tylko jeden z aspektów wydajności strony internetowej, ale ma on duży wpływ na wydajność, zwłaszcza w przypadku większych bibliotek. Trzęsienie się drzew jest zwykle łatwiejsze za pomocą bibliotek niż za pomocą platform.

Aktualizacje oprogramowania

W przypadku wielu bibliotek i ramek aktualizacje oprogramowania dodają funkcje, naprawiają błędy i ostatecznie zwiększają rozmiar. Nie zawsze trzeba pobierać aktualizacji, ale jeśli zawierają one poprawki błędów, ulepszenia funkcji lub poprawki zabezpieczeń, warto je zainstalować. Im więcej danych przesyłasz przez sieć, tym słabsza jest wydajność aplikacji, a tym większy wpływ na wrażenia użytkownika.

Jeśli biblioteka się powiększy, możesz potrząsać drzewami, by powstrzymać ich wzrost. Możesz też użyć mniejszej biblioteki JavaScript. Więcej informacji znajdziesz w artykule Wymiana.

Jeśli framework rośnie, nie tylko staje się trudniejsze do zrzucanie drzewa, ale też trudniej jest zastąpić jeden framework innym. Więcej informacji znajdziesz w artykule Wymiana.

Zdolność do pracy

Nie jest tajemnicą, że wiele firm ma rygorystyczne wymagania dotyczące deweloperów, którzy znają dany framework. Mogą nie zwracać uwagi na Twoją wiedzę o podstawach sieci, a skupić się tylko na Twojej wiedzy o konkretnej platformie JavaScript. Niezależnie od tego, czy jest to słuszne, jest to rzeczywistość w przypadku wielu zawodów.

Znajomość kilku bibliotek JavaScript nie zaszkodzi w Twoim zgłoszeniu o pracę, ale nie ma też gwarancji, że wyróżni Cię ona na tle innych kandydatów. Jeśli dobrze znasz kilka popularnych platform JavaScript, z dużym prawdopodobieństwem uznają ją za pozytywną na obecnym rynku pracy dla twórców stron internetowych. Niektóre duże organizacje stosują bardzo stare frameworki JavaScriptu i mogą nawet rozpaczliwie szukać kandydatów, którzy znają się na takich frameworkach.

Możesz wykorzystać tę otwartą tajemnicę na swoją korzyść. Pamiętaj jednak, że na rynku pracy należy zachować ostrożność i brać pod uwagę te kwestie:

Pamiętaj, że jeśli w swojej karierze będziesz spędzać dużo czasu, korzystając tylko z jednej struktury, możesz przegapić doświadczenia edukacyjne związane z innymi, bardziej nowoczesnymi rozwiązaniami.
Wyobraź sobie programistę, który nie zna dobrze podstaw tworzenia oprogramowania ani stron internetowych, ale został zatrudniony jako programista frameworków. Ten programista nie pisze skutecznego kodu, a praca nad taką bazą kodu może być przytłaczająca. W niektórych przypadkach może to prowadzić do wypalenia. Możesz na przykład potrzebować przeformułowania kodu lub dostosowania go pod kątem wydajności, ponieważ jest on zbyt wolny.
Gdy uczysz się tworzenia stron internetowych, najlepiej zacząć od opanowania podstaw tworzenia stron internetowych, tworzenia oprogramowania i inżynierii oprogramowania. Tak solidne podstawy pomagają w szybkim i efektywnym opanowaniu dowolnej platformy JavaScript.

Podsumowanie

Gratulacje za zrozumienie różnic między frameworkami i bibliotekami JavaScript. Nie będziesz często wybierać platform ani bibliotek, chyba że pracujesz nad projektami greenfield lub jesteś konsultantem. Jednak gdy takie decyzje się pojawią, im więcej wiesz na dany temat, tym lepsze będą Twoje decyzje.

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