Współczesna inżynieria frontendowa zupełnie nie przypomina tego, co działo się dekadę temu. Nie piszesz już tylko HTML i CSS. Typowy projekt jest teraz dostarczany wraz z konkretnym środowiskiem uruchomieniowym Node.js, zablokowaną wersją menedżera pakietów, plątaniną narzędzi budujących oraz potokami wdrożeniowymi, które wymagają idealnej synchronizacji wszystkiego. Gdzieś pomiędzy pierwszym npm install a finalnym buildem produkcyjnym pojawiają się drobne różnice. Kolega z zespołu używa Node 20. Ty używasz Node 18. Globalne narzędzie CLI na Twoim komputerze maskuje brakującą zależność na jego maszynie. Wtedy pada zdanie, którego nikt nie chce słyszeć: „U mnie działa”.

Docker zasługuje na swoje miejsce w Twoim zestawie narzędzi frontendowych, ponieważ eliminuje tę niepewność. Pakuje on Twoją aplikację wraz z dokładnym środowiskiem uruchomieniowym, bibliotekami systemowymi i zależnościami, których ona potrzebuje. Niezależnie od tego, czy kodujesz na Windowsie, wypuszczasz wersję z macOS, czy wdrażasz ją na instancję chmurową Linux, zachowanie aplikacji pozostaje identyczne.

Dlaczego frontend developerzy powinni o to dbać

Problemy, które rozwiązuje Docker, nie są abstrakcyjne. Pojawiają się w każdym sprincie.

Konflikty wersji marnują czas. Jeden starszy projekt dla klienta wymaga Node 18, Twój projekt poboczny potrzebuje Node 20, a nowa praca w startupie wymaga Node 22. Bez kontenerów zarządzasz tym za pomocą menedżerów wersji. To działa, dopóki nie przestaje działać. Nawet drobna niezgodność wersji npm może zmienić sposób rozwiązywania peer dependencies, pozostawiając Cię z niedziałającym buildem, który u kogoś innego działa bez problemów. Gdy framework ogłasza nową wersję, pętla zwrotna nie powinna składać się z dwóch godzin reinstalacji. Powinna to być pojedyncza zmiana w pliku i restart kontenera.

Globalne pakiety to kolejne źródło cichych tarć. Możesz mieć zainstalowane globalnie Angular CLI, Expo lub Prisma sprzed sześciu miesięcy. Nowy programista instaluje to samo narzędzie na nowo i otrzymuje inną wersję. Nagle Twoje skrypty budujące wyrzucają ostrzeżenia, które nie pojawiają się nigdzie indziej. Docker rozwiązuje ten problem, utrzymując wszystko lokalnie w projekcie. Definiujesz wersję Node w swoim Dockerfile. Zależności instalują się wewnątrz kontenera, w izolacji od Twojego systemu operacyjnego. Twój laptop może mieć macOS, Windows lub Ubuntu; aplikacja za każdym razem widzi dokładnie to samo środowisko.

Korzyści z onboardingu są trudne do zignorowania. Nowi pracownicy nie potrzebują trzystronnego pliku README opisującego instalację Homebrew, aliasy nvm i poprawki uprawnień globalnych. Instalują Dockera, klonują repozytorium i uruchamiają jedną komendę. Konfigur