Backbone.js to biblioteka sprzed epoki komponentów, wciąż utrzymywana i wciąż stojąca pod starszymi panelami. Opis jej mechanizmu i kosztu ręcznego sprzątania po widokach.
Backbone.js pojawia się dziś zwykle w jednej sytuacji: ktoś otwiera panel administracyjny albo aplikację wewnętrzną napisaną kilkanaście lat temu, widzi katalog z plikami o nazwach model, view i collection, i próbuje ustalić, czym to w ogóle jest. To biblioteka JavaScriptu z 2010 roku, autorstwa Jeremy'ego Ashkenasa, wydana na licencji MIT.
Sposób jej działania najlepiej oddaje radiowęzeł w hali produkcyjnej. Dane siedzą w jednym miejscu i przez głośniki ogłaszają każdą swoją zmianę. Stanowiska zapisane na dany kanał słyszą komunikat i same przerysowują to, co mają przed sobą. Nikt nikogo nie odpytuje, komunikat idzie w jedną stronę.
Powstała, kiedy typowa aplikacja przeglądarkowa była zbiorem funkcji dopiętych do elementów strony, a stan trzymało się w atrybutach HTML i w zmiennych globalnych. Backbone.js zaproponował wtedy minimum porządku: dane osobno, wygląd osobno, adresy osobno.
Całość składa się z pięciu pojęć. Model trzyma zestaw danych jednej rzeczy. Kolekcja trzyma zbiór modeli. Widok odpowiada za kawałek strony i za reakcje na kliknięcia. Router wiąże adres w pasku przeglądarki z funkcją, którą trzeba wywołać. Zdarzenia spinają to wszystko razem. Biblioteka nie dostarcza silnika szablonów ani sposobu na budowanie interfejsu, bo to była świadoma decyzja jej autora.
Zmiana wartości w modelu wywołuje zdarzenie. Kto się na to zdarzenie zapisał, dostaje powiadomienie i wykonuje swoją funkcję, zwykle przerysowanie fragmentu strony. Kolekcja ogłasza z kolei dodanie i usunięcie pozycji oraz przekazuje dalej komunikaty pochodzące od swoich modeli.
Rysowanie jest tu ręczne i to jest sedno różnicy wobec późniejszych narzędzi. Funkcja odpowiedzialna za wyświetlenie sama składa kawałek HTML, wstawia go w element widoku i podpina zdarzenia myszy. Nikt nie porównuje starej wersji strony z nową, nikt nie wylicza minimalnej zmiany. Programista decyduje, co dokładnie i kiedy zostanie odświeżone.
Zapis modelu wysyła żądanie do serwera, a kolekcja potrafi pobrać listę spod wskazanego adresu. Domyślnie odpowiada to zwykłemu API opartemu na metodach protokołu HTTP, więc pobranie listy to zapytanie na adres zasobu, a zapis nowej pozycji to wysłanie jej pod ten sam adres.
Zależność jest jedna i twarda: biblioteka wymaga Underscore. Do obsługi elementów strony i żądań sieciowych korzysta z jQuery albo zgodnego zamiennika, ale samo trzymanie danych działa i bez tego. Router obsługuje adresy zarówno w wersji z fragmentem po krzyżyku, jak i w wersji z prawdziwą ścieżką, przy czym ta druga wymaga ustawienia serwera, żeby odświeżenie strony pod głębokim adresem nie kończyło się błędem.
Różnica jest głębsza niż składnia. React opisuje, jak interfejs ma wyglądać dla danego stanu, i sam wylicza, co zmienić w drzewie strony. Tutaj to programista pisze instrukcję, jak przejść ze stanu poprzedniego do następnego, i sam pamięta o odpięciu tego, co przestało być potrzebne.
Angular w wersji z lat, gdy obie rzeczy konkurowały, dorzucał dwustronne wiązanie danych i wstrzykiwanie zależności. Backbone.js nie ma ani jednego, ani drugiego. Za to nie narzuca struktury projektu, więc dwie aplikacje na tej samej bibliotece potrafią być zbudowane zupełnie inaczej, co przy przejmowaniu cudzego kodu bywa kłopotem większym niż sama technologia.
Projekt nie został porzucony i to warto powiedzieć wprost, bo bywa opisywany jako martwy. Opiekę nad nim przejął Julian Gonggrijp w grudniu 2021 roku, repozytorium nie jest zarchiwizowane, a poprawki i zmiany w dokumentacji trafiały do niego jeszcze w połowie 2026 roku. Ostatnie wydanie oznaczone numerem 1.6.1 ukazało się 1 kwietnia 2025 roku.
Trzeba jednak czytać to uczciwie. Tempo prac odpowiada bibliotece w stanie stabilnym, wydania pojawiają się co kilkanaście miesięcy i przynoszą poprawki, a nie nowe możliwości. Społeczność, materiały i pytania na forach przeniosły się dawno gdzie indziej, więc problem rzadszy niż typowy rozwiązuje się dziś czytaniem źródeł, a nie wyszukiwarką.
Tu znowu przydaje się radiowęzeł. Stanowisko zlikwidowano, ale nikt nie wypisał go z kanału, więc głośnik dalej nadaje w pustą przestrzeń, a komunikaty gromadzą się bez odbiorcy. W przeglądarce wygląda to tak, że widok został usunięty ze strony, lecz nadal jest zapisany na zdarzenia modelu, więc zostaje w pamięci razem z całym poddrzewem elementów, do którego się odwołuje.
Objaw jest charakterystyczny: aplikacja działa szybko po odświeżeniu i muli po godzinie pracy, a każde przejście między ekranami dokłada kolejną kopię tego samego nasłuchu. Kliknięcie potrafi wtedy wywołać tę samą akcję kilka razy. Lekarstwo jest znane, czyli jawne odpinanie nasłuchów przy usuwaniu widoku, tylko trzeba o nim pamiętać w każdym miejscu, bo biblioteka nie zrobi tego sama.
Przy nowym interfejsie, który ma żyć latami i przechodzić między zespołami, wybór padnie rozsądniej na narzędzie z żywym rynkiem pracy i aktualnymi materiałami. Argument nie brzmi „technologia jest zła”, tylko „za trzy lata trudno będzie znaleźć kogoś, kto zechce to utrzymywać”.
Odwrotna sytuacja też ma swoją odpowiedź. Działająca aplikacja z ustabilizowanym zakresem, do której zmiany wchodzą kilka razy w roku, nie wymaga przepisania na siłę. Przepisanie kosztuje tyle, co napisanie od nowa, i przywraca wszystkie błędy wyprostowane przez lata użytkowania.
Mogę Ci jakoś pomóc?
Stary komputer w zakurzonym garażu jako serwer, dodatkowo z przepełnionymi dyskami, to sposób na katastrofę, a nie nowoczesna firma. Zmigorwaliśmy infrastrukturę klienta na bezpieczne środowisko i uporządkowaliśmy to co nas zaskoczyło w systemach.
Czytaj wpisKlikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.