Czym był ReactXP? Wieloplatformowa biblioteka React od Microsoftu, nasze doświadczenia i z czego korzystać dziś

ReactXP był biblioteką open source stworzoną przez zespół Skype'a w Microsoft, która pozwalała programistom utrzymywać jedną bazę kodu React i React Native dla iOS, Androida i webu.

Microsoft ogłosił koniec życia projektu w 2022 roku, a w czerwcu 2026 zarchiwizował jego repozytorium na GitHubie. Użyliśmy ReactXP w projekcie dla klienta krótko po premierze i wersję webową aplikacji mobilnej dostaliśmy niemal gratis.

W tym artykule wyjaśniamy, czym był ReactXP, jak z niego korzystaliśmy i co polecilibyśmy dziś zespołowi, który mierzy się z podobnym wyzwaniem.

Czym był ReactXP i dlaczego Microsoft go stworzył?

ReactXP był biblioteką JavaScript, która pozwalała jednej bazie kodu React renderować natywny interfejs na iOS i Androidzie oraz HTML w webie. Jak czytamy w FAQ ReactXP, „powstał w zespole Skype'a w Microsoft, aby odpowiadać na jego potrzeby związane z tworzeniem oprogramowania”. Kod pojawił się na GitHubie w marcu 2017 roku, a Microsoft ogłosił projekt publicznie w kwietniu 2017 roku.

React i React Native już wtedy pozwalały zespołom współdzielić logikę biznesową między webem a mobilem, ale warstwę widoków nadal trzeba było pisać podwójnie: <div> i CSS dla przeglądarki, <View> i natywne style dla telefonów. ReactXP dodał to, co w swoim README nazywa „cienką warstwą wieloplatformową”. Jeśli pisałeś aplikację w oparciu o tę abstrakcję, mogłeś współdzielić definicje widoków, style i animacje między platformami, a tam, gdzie było to potrzebne, nadal dodawać warianty specyficzne dla danej platformy.

ReactXP celowo udostępniał tylko te propsy, atrybuty stylów i API, które działały na wszystkich wspieranych platformach, dzięki czemu kod kompilujący się dla jednego celu zachowywał się spójnie także na pozostałych. Obsługiwał iOS i Androida, przez React Native, web, przez React, oraz Windows UWP, który w FAQ był oznaczony jako wciąż rozwijany. ReactXP napisano w TypeScript i dostarczano z definicjami typów dla całego interfejsu.

Czy ReactXP jest nadal utrzymywany w 2026 roku?

Nie. ReactXP zakończył swój cykl życia. W kwietniu 2022 roku Microsoft dodał do README informację, że „biblioteka ReactXP nie jest już utrzymywana”, że nie będą publikowane nowe wersje, i zarekomendował zamiast niej React Native for Web. 11 czerwca 2026 roku Microsoft zarchiwizował repozytorium, które jest teraz dostępne tylko do odczytu.

Pakiet nadal możesz zainstalować z npm i przejrzeć jego kod źródłowy, ale nie warto zaczynać na nim nowego projektu. ReactXP 2.0.0 celuje w wersje React Native z 2019 roku. Każda aktualizacja SDK iOS i Androida od tamtego czasu tylko powiększa rozjazd między tym, czego oczekuje biblioteka, a tym, czego wymagają sklepy z aplikacjami.

Jak wyglądało tworzenie aplikacji wieloplatformowych, gdy ReactXP debiutował?

W 2017 roku zespół, który chciał mieć jedną bazę kodu dla iOS, Androida i webu, miał kilka opcji, a każda z nich wiązała się z kompromisem. Większość z tych opcji nadal istnieje, choć nie wszystkie przetrwały całą dekadę.

Platformy oparte na językach kompilowanych, takie jak Xamarin i RubyMotion, były atrakcyjne dla programistów C# i Ruby tworzących aplikacje na iOS i Androida, ale nadal wymagały osobnej aplikacji webowej, a część z nich wymagała płatnej subskrypcji. Microsoft zakończył wsparcie dla Xamarin 1 maja 2024 roku; jego następcą jest .NET MAUI.

Aplikacje hybrydowe budowane w Cordovie/PhoneGap lub Ionic współdzieliły logikę biznesową, układ HTML i CSS między webem a mobilem, opakowując aplikację webową w mobilne środowisko przeglądarkowe z natywnymi wtyczkami. Wiązało się to z pewnym narzutem na wydajność, który coraz szybsze urządzenia stopniowo zmniejszały. Adobe zamknęło PhoneGap Build w październiku 2020 roku; Apache Cordova i Ionic działają dalej.

Progressive Web Apps (PWA) były lżejszą alternatywą: zwykłymi aplikacjami webowymi, które zamiast zewnętrznych wrapperów korzystają z nowoczesnych API przeglądarki, aby uzyskać dostęp do natywnych funkcji. To nadal dobry wybór, jeśli obecność w sklepach z aplikacjami nie jest wymagana.

Flutter od Google obrał inną drogę: aplikacje pisze się w Darcie, a Flutter rysuje własne widgety zamiast korzystać z natywnych komponentów interfejsu danej platformy. Od tamtej pory urósł do jednego z dwóch wiodących frameworków wieloplatformowych.

React Native uruchamiał logikę biznesową w silniku JavaScript i renderował prawdziwe natywne elementy interfejsu iOS oraz Androida, co dawało mu przewagę wydajnościową nad podejściami opartymi na przeglądarce. Logikę biznesową można było współdzielić z webem, ale układ i style nadal trzeba było odtworzyć w HTML i CSS.

W tamtym czasie dwa projekty open source próbowały zamknąć tę lukę: React Native for Web Nicolasa Gallaghera i ReactXP od Microsoftu. Oba udostępniały webowe odpowiedniki komponentów React Native, takich jak View i TextInput, a także abstrakcje dla wspólnych funkcji, takich jak magazyn klucz-wartość i status sieci.

Dlaczego w Monterail wybraliśmy ReactXP zamiast React Native for Web?

Po ReactXP sięgnęliśmy po raz pierwszy w nowym projekcie dla klienta, którego głównym wymaganiem była aplikacja na iOS, Androida i web, z niemal identycznymi funkcjami i bardzo niewielkimi różnicami w projekcie. Nasz trzyosobowy zespół miał duże doświadczenie w JavaScript, ale nigdy wcześniej nie dostarczył natywnej aplikacji w Objective-C, Swifcie ani Javie, więc podejście wieloplatformowe wydawało się naturalnym wyborem.

Na początku zakładaliśmy, że aplikacje mobilne i webową zbudujemy osobno. Projekty prawie się nie różniły, ale zachowanie już tak, i spodziewaliśmy się, że wiele komponentów i tak będzie wymagało oddzielnych implementacji, co utrudni utrzymanie współdzielonej bazy kodu. Potem przyjrzeliśmy się bliżej React Native for Web i ReactXP. React Native for Web był popularniejszy, miał więcej gwiazdek na GitHubie i więcej materiałów do nauki, ale ostatecznie wybraliśmy ReactXP z dwóch powodów.

Po pierwsze, stał za nim Microsoft i była to jedna z bibliotek wykorzystanych przy nowym wieloplatformowym Skype'ie. Nowy Skype był już wdrożony, co przekonało nas, że biblioteka jest gotowa do użycia produkcyjnego i szybko nie zniknie. Po drugie, napisano ją w TypeScript, czyli w języku, który wybraliśmy do tego projektu. Dzięki Visual Studio Code i mechanizmowi autouzupełniania IntelliSense dostawaliśmy podpowiedzi typów i natychmiastową kontrolę błędów nie tylko w logice, ale też w znacznikach i stylach: każdy prop komponentu i każdy atrybut stylu miał swój typ, więc błędy wychodziły na jaw już podczas pisania.

Z perspektywy czasu pierwszy argument źle się zestarzał, bo wsparcie dużej firmy nie gwarantuje długowieczności. Microsoft przestał utrzymywać ReactXP pięć lat po jego wydaniu, a trzy lata później wycofał też samego Skype'a. Tymczasem rozwijany przez społeczność React Native for Web działał dalej. Zniknęła też luka w TypeScript, która była wtedy dla nas istotna: definicje typów są dziś dostępne przez @types/react-native-web. Gdybyśmy wybierali dziś, większe znaczenie niż nazwa właściciela repozytorium miałyby dla nas skala adopcji i aktywność maintainerów.

Jak jedna baza kodu ReactXP obsługiwała iOS, Androida i web?

Aplikację zorganizowaliśmy tak, by platformy rozdzielały się na górze i na dole stosu, a wszystko pomiędzy było współdzielone. Repozytorium ReactXP na GitHubie zawierało przykładowe aplikacje, od prostego Hello World po aplikację testową sprawdzającą każdy komponent i każde API, i to na nich oparliśmy naszą konfigurację.

Każda platforma dostała osobny punkt wejścia, app.native.tsx i app.web.tsx, oraz własną konfigurację nawigacji: React Navigation dla środowiska natywnego i React Router dla webu, bo wzorce nawigacji w aplikacjach mobilnych i przeglądarkowych bardzo się od siebie różnią.

Poniżej warstwy nawigacji widoki były już współdzielone. Gdy trafialiśmy do konkretnego widoku, screen w środowisku natywnym, a route w webie, importowaliśmy wspólny kontener i właśnie tam zaczynała się korzyść z jednej bazy kodu. Korzystając z wieloplatformowych komponentów ReactXP, definiowaliśmy każdy widok tylko raz, a on wyglądał i działał zgodnie z oczekiwaniami zarówno na mobile'u, jak i w webie. Przy prostych wyjątkach specyficznych dla platformy RX.Platform.getType() mówił nam, na której platformie jesteśmy.

Gdy komponent rzeczywiście potrzebował osobnych wersji dla webu i środowiska natywnego, importowaliśmy go przez aliasy ścieżek. Osobne pliki tsconfig.json i osobne konfiguracje webpacka rozwiązywały ten sam alias do różnych katalogów: @components wskazywał na src/components/web w webie i na src/components/native w mobile'u. Żeby webpack działał także przy buildach natywnych, zastąpiliśmy domyślny bundler React Native, packager, narzędziem Haul od Callstack.

Po ponad sześciu miesiącach pracy nad projektem ReactXP zrobił na nas duże wrażenie i nie napotkaliśmy żadnych blokujących problemów. Aplikacja webowa wymagała od nas bardzo niewiele dodatkowej pracy. Nasze case study Guild, aplikacji społecznościowej dla profesjonalistów zbudowanej w React Native i ReactXP, pokazuje to w liczbach: aplikacje mobilne współdzieliły około 99% kodu, a wersja webowa wykorzystywała ponownie około 80% kodu JavaScript.

Od tamtej pory większość tych narzędzi poszła dalej. TSLint, którego używaliśmy do lintingu, został wycofany na rzecz ESLint. Maintainerzy Haul dziś zalecają migrację do Re.Pack. Sama architektura, czyli współdzielone widoki z elementami specyficznymi dla platform, nadal pozostaje właściwym podejściem.

Czego używać dziś zamiast ReactXP?

React Native for Web, najlepiej przez Expo. To rekomendacja samego Microsoftu zawarta w informacji o zakończeniu życia ReactXP i właśnie z tego dziś najczęściej korzystają zespoły React Native budujące także na web.

React Native for Web opisuje się jako „warstwę zgodności między React DOM a React Native”. Piszesz standardowe komponenty React Native, View, Text, TextInput, ScrollView, a w webie renderują się one jako elementy DOM ze stylami kompilowanymi do CSS. Jego tabela zgodności obejmuje „zdecydowaną większość API JavaScript React Native”. Wśród firm, które go wdrożyły, są Twitter i Flipkart, a my użyliśmy go przy migracji platformy doceniania pracowników Cooleaf z niewspieranego AngularJS, współdzieląc kod między aplikacją webową a mobilnymi aplikacjami React Native.

Własny przewodnik po platformach tej biblioteki mówi wprost, że korzystanie z Expo jest „zdecydowanie zalecane”, bo przejmuje ono konfigurację webu. Dokumentacja React Native również zaleca rozpoczynanie nowych aplikacji od frameworka, konkretnie Expo. Expo for web korzysta pod spodem z React Native for Web, a Expo Router daje routing oparty na plikach między platformami, z opcjonalnym renderowaniem statycznym pod SEO.

Obie biblioteki radzą sobie z różnicami między platformami w przeciwny sposób. ReactXP ograniczał cię do najmniejszego wspólnego mianownika, więc wszystko, co udostępniał, działało wszędzie. React Native for Web daje ci prawie pełne API React Native, ale w webie kilka elementów jest zasymulowanych albo niedostępnych, na przykład Alert, RefreshControl i KeyboardAvoidingView. Musisz wiedzieć, gdzie są te luki.

Jak przenieść aplikację z ReactXP do React Native for Web?

Przepisujesz warstwę widoków i zostawiasz resztę. Logika biznesowa, zarządzanie stanem i klienci API przechodzą bez zmian, bo ReactXP nigdy ich nie dotykał. Prace skupiają się w trzech obszarach.

1. Zamień komponenty ReactXP na komponenty React Native. RX.View, RX.Text, RX.Image i RX.TextInput mają bliskie odpowiedniki w React Native, ale propsy i nazwy stylów nie zawsze odpowiadają sobie jeden do jednego, więc zaplanuj czas na ręczne sprawdzenie każdego ekranu.

2. Przerób wykrywanie platformy. Sprawdzenia RX.Platform.getType() zamieniają się w Platform.OS. Własne aliasy ścieżek i równoległe konfiguracje webpacka mogą ustąpić miejsca rozszerzeniom plików zależnym od platformy, Button.web.tsx i Button.native.tsx, które bundler rozpoznaje automatycznie.

3. Przenieś narzędzia do budowania aplikacji. Projekt w Expo zwykle jest najczystszym kierunkiem, bo w jednym pakiecie dostajesz bundlowanie przez Metro, obsługę webu i routing. Zespoły, które potrzebują natywnych buildów z konfiguracją w stylu webpacka, mogą sięgnąć po Re.Pack, a konfiguracje TSLint warto przenieść do ESLint.

Zakładaj, że większość wysiłku pójdzie w wszystko to, co zamarło razem z ReactXP. Aplikacja ostatnio aktualizowana około 2019 roku może wymagać także dużej aktualizacji React Native, wymiany porzuconych bibliotek zewnętrznych i nowej nawigacji. Zanim przygotujesz wycenę, zrób audyt zależności. W niektórych przypadkach uporządkowana przebudowa na aktualnym stosie technologicznym jest tańsza niż stopniowa aktualizacja.

Ile naprawdę kosztuje współdzielona baza kodu?

Jedna baza kodu ogranicza duplikację pracy i wypycha różnice między platformami na brzegi aplikacji, gdzie i tak trzeba je obsadzić odpowiednimi kompetencjami i przetestować.

Nawigacja i UX nadal się rozchodzą. Nasze pierwotne założenie, że nawigacja pozostanie specyficzna dla platformy, sprawdzało się przez lata. Expo Router od tamtej pory zmniejszył tę różnicę, ale użytkownicy webu nadal oczekują adresów URL, deep linków, historii przeglądarki i stanów hover, których użytkownicy mobile'a nie potrzebują.

Web ma też własną poprzeczkę jakości. Jeśli aplikacja webowa jest tylko dodatkiem do aplikacji mobilnej, widać to po dostępności, SEO i wydajności ładowania. Renderowanie statyczne i dzielenie kodu są dostępne w Expo i React Native for Web, ale ktoś musi za to odpowiadać.

Na koniec, zależności niosą ze sobą ryzyko biznesowe. ReactXP był dobrze zaprojektowaną biblioteką od dużego dostawcy, a mimo to zakończył swój cykl życia, gdy aplikacje nadal od niego zależały. Stawiaj na narzędzia szeroko stosowane i aktywnie utrzymywane, trzymaj kod specyficzny dla platform za wyraźnymi granicami i uwzględniaj w budżecie regularne aktualizacje frameworków, zamiast odkładać je tak długo, aż się nawarstwią.

Czy jedna baza kodu React Native nadal ma sens dla webu i mobile'a?

Tak, dla większości produktów, w których aplikacje mobilne i webowa mają wspólne funkcje i trafiają do tej samej grupy odbiorców. ReactXP pokazał nam, że jedna baza kodu TypeScript może posłużyć do tworzenia aplikacji na iOS, Androida i web w trzyosobowym zespole, i ta lekcja przetrwała dłużej niż sama biblioteka. Dziś nie potrzebujesz już niszowej abstrakcji, by to osiągnąć, bo React Native for Web i Expo są oficjalnie zalecaną ścieżką. O sukcesie decydują mniej efektowne rzeczy: jasne wyznaczenie granic tam, gdzie platformy się różnią, wybór zależności, które będą utrzymywane także za pięć lat, i regularne nadążanie za aktualizacjami.

Jeśli planujesz produkt wieloplatformowy albo masz aplikację z epoki ReactXP i szukasz dla niej dalszej drogi, zespoły Monterail od React Native i tworzenia aplikacji webowych pomogą ci ocenić, co warto zachować, co zmigrować i co bardziej opłaca się zbudować od nowa.