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ść frameworka 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 pogarsza się z czasem, co ma wpływ 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 wdrażaniu funkcji. Zamiast tego powinieneś zapoznać się z informacjami, aby móc podjąć świadomą decyzję, gdy zajdzie taka potrzeba.
Pytanie „Czy powinienem użyć biblioteki czy frameworku?” nie jest częstym dylematem. 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. Jednak wszystkie one zwykle należą 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.
Oto 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 frameworku 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 używać biblioteki, a kiedy frameworku
Po przeczytaniu porównania bibliotek i platform możesz zacząć rozumieć, kiedy używać jednej lub drugiej:
- 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 rzadkie.
- Większość frameworków zapewnia funkcjonalny punkt wyjścia, np. szkielet lub szablon, aby ułatwić szybkie tworzenie aplikacji internetowych. Biblioteka staje 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 biblioteki i ramki nie są porównywalne, ponieważ służą do różnych celów. 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ń.
Możliwość wymiany
Biblioteki ani frameworka nie zmienia się co tydzień. Warto jednak poznać wady pakietu, który zmusza Cię do korzystania z jego ekosystemu. Pamiętaj też, ż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. Wymiana 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ł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.
- Framework udostępnia interfejs API, który jest zgodny ze wspólnymi konwencjami kodowania. Framework jest wydajny, ponieważ wcześniej poznaliśmy takie konwencje i znacznie lepiej znamy style kodowania.
Te punkty są zwykle przypisywane frameworkom, ale można je też przypisać bibliotekom. Na przykład biblioteka JavaScript D3.js jest potężna i ma duży ekosystem, który obejmuje warsztaty, przewodniki i dokumentację, a wszystkie te zasoby wpływają na łatwość jej używania.
Ponadto framework zwykle określa architekturę aplikacji internetowej, podczas gdy biblioteka jest zwykle zgodna z dotychczasową architekturą.
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
Pakowanie to tylko jeden z aspektów wydajności witryny, ale ma on duży wpływ na wydajność, zwłaszcza w przypadku większych 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, który polega na pozbyciu się zbędących części kodu (tzw. tree shaking). Jest to przydatna optymalizacja kodu, która jest jednak łatwiejsza do wykonania 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.
Prosty proces tworzenia pakietu może eksportować kod z tymi 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));
Chociaż funkcja subtract()
nie jest potrzebna w tej aplikacji, jest ona nadal uwzględniona w ostatecznym pakiecie. Taki niepotrzebny kod zwiększa rozmiar pobierania, czas analizowania i kompilowania oraz koszty wykonania, które muszą ponieść 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 do tworzenia pakietów, użyliśmy narzędzia Parcel do utworzenia pliku 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 witryny, ale ma on duży wpływ na wydajność, zwłaszcza w przypadku większych bibliotek. Wyłączanie elementów w drzewie jest zwykle łatwiejsze w przypadku bibliotek niż ram.
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ę rozrasta, możesz użyć potrząsania drzewa, aby ograniczyć jej rozmiar. 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 znasz bardzo dobrze kilka popularnych frameworków JavaScript, istnieje duże prawdopodobieństwo, że pracodawcy uznają te umiejętności za korzystne na obecnym rynku pracy dla programistó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ć ten otwarty sekret na swoją korzyść. Jednak na rynku pracy należy zachować ostrożność i brać pod uwagę te kwestie:
- Pamiętaj, że jeśli w trakcie swojej kariery poświęcasz dużo czasu na korzystanie z tylko jednej platformy, możesz nie mieć okazji do nauki obsługi innych, nowszych platform.
- 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. Dzięki temu będziesz w stanie szybko i skutecznie opanować dowolny framework JavaScript.
Podsumowanie
Gratulacje za zrozumienie różnic między frameworkami i bibliotekami JavaScript. Nie będziesz często wybierać frameworków ani bibliotek, chyba że pracujesz nad nowymi projektami lub jesteś konsultantem. Jednak gdy takie decyzje się pojawią, im więcej wiesz na dany temat, tym lepsze będą Twoje decyzje.
Jak już wiesz, wybór platformy, a w niektórych przypadkach także biblioteki, może mieć znaczący wpływ na proces tworzenia i wygodę użytkowników, np. na wydajność.