Phoenix LiveView vs React - porównanie, które powinien zobaczyć każdy CTO

Gdy firma planuje nowy system webowy, pytanie o frontend brzmi zwykle: "React czy Vue?". To jak pytanie "BMW czy Mercedes?" - obie odpowiedzi zakładają, że potrzebujesz samochodu. A co, jeśli Twój problem lepiej rozwiązuje tramwaj?

Phoenix LiveView to fundamentalnie inne podejście do budowy interaktywnych aplikacji. Nie jest "kolejnym frameworkiem JavaScript". Nie konkuruje z Reactem na tym samym polu - zmienia pole gry. Ten artykuł nie jest flamewarem. To analiza dla ludzi, którzy podejmują decyzje technologiczne i ponoszą ich konsekwencje finansowe.

Dwa modele, dwie filozofie

Model React: ciężki klient

React to architektura, w której przeglądarka użytkownika jest pełnoprawną aplikacją:

1. Serwer wysyła pusty HTML + bundle JavaScript (500KB-2MB)
2. Przeglądarka pobiera JS, parsuje, wykonuje, renderuje interfejs
3. Aplikacja w przeglądarce zarządza stanem, routingiem, cache'em
4. Komunikacja z serwerem przez REST API lub GraphQL
5. Stan istnieje w dwóch miejscach: przeglądarka i serwer

To oznacza, że de facto budujesz dwie aplikacje: frontend w TypeScript i backend w wybranym języku. Dwie bazy kodu, dwa zestawy testów, dwa pipeline'y deploymentu.

Model LiveView: inteligentny serwer

LiveView odwraca ten model:

1. Serwer wysyła wyrenderowany HTML (gotowy do wyświetlenia)
2. Przeglądarka ładuje minimalny klient JavaScript (~30KB)
3. Klient nawiązuje połączenie WebSocket z serwerem
4. Każda interakcja (klik, wpisanie tekstu) idzie do serwera
5. Serwer oblicza nowy stan i wysyła diff HTML
6. Klient podmienia zmienione fragmenty DOM

Stan istnieje w jednym miejscu: na serwerze. Jedna baza kodu, jeden język, jeden deployment.

Porównanie z perspektywy biznesu

Koszt zespołu

To największa różnica, o której mało kto mówi wprost.

React: Potrzebujesz minimum dwóch specjalizacji: frontend developer (React, TypeScript, state management, bundlery) i backend developer (Node/Python/Go/Java, API design, baza danych). W praktyce to osobne osoby. Senior React developer w Polsce to 25 000-35 000 PLN brutto. Senior backend to podobnie. Masz dwóch programistów do jednego projektu.

Do tego dochodzi potrzeba koordynacji: kontrakt API między frontem a backendem, synchronizacja wersji, wspólne code review. Każda zmiana w logice biznesowej wymaga zmian w dwóch miejscach. Każdy bug może być "na froncie" albo "na backendzie" - najpierw musisz ustalić gdzie.

LiveView: Potrzebujesz jednej specjalizacji: programista Elixir/Phoenix. Pisze backend, pisze interfejs, pisze testy. Jedna osoba widzi cały obraz - od zapytania do bazy danych po przycisk na ekranie. Zmiana w logice biznesowej to zmiana w jednym pliku.

Różnica w kosztach: Przy projekcie, który w React wymaga 2 programistów na 6 miesięcy, LiveView wymaga 1 programisty na 4-5 miesięcy. Nie dlatego, że programista LiveView jest szybszy - dlatego, że nie traci czasu na koordynację między frontem a backendem, na pisanie i utrzymywanie API, na synchronizację stanu między klientem a serwerem.

Czas dostarczenia (Time to Market)

React: Typowy flow dodania nowej funkcji "filtrowanie zamówień po statusie":

1. Backend: endpoint API GET /api/orders?status=pending + testy
2. Backend: dokumentacja API (Swagger/OpenAPI)
3. Frontend: komponent OrderFilter + stan + wywołanie API
4. Frontend: obsługa loading state, error state, empty state
5. Frontend: cache (React Query / SWR) - kiedy odświeżyć?
6. Frontend: testy komponentu
7. Integracja: test end-to-end
8. Deploy: dwa artefakty (frontend build + backend)

LiveView: Ten sam feature:

1. Elixir: handle_event "filter", query do bazy, assign do socket
2. Template: formularz z selectem, tabela z wynikami
3. Test: jeden test LiveView
4. Deploy: jeden artefakt

# Cała implementacja filtrowania - backend + frontend w jednym
def handle_event("filter", %{"status" => status}, socket) do
  zamowienia = Zamowienia.list(status: status)
  {:noreply, assign(socket, zamowienia: zamowienia, filtr: status)}
end

<form phx-change="filter">
  <select name="status">
    <option value="">Wszystkie</option>
    <option value="pending" selected={@filtr == "pending"}>Oczekujące</option>
    <option value="shipped" selected={@filtr == "shipped"}>Wysłane</option>
  </select>
</form>

<table>
  <tr :for={z <- @zamowienia}>
    <td><%= z.numer %></td>
    <td><%= z.status %></td>
    <td><%= z.wartosc %> PLN</td>
  </tr>
</table>

To wszystko. Filtrowanie działa w czasie rzeczywistym, bez przeładowania strony, bez pisania API, bez zarządzania stanem po stronie klienta. Zmiana filtra wysyła event do serwera, serwer odpytuje bazę i wysyła zaktualizowany HTML.

Różnica: Feature, który w React zajmuje 2-3 dni (z API, stanem, testami), w LiveView zajmuje 2-3 godziny.

Złożoność utrzymania

React po 2 latach:

• 200+ komponentów
• 15+ zależności npm wymagających aktualizacji (i łamania breaking changes)
• State management, który nikogo nie obchodzi refaktoryzować
• Bundle size, który urósł z 500KB do 2MB
• Testy E2E, które się sypią na CI, bo Playwright/Cypress mają swoje humory
• Nowy programista potrzebuje 2-4 tygodnie na zrozumienie architektury frontu

LiveView po 2 latach:

• Moduły LiveView z handlerami zdarzeń
• ~20 zależności Hex (Elixir package manager) - stabilnych, wersjonowanych semantycznie
• Stan zawsze na serwerze - jedno źródło prawdy
• 30KB klienta JavaScript - nie rośnie z rozmiarem aplikacji
• Testy LiveView uruchamiane w milisekundach, bez przeglądarki
• Nowy programista Elixir jest produktywny w dni, nie tygodnie

Kluczowa różnica: W React złożoność rośnie wykładniczo z rozmiarem aplikacji. Każdy nowy komponent potencjalnie wchodzi w interakcję z globalnym stanem, routingiem, cache'em. W LiveView złożoność rośnie liniowo - nowy moduł LiveView jest izolowany, ma swój stan, nie wpływa na resztę systemu.

Ekosystem npm vs Hex

To temat, o którym CTO powinien wiedzieć, bo wpływa na bezpieczeństwo i stabilność.

npm (React):

• Średni projekt React ma 200-500 zależności (włącznie z transitywnymi)
• node_modules waży 200MB-1GB
• Incydent left-pad (2016) - usunięcie 11-linijkowej biblioteki złamało tysiące projektów na świecie
• Incydenty supply chain attack (event-stream, ua-parser-js, colors.js) - złośliwy kod w popularnych pakietach
• Breaking changes w major versions - migracja z React 17 do 18, z webpack do Vite, z Create React App (zdeprecjonowany) do Next.js
• npm audit regularnie pokazuje dziesiątki vulnerabilities (często fałszywe alarmy, ale kto to sprawdzi?)

Hex (Elixir):

• Średni projekt Phoenix ma 15-30 zależności
• Ekosystem jest mniejszy, ale bardziej stabilny
• Semantic versioning jest traktowane poważnie - breaking changes są rzadkie i dobrze komunikowane
• Społeczność ceni jakość nad ilość - mniej bibliotek, ale lepiej utrzymanych
• mix deps.audit - proste, czytelne raportowanie

Mniej zależności = mniejsza powierzchnia ataku = mniej niespodzianek o 3 w nocy.

Bezpieczeństwo aplikacji

To argument, który rzadko pojawia się w porównaniach frameworków, a powinien być na pierwszym miejscu.

React - logika w przeglądarce:

• Walidacja po stronie klienta? Użytkownik może ją wyłączyć w DevTools
• Ukrywanie elementów CSS-em (display: none)? Dane nadal są w DOM
• Kontrola dostępu w komponencie React? Można ją obejść wywołując API bezpośrednio
• Każdy endpoint API musi sam walidować uprawnienia - bo frontend jest niezaufany
• Token JWT w localStorage? XSS = kradzież sesji

Programiści React to wiedzą i implementują zabezpieczenia po stronie backendu. Ale to podwójna praca - logika uprawnień raz na froncie (UX), raz na backendzie (bezpieczeństwo). I wystarczy, że ktoś zapomni o backendzie...

LiveView - logika na serwerze:

• Walidacja? Na serwerze. Nie da się jej obejść
• Kontrola dostępu? Na serwerze. Użytkownik widzi tylko to, co mu wyślesz
• Dane wrażliwe? Nigdy nie opuszczają serwera. W przeglądarce jest tylko HTML
• Brak API do zaatakowania - przeglądarka komunikuje się przez WebSocket z binarnymi diffami
• Brak tokenów w przeglądarce - sesja żyje w procesie BEAM na serwerze

To nie jest "trochę bezpieczniejsze". To fundamentalnie inna powierzchnia ataku. W LiveView cała klasa podatności (XSS przez stan klienta, manipulacja API, kradzież tokenów) po prostu nie istnieje.

SEO i pierwszy render

React (CSR - Client-Side Rendering):

• Przeglądarka dostaje pusty <div id="root"></div>
• Google musi wykonać JavaScript, żeby zobaczyć treść (robi to, ale wolniej indeksuje)
• First Contentful Paint: 1-3 sekundy (pobranie + parsowanie + wykonanie JS)
• Rozwiązania: SSR (Next.js), SSG, RSC - ale każde dodaje złożoność

LiveView:

• Przeglądarka dostaje gotowy HTML z pierwszym renderem
• Google widzi pełną treść natychmiast - zero JavaScript wymagane do indeksowania
• First Contentful Paint: 50-200ms
• Zero dodatkowej konfiguracji - to domyślne zachowanie

Dla aplikacji biznesowych (dashboardy, panele admin) SEO nie ma znaczenia. Ale dla e-commerce, stron produktowych, landing pages - LiveView daje SEO za darmo, bez SSR/SSG/RSC.

Wydajność na słabych urządzeniach

React: Twoja aplikacja działa na urządzeniu użytkownika. Jeśli użytkownik ma 5-letni telefon z Androidem za 500 zł, React będzie na nim zamulał. 2MB JavaScriptu do sparsowania, virtual DOM do obliczenia, re-rendery przy każdej interakcji. Nie masz kontroli nad sprzętem swoich użytkowników.

LiveView: Twoja aplikacja działa na Twoim serwerze. Użytkownik z 5-letnim telefonem dostaje taki sam performance jak użytkownik z MacBookiem Pro - bo obliczenia robi serwer, a przeglądarka tylko podmienia fragmenty HTML. Kontrolujesz sprzęt, na którym działa Twoja aplikacja.

Dla systemów B2B, gdzie użytkownicy pracują na firmowych komputerach różnej jakości, to realna przewaga. Magazynier ze skanerem, handlowiec ze starym tabletem, księgowa z komputerem sprzed 7 lat - wszyscy mają ten sam performance.

Skalowalność i koszty infrastruktury

Tu React ma teoretyczną przewagę, o której warto powiedzieć uczciwie.

React (statyczny hosting):

• Frontend to pliki statyczne - hosting za grosze (Cloudflare Pages, Vercel, S3)
• Obliczenia robi przeglądarka użytkownika - zero kosztów serwera na rendering
• Backend skaluje się tylko na logikę biznesową i bazę danych

LiveView (serwer renderuje):

• Każdy użytkownik to proces na serwerze + połączenie WebSocket
• Serwer robi obliczenia, które w React robi przeglądarka
• Więcej użytkowników = więcej zasobów serwera

Ale kontekst ma znaczenie. Typowy serwer z 8GB RAM obsługuje 100 000+ jednoczesnych połączeń LiveView dzięki BEAM. Przy 1000 jednoczesnych użytkowników (typowy system ERP/CRM) to ułamek zasobów. Przy 100 000 jednoczesnych użytkowników zaczynasz myśleć o skalowaniu - ale wtedy koszt dodatkowego serwera jest ułamkiem kosztu zespołu developerskiego.

Policzmy: Dodatkowy serwer to 500-2000 PLN miesięcznie. Dodatkowy programista React do utrzymania frontendu to 25 000+ PLN miesięcznie. Ekonomia jest jasna do momentu, gdy masz miliony jednoczesnych użytkowników.

Kiedy React ma sens

Uczciwie - są scenariusze, w których React jest lepszym wyborem:

Aplikacje offline-first - LiveView wymaga połączenia z serwerem. Jeśli Twoi użytkownicy pracują w terenie bez internetu (geolodzy, leśnicy, serwisanci), potrzebujesz PWA z React + service workerami.

Edytory graficzne i gry - Figma, Canva, Miro. Ciężkie operacje na Canvas/WebGL, drag & drop z submilisekundową responsywnością. Tu przeglądarka musi robić ciężkie obliczenia lokalne.

Istniejący duży zespół React - masz 10 programistów React, pipeline CI/CD, bibliotekę komponentów. Przebudowa na LiveView to koszt rekrutacji i szkolenia. Warto? Zależy od horyzontu czasowego.

Publiczne API jako produkt - budujesz platformę, której klienci integrują się przez API (Stripe, Twilio). API i tak musisz mieć - frontend w React jest naturalnym klientem tego API.

Miliony jednoczesnych użytkowników na tanim hostingu - Facebook, Twitter. Przy skali miliardów użytkowników koszt serwerowego renderingu jest istotny. Ale jeśli budujesz system na tę skalę, ten artykuł nie jest dla Ciebie.

Kiedy LiveView wygrywa

Systemy wewnętrzne firm (ERP, CRM, helpdesk) - 50-5000 użytkowników, bogate formularze, tabele, dashboardy. Naturalny habitat LiveView. Jeden programista zamiast dwóch, szybsze dostarczanie, prostsze utrzymanie.

Dashboardy i monitoring - dane aktualizujące się w czasie rzeczywistym. LiveView robi to natywnie, React wymaga dodatkowej infrastruktury (WebSocket, state sync).

Aplikacje collaborative - wielu użytkowników edytujących te same dane. BEAM z procesami izolującymi każdą sesję + LiveView z real-time updates = architektura, która to obsługuje z automatu.

MVP i prototypy - czas do rynku jest krytyczny. Jeden programista, jeden język, jedna baza kodu. Prototyp w tygodnie zamiast miesiące.

Systemy z wysokimi wymaganiami bezpieczeństwa - fintech, medtech, dane wrażliwe. Mniej kodu w przeglądarce = mniejsza powierzchnia ataku.

Podsumowanie: tabela decyzyjna

Co rekomendujemy

Dla większości systemów biznesowych B2B - ERP, CRM, panele administracyjne, dashboardy, systemy zamówień - LiveView jest ekonomicznie lepszym wyborem. Mniejszy zespół, szybsze dostarczanie, prostsze utrzymanie, lepsze bezpieczeństwo.

React jest lepszym wyborem, gdy budujesz produkt konsumencki na miliony użytkowników z wymaganiami offline, ciężkim frontendem graficznym, albo masz istniejący zespół React, który nie chce się przebranżawiać.

Nie wiesz, które podejście jest lepsze dla Twojego projektu? Porozmawiajmy - przeanalizujemy Twoje wymagania i powiemy szczerze, czy LiveView ma sens w Twoim przypadku. Czasem odpowiedź brzmi "zostań przy React" - i to też jest wartościowa konsultacja.