Zastrzeżenie: Utrzymujemy CRXJS i stworzyliśmy ponad 27 pull requestów do projektu. To porównanie opiera się na naszym produkcyjnym doświadczeniu z wszystkimi trzema narzędziami. Staraliśmy się być uczciwi i dokładni, ale powinieneś wiedzieć, po której stronie stoimy.
Spis treści
1. Dlaczego w ogóle potrzebujesz frameworka
Budowanie rozszerzenia Chrome od zera jest zaskakująco bolesne. Musisz ręcznie zarządzać plikiem manifest.json, który odwołuje się do każdego skryptu, strony i zasobu. Potrzebujesz systemu budowania, który generuje właściwą strukturę plików, aby Chrome mógł je załadować. Nie masz hot module replacement — każda zmiana oznacza ręczne przeładowanie rozszerzenia i odświeżenie strony testowej. A jeśli chcesz użyć React, Vue czy Svelte w swoim popup lub content scripts, konfigurację bundlera musisz ogarnąć sam.
To nie jest tylko niewygodne — to jest wolne. Workflow bez narzędzi dodaje 30-60 sekund na każdą iterację: zapisz, zbuduj, przeładuj rozszerzenie, odśwież stronę, sprawdź wyniki. Przy ponad 50 iteracjach dziennie to prawie godzina stracona na tarcie z narzędziami.
Wszystkie trzy narzędzia — CRXJS, Plasmo i WXT — rozwiązują te problemy. Wszystkie zapewniają:
- -Hot module replacement (HMR), dzięki któremu widzisz zmiany natychmiast bez przeładowania
- -Pipeline budowania generujący prawidłową strukturę plików rozszerzenia
- -Wsparcie dla frameworków (React, Vue, Svelte) od razu po instalacji
- -Kompatybilność z Manifest V3
- -Serwer deweloperski z automatycznym przeładowaniem rozszerzenia
Różnią się filozofią: ile abstrakcji nakładają na Chrome APIs, jakiego bundlera używają i jak opiniotwórcze powinno być doświadczenie programisty. Ta różnica ma większe znaczenie, niż mogłoby się wydawać.
2. CRXJS: podejście oparte na pluginie Vite
CRXJS nie jest frameworkiem — to plugin do Vite. Stworzony przez Jacka i Amy, ma ponad 3,9 tys. gwiazdek na GitHubie i celowo przyjmuje minimalistyczne podejście: czyta Twój manifest.json, rozumie strukturę rozszerzenia Chrome i konfiguruje Vite, aby wszystko poprawnie zbudował. Piszesz standardowy kod rozszerzenia Chrome. CRXJS po prostu sprawia, że budowanie i development są szybkie.
Jak działa CRXJS
Tworzysz normalny projekt Vite z plikiem manifest.json w katalogu głównym. CRXJS czyta manifest i obsługuje:
- -Bundlowanie i wstrzykiwanie content scripts z pełnym wsparciem HMR
- -Kompilację background service worker
- -Budowanie stron popup i options
- -Kopiowanie zasobów publicznych i generowanie manifestu
- -Automatyczne przeładowanie rozszerzenia przy zmianach
Kluczowa filozofia: CRXJS nie abstrakcjonuje Chrome APIs. Nadal używasz chrome.runtime.sendMessage, chrome.storage i chrome.tabs bezpośrednio. Twój manifest to prawdziwy manifest. Twoje content scripts to prawdziwe content scripts. CRXJS jest narzędziem budowania, nie architekturą.
Mocne strony
- -Najbliżej natywnych API — brak abstrakcji między Tobą a Chrome APIs
- -Pełna kontrola nad architekturą i wzorcami
- -Doskonałe HMR, w tym w content scripts wstrzykiwanych na żywe strony
- -Wsparcie dla React, Vue i Svelte
- -Ekosystem Vite — wsparcie dla Vite od wersji 3 do 8, dostęp do wszystkich pluginów Vite
- -Natywne wsparcie Manifest V3
- -Aktywne utrzymanie — sami kontrybuujemy i używamy go codziennie w produkcji
Słabe strony
- -Wymaga solidnej znajomości Chrome API — CRXJS nie uczy, jak działają rozszerzenia
- -Mniej opiniotwórczy — więcej decyzji architektonicznych podejmujesz sam
- -Brak wbudowanej abstrakcji do messagingu ani wrappera na storage
- -Wsparcie cross-browser (Firefox, Safari) nie jest głównym priorytetem
CRXJS jest dla zespołów, które chcą szybkości i ekosystemu Vite bez rezygnacji z kontroli nad tym, jak działa ich rozszerzenie. Jeśli znasz Chrome APIs (lub chcesz się ich nauczyć), CRXJS nie wchodzi Ci w drogę i pozwala zbudować dokładnie to, czego potrzebujesz.
3. Plasmo: podejście pełnego frameworka
Plasmo przyjmuje odwrotne podejście do CRXJS. Z ok. 10 tys. gwiazdek na GitHubie jest najpopularniejszy z trójki i pozycjonuje się jako pełny framework do tworzenia rozszerzeń przeglądarek. Tam, gdzie CRXJS mówi “oto lepsze narzędzie do budowania”, Plasmo mówi “oto lepszy sposób na budowanie rozszerzeń”.
Jak działa Plasmo
Plasmo stosuje zasadę convention-over-configuration. Tworzysz pliki w określonych katalogach, a Plasmo automatycznie generuje manifest i output budowania:
- -
popup.tsxstaje się stroną popup — nie trzeba wpisu w manifeście - -
content.tsxstaje się content scriptem z frameworkiem CSUI (Content Script UI) - -Wbudowany
@plasmohq/messagingdo typowanego messagingu między kontekstami - -Wbudowany
@plasmohq/storagedo reaktywnego storage z hookami - -Manifest jest auto-generowany z Twojego kodu i konfiguracji
Framework CSUI to najbardziej wyróżniająca cecha Plasmo. Obsługuje montowanie komponentów React na stronach internetowych przez content scripts, zarządzanie izolacją Shadow DOM i zapewnia cykl życia komponentów świadomy strony-hosta. Dla prostych UI w content scripts jest to naprawdę wygodne.
Mocne strony
- -Najszybsza droga od zera do działającego rozszerzenia
- -Dobra dokumentacja z wieloma przykładami
- -Wbudowane abstrakcje messagingu i storage oszczędzają boilerplate
- -Framework CSUI dla komponentów React w content scripts
- -Największa społeczność (najwięcej gwiazdek na GitHubie, najwięcej odpowiedzi na Stack Overflow)
- -Świetny do prototypowania i MVP
Słabe strony
- -Abstrakcje mogą przeszkadzać w złożonych projektach — gdy CSUI nie obsługuje Twojego wzorca wstrzykiwania, obejście jest trudniejsze niż budowanie od zera
- -Uzależnienie od wzorców Plasmo — migracja oznacza przepisanie messagingu, storage i wstrzykiwania content scripts
- -Własny bundler oparty na Parcel, nie Vite — mniejszy ekosystem pluginów, mniejsza kompatybilność z narzędziami społeczności
- -Debugowanie jest trudniejsze, gdy abstrakcje przeciekają — komunikaty błędów odnoszą się do wewnętrznych mechanizmów Plasmo, nie do Twojego kodu
- -Auto-generowany manifest oznacza mniejszą widoczność tego, co Chrome faktycznie widzi
Plasmo jest doskonały do szybkiego startu i dla rozszerzeń, w których wbudowane wzorce odpowiadają Twoim wymaganiom. Problem pojawia się, gdy wyrośniesz z tych wzorców — a z naszego doświadczenia wynika, że złożone rozszerzenia produkcyjne często tak robią. Mimo to, dla wielu projektów abstrakcje Plasmo są dokładnie odpowiednie, a zyski produktywności są realne.
4. WXT: podejście inspirowane Nuxt
WXT jest najnowszy z trójki, z ok. 5 tys. gwiazdek na GitHubie i szybko rośnie. Inspirowany Nuxt, łączy konwencje oparte na plikach z Vite pod spodem. Pomyśl o nim jako o złotym środku: więcej struktury niż CRXJS, mniej abstrakcji niż Plasmo.
Jak działa WXT
WXT używa systemu routingu opartego na plikach dla entry pointów rozszerzenia. Wrzuć pliki do odpowiednich katalogów, a WXT połączy wszystko za Ciebie:
- -
entrypoints/popup.tsxstaje się Twoim popup - -
entrypoints/background.tsstaje się Twoim service workerem - -
entrypoints/content.tsstaje się content scriptem - -Auto-importy dla popularnych API (bez ręcznych instrukcji import)
- -Wbudowane wsparcie cross-browser — buduj dla Chrome, Firefox i Safari z jednego codebase
Wyróżniającą cechą WXT jest wsparcie cross-browser. Podczas gdy CRXJS i Plasmo koncentrują się głównie na Chrome (z różnym poziomem wsparcia dla Firefoksa), WXT traktuje buildy wieloprzeglądarkowe jako funkcję pierwszej klasy. Piszesz rozszerzenie raz, a WXT generuje buildy dla Chrome, Firefox i Safari z prawidłowym formatem manifestu dla każdego.
Mocne strony
- -Najlepsze wsparcie cross-browser z trójki (Chrome, Firefox, Safari)
- -Vite pod spodem — dostęp do pełnego ekosystemu pluginów Vite
- -Konwencje oparte na plikach są intuicyjne, jeśli używałeś Nuxt lub Next.js
- -Auto-importy redukują boilerplate
- -Dobre doświadczenie programisty z przejrzystą dokumentacją
- -Rosnąca społeczność z aktywnym utrzymaniem
Słabe strony
- -Nowszy ekosystem — mniej zasobów społeczności i poradników od osób trzecich
- -Niektóre zaawansowane wzorce (złożone wstrzykiwanie content scripts, komunikacja wielostronicowa) nie są jeszcze tak przetestowane w boju
- -Konwencje oparte na plikach mogą być ograniczające dla niestandardowych architektur rozszerzeń
- -Mniejsza społeczność oznacza mniej odpowiedzi, gdy natrafisz na edge case
WXT to solidny wybór, który szybko dojrzewa. Jeśli wsparcie cross-browser jest ważne dla Twojego projektu — a powinno być, jeśli celujesz w użytkowników enterprise, którzy mogą korzystać z Firefoksa lub Safari — WXT jest najprostszą drogą. Konwencje inspirowane Nuxt sprawiają też, że jest przystępny dla zespołów przechodzących z web developmentu.
5. Porównanie obok siebie
Oto jak te trzy narzędzia wypadają w wymiarach, które mają największe znaczenie w produkcyjnym developmencie rozszerzeń:
| CRXJS | Plasmo | WXT | |
|---|---|---|---|
| Typ | Plugin Vite | Pełny framework | Toolkit (w stylu Nuxt) |
| Gwiazdki GitHub | ~3,9 tys. | ~10 tys. | ~5 tys. |
| Bundler | Vite (3–8) | Parcel (własny) | Vite |
| Wsparcie frameworków | React, Vue, Svelte | React, Vue, Svelte | React, Vue, Svelte |
| Manifest | Piszesz sam | Auto-generowany | Auto-generowany |
| HMR | Doskonałe | Dobre | Dobre |
| Cross-browser | Skupiony na Chrome | Chrome + Firefox | Chrome + Firefox + Safari |
| API Messagingu | Natywne Chrome APIs | Wbudowana abstrakcja | Natywne Chrome APIs |
| API Storage | Natywne Chrome APIs | Wbudowana abstrakcja | Wbudowane narzędzie |
| Poziom abstrakcji | Niski (plugin) | Wysoki (framework) | Średni (toolkit) |
Żadne z tych narzędzi nie jest uniwersalnie “lepsze”. Są zoptymalizowane pod kątem różnych sytuacji i różnych zespołów. Właściwy wybór zależy od wymagań Twojego projektu, doświadczenia Twojego zespołu z Chrome APIs i tego, ile kontroli potrzebujesz nad architekturą rozszerzenia.
6. Kiedy użyć którego
Po wydaniu produkcyjnych rozszerzeń ze wszystkimi trzema narzędziami, oto nasza szczera rekomendacja, kiedy każde z nich ma największy sens:
Użyj CRXJS, gdy:
- -Potrzebujesz maksymalnej kontroli nad architekturą rozszerzenia
- -Budujesz złożone wstrzykiwanie content scripts (SPA, dynamiczne strony, multi-mount)
- -Twój zespół ma doświadczenie z Chrome API lub jest gotowy zainwestować w naukę
- -Chcesz używać Vite i jego ekosystemu pluginów bezpośrednio
- -Budujesz długowieczne rozszerzenie produkcyjne, które będzie ewoluować przez lata
- -Chcesz uniknąć uzależnienia od frameworka — migracja z CRXJS oznacza zamianę pluginu Vite, nie przepisywanie aplikacji
Użyj Plasmo, gdy:
- -Musisz szybko stworzyć prototyp lub wydać MVP
- -Twoje rozszerzenie ma prostą architekturę (popup + prosty content script)
- -Chcesz wbudowanych abstrakcji messagingu i storage, aby zredukować boilerplate
- -Twój zespół jest nowy w developmencie rozszerzeń Chrome i potrzebuje prowadzenia
- -Cenisz dużą społeczność i mnóstwo istniejących tutoriali
Użyj WXT, gdy:
- -Wsparcie cross-browser (Chrome + Firefox + Safari) jest twardym wymaganiem
- -Lubisz konwencje oparte na plikach w stylu Nuxt
- -Chcesz Vite pod spodem, ale z większą strukturą niż oferuje CRXJS
- -Twój zespół pochodzi ze środowiska Nuxt lub Next.js
- -Chcesz auto-importów i bardziej opiniotwórczej struktury projektu bez pełnego uzależnienia od frameworka
7. Nasza opinia
Używamy CRXJS w naszej pracy produkcyjnej. Powód jest specyficzny dla tego, co budujemy: złożone rozszerzenia, które wstrzykują interfejsy React w aplikacje SPA firm trzecich, obsługują dynamiczne montowanie content scripts przy zmianach tras po stronie klienta i wymagają precyzyjnej kontroli nad tym, jak i kiedy skrypty się wykonują. Do tego rodzaju pracy musimy być blisko Chrome APIs i potrzebujemy narzędzia budowania, które nie wchodzi nam w drogę.
Jesteśmy też kontrybutorami CRXJS, co daje nam praktyczną przewagę: gdy natrafiamy na buga lub potrzebujemy funkcji, możemy to naprawić upstream. Stworzyliśmy ponad 27 pull requestów w tym cross-platformowe CI/CD, wsparcie Vite 8, poprawki HMR dla CSS w content scripts i wsparcie developmentu na Windows. Oznacza to, że nasi klienci otrzymują poprawki szybciej niż czekając na wydanie zewnętrzne.
Mimo to nie jesteśmy w tym dogmatyczni. Dla klienta, który potrzebuje prostego rozszerzenia popup wydanego w tydzień, wbudowane abstrakcje Plasmo zaoszczędziłyby czas. Dla klienta, który potrzebuje tego samego rozszerzenia na Chrome, Firefox i Safari, buildy cross-browser WXT byłyby oczywistym wyborem.
Najlepsze narzędzie to takie, które pasuje do Twoich ograniczeń. Oto szybki schemat decyzyjny:
- 1.Zacznij od złożoności. Proste rozszerzenie? Plasmo doprowadzi Cię tam najszybciej. Złożone wstrzykiwanie content scripts? CRXJS daje kontrolę.
- 2.Sprawdź wymagania przeglądarkowe. Tylko Chrome? Każde narzędzie zadziała. Chrome + Firefox + Safari? WXT jest do tego stworzony.
- 3.Weź pod uwagę zespół. Nowi w rozszerzeniach? Prowadzenie Plasmo pomoże. Doświadczeni z Chrome APIs? CRXJS będzie naturalny. Przychodzisz z Nuxt? WXT będzie znajomy.
- 4.Pomyśl o uzależnieniu. CRXJS to plugin Vite — łatwo go usunąć. Abstrakcje Plasmo są głębsze — trudniej migrować. WXT jest pośrodku.
Wszystkie trzy narzędzia są aktywnie utrzymywane, gotowe do produkcji i stanowią ogromną poprawę w porównaniu z budowaniem rozszerzeń bez żadnych narzędzi. Nie popełnisz poważnego błędu wybierając którekolwiek z nich. Różnice leżą w szczegółach — a te szczegóły mają największe znaczenie, gdy Twoje rozszerzenie rośnie w złożoności.
Potrzebujesz pomocy w wyborze lub budowie?
Wydaliśmy produkcyjne rozszerzenia z CRXJS, Plasmo i WXT. Niezależnie od tego, czy potrzebujesz pomocy w wyborze odpowiedniego narzędzia, czy chcesz, żebyśmy zbudowali rozszerzenie za Ciebie — możemy pomóc.
