Obiektywne spojrzenie na wojnę bibliotek: React vs Vue

Skąd pochodzimy? Kim jesteśmy? Dokąd zmierzamy?

Zatrzymajmy się na chwilę i zastanówmy się, gdzie jesteśmy. Jako totalny boomer, szczerze wątpię, by 10 lat temu ktokolwiek mógł przewidzieć, że tworzenie stron internetowych posunąłby się tak daleko.

Użyteczne aplikacje desktopowe należą już do przeszłości, ponieważ wszystko można zrobić w przeglądarce. W rzeczywistości aplikacje, które muszą korzystać z interfejsów API niższego poziomu, które nie są dostępne w przeglądarce, są również pisane przy użyciu silników i języków przeglądarek, ponieważ ułatwia to ich utrzymanie.

Aplikacje mobilne można łatwo zastąpić narzędziami używanymi do tworzenia stron internetowych - zob. React Native, NativeScript. Do tego mamy PWA, które z łatwością "imituje" działanie aplikacji mobilnych. Dodatkowo komponenty, które zasilają aplikację napisaną w Vue lub React mogą łatwo udostępniać różne kod elementów między platformami.

Trzeba przyznać jedno - aplikacje webowe to obecnie potęga, którą ciężko będzie sprowadzić do parteru. Jako użytkownik widzę, że korzystam z nich praktycznie wszędzie: komunikując się przez Slacka, używając edytora kodu, robiąc prezentacje czy nawet pisząc artykuł na bloga.

Trudno przewidzieć, co stanie się za kilka lat. WebAssembly wkracza do gry i pozwoli nam przenieść aplikacje wymagające bardziej skomplikowanych obliczeń do świata przeglądarek. Jeden fakt pozostaje jednak niezmienny - naprawdę trudno znaleźć przeszkodę, by zbudować z wykorzystaniem technologii webowych taką aplikację, o jakiej do tej pory mogliśmy tylko pomarzyć.

Wielki wybuch w internetowej rzeczywistości

Do rzeczy - wróćmy na chwilę do przeszłości, zanim pojawiły się pierwsze bardziej znaczące frameworki webowe, a aplikacje były tworzone w sposób imperatywny. Każda interaktywna mechanika na stronie była obsługiwana ręcznie i odpowiadała za konkretną akcję.

Najlepszym przykładem jest biblioteka jQuery - swego czasu jedno z najpopularniejszych rozwiązań do obsługi prostych zdarzeń. Z jej pomocą implementowano różnego rodzaju rozwijane menu, przejścia, animacje, kalkulatory i tym podobne mechaniki.

Warto wspomnieć, że już wtedy zauważono problemy w bardziej złożonych aplikacjach - w miejscach, gdzie różne, niezależne części musiały np. reagować na odpowiednie kliknięcie lub wpisanie czegoś. Większość aplikacji nie posiadała jawnego stanu, a zamiast tego ratowały je np. atrybuty elementów lub posiadane przez nie klasy.

W tamtym czasie było jasne, że obecnemu podejściu brakowało reaktywności - ustrukturyzowanego sposobu, w jaki komponenty komunikowałyby się ze sobą i dzieliły np. swoim stanem lub różnymi zdarzeniami, co ułatwiało utrzymanie aplikacji i pozwalało im zapewnić dobre wrażenia użytkownika przy niskich kosztach.

Pierwsze kroki w kierunku znanych ram

Z czasem na horyzoncie zaczęły pojawiać się pierwsze frameworki front-endowe, mające na celu ustrukturyzowanie architektury dla bardziej złożonych aplikacji.

Ramy te opierały się głównie na wzorcu MVC - niektóre sugerowały bardziej ręczne podejście, takie jak Backbone.js, podczas gdy inne, takie jak Knockout.js, opierały się na dwukierunkowym wiązaniu danych.

Mimo to można odnieść wrażenie, że napisanie aplikacji było trudniejsze, wymagało znacznie więcej kodowania i niekoniecznie przyniosło zamierzone rezultaty lub zrekompensowało czas stracony na tworzenie aplikacji.

Głównym powodem, dla którego znalezienie złotego środka w ekosystemie JS było trudne, było to, że był on nieco dziwny wśród dobrze znanych języki programowania które od dawna mają przetarte szlaki.

I nie chcę się tutaj rozwodzić nad tym, jakie dokładnie ścieżki towarzyszyły rozwojowi poszczególnych frameworków na przestrzeni dziejów. Trzeba jednak zauważyć jedno - czas dojrzewania ekosystemu JS w przeglądarkach nie był łatwy i napotykał wiele prób.

Jest to jedyny powód, dla którego dziś możemy tworzyć aplikacje internetowe i rozwijać je w bardzo łatwy i bezbolesny sposób.

Podstawowe informacje i niewielkie porównanie

Zamiast rzucać mięsem, jak to zwykle bywa w Internecie, przyjrzyjmy się obu bibliotekom, zbierzmy informacje na ich temat i porównajmy je - zarówno w teorii, jak i w praktyce.

UWAGA: Opis mechanizmów działających w Vue odnosi się konkretnie do wersji 2. Wersja 3 wprowadza wiele znaczących zmian, ale nie jest prawdziwym konkurentem dla React w tej chwili, choćby ze względu na jego dojrzałość - data premiery Vue 3: 18 września 2020 r.

Wyjaśnijmy sobie jedną rzecz - zagłębiając się w obie biblioteki, można zauważyć, że w rzeczywistości istnieje więcej podobieństw niż różnic. Pomijając sposób korzystania z bibliotek jako takich - obie mają bardzo podobne koncepcje działania. Obie są zasilane przez podobny ekosystem, a ich zastosowanie nie jest diametralnie różne.

Diabeł tkwi w szczegółach - im częściej korzystamy z danego narzędzia, tym większe wady poszczególnych rozwiązań dostrzegamy. Dobrym przykładem może być tutaj dwukierunkowe wiązanie danych, które jest najczęściej wykorzystywane w Vue jako właściwość v-modelu: często ułatwia pracę, zajmuje się wieloma rzeczami automatycznie i nie wymaga kodowania dodatkowej obsługi zmiany wartości.

Istnieją jednak przypadki, w których musimy konkretnie śledzić próbę zmiany i odpowiednio zareagować, w którym to przypadku komponenty oparte na v-modelu często zmuszają nas do mieszania się z innymi komponentami. Vue mechaniki, takie jak obliczona właściwość, co sprawia, że uzyskany efekt często wygląda znacznie gorzej niż w przypadku podejścia ręcznego;

Innym interesującym aspektem jest JSX, który jest takim "włóczęgowskim" sposobem na szablonowanie renderowanej treści przy użyciu React. Społeczność deweloperów ma różne opinie na ten temat.

Z moich obserwacji wynika, że deweloperzy korzystający ze środowiska innego niż JS, np. PHP lub C#, są bardziej skłonni do szablonowania widoków w sposób, który Vue nie.

Podsumowując - szablony znane z Vue pozwalają definiować widoki w bardzo przejrzysty i elegancki sposób, podczas gdy JSX w React pozwala budować je w wielu przypadkach szybciej, dostosowywać do konkretnych potrzeb i często wymaga mniej kodu do budowania różnorodnych struktur;

Przyjrzyjmy się również ekosystemom tych dwóch narzędzi. W zasadzie można powiedzieć, że nie różnią się one niczym. Oba nie bez powodu nazywane są bibliotekami - zapewniają absolutne minimum dla reaktywnej obsługi aplikacji webowych.

Natomiast reszta, związana z komunikacją z API, przepływem danych, komponentami UI wykorzystywanymi wokół poszczególnych podstron, to tzw. vendory - biblioteki pobierane z zewnątrz, które należy odpowiednio podpiąć do aplikacji. projekt. To trochę jak w świecie klocków Lego: jeśli chcesz zbudować spójną całość - musisz złożyć ją z pojedynczych, małych klocków.

Alegoria ta odnosi się właśnie do dołączanych komponentów, które stanowią o sile aplikacji tworzonych za pomocą React lub Vue;

Ważną rzeczą, szczególnie dla osób, które nie są tak doświadczone w środowisku JS, jest poziom wejścia w daną bibliotekę. Innymi słowy - złożoność narzędzia, na którą składa się bezpośredni czas, jaki trzeba poświęcić na zrozumienie jego mechaniki.

Myślę, że trzeba tu jednoznacznie stwierdzić jedną rzecz - w przypadku Vuejest znacznie prostsze. Mamy dwukierunkowe wiązanie danych, mamy elegancko sprecyzowany szablon, który jest łudząco podobny do rozwiązań w innych językach, np. twigu, no i wreszcie - nie mamy bólu głowy spowodowanego poznawaniem teorii dotyczących działania poszczególnych hooków i przypadków, w których należy użyć konkretnej mechaniki.

Co mówią statystyki?

Podążanie bezpośrednio za głosem tłumu nie jest do końca dobrym wyborem. Jednak dobrym krokiem w kierunku podjęcia dobrej decyzji jest przeanalizowanie tego, co mówią ludzie, którzy mieli styczność z tymi bibliotekami.

I tak - gwiazdy na github może być wskaźnikiem tego, jak bardzo społeczność danej biblioteki jest zaangażowana w jej rozwój, jak jest ona postrzegana przez deweloperów i czy są oni zainteresowani tym, dokąd ona zmierza. Inżynierowie, którzy są gwiazdami danego repozytorium, często otrzymują powiadomienia o nowych wydaniach lub zmianach w kodzie, co przekłada się na ich bezpośrednią wiedzę o bibliotece.

Jednak liczba gwiazdek na githubie nie powinna być postrzegana jako wyrocznia - nie każdy programista, który lubi narzędzie, pozostawi po sobie ślad - zamiast tego potraktowałbym to jako oznakę czystej pasji, jaką programiści mają dla konkretnego projektu open source.

Google Trends to dobrze znana usługa, która pozwala nam badać zainteresowanie określonymi tematami w czasie. Chociaż nie jest to racjonalny wskaźnik jakości lub użytkowania, może dostarczyć wszelkiego rodzaju analiz.

Łatwo zauważyć, że przebieg ostatnich 5 lat został nakreślony dość podobnie, jeśli chodzi o porównanie dwóch bohaterów dzisiejszego artykułu. Podstawowy wniosek, jaki można wyciągnąć z wykresu jest następujący React jest wyższa, jeśli chodzi o popularność wyszukiwania w stosunku do swojego przeciwnika.

Żeby było jasne - bycie na szczycie w Google Trends nie oznacza, że dana biblioteka jest lepsza. Chodzi o popularność w tłumie, jak wspomniałem wcześniej - prawdopodobnie więcej osób słyszało o tym narzędziu, mogło ono wzbudzić większe zainteresowanie wśród użytkowników. CTOs, programiści lub osoby, które chcą po prostu nauczyć się konkretnego narzędzia.

Czy ten wykres ma odzwierciedlenie w rzeczywistości? Poniekąd tak. Ogólnie rzecz biorąc - wśród ankietowanych osób więcej wykazuje się zróżnicowaną wiedzą na temat React niż Vue. Jakie opinie można uzyskać rozmawiając z tymi ludźmi? Postaram się to przedstawić w następnym akapicie.

Stan JS  to strona, która co roku przeprowadza ankietę wśród osób pracujących w technologiach związanych z JavaScript. Jej celem jest zebranie informacji od deweloperów na temat tego, jak postrzegają narzędzia, z którymi pracują na co dzień.

Pytania obejmują poszczególne narzędzia do różnych celów - np. narzędzia używane na front-endzie i na back-endzie, ale także narzędzia do testowania, zarządzania stanem aplikacji itp. Każde z tych pytań nie jest prostą odpowiedzią tak/nie, strona zadaje serię pytań dotyczących samego narzędzia, zainteresowań, doświadczeń i ogólnej oceny, która sprowadza się do zdania "Czy użyłbyś tego narzędzia w przyszłych projektach?".

Sama strona pozwala przeprowadzić wiele analiz, porównać odpowiednie narzędzia, a czasem dowiedzieć się o mniej znanych bibliotekach, które zaczynają dobrze radzić sobie w świecie JS, zdobywając popularność i ciesząc się wysokim wskaźnikiem "happiness to use". Szczerze zachęcam do przeglądania treści na tej stronie.

Podsumujmy sekcję ze statystykami. Analizowanie różnego rodzaju wykresów może być często bardzo dobrą opcją do porównywania różnych aspektów danych tematów. Ważne jest jednak, aby wziąć pod uwagę, że podążanie za głosem tłumu niekoniecznie będzie najmądrzejszą rzeczą do zrobienia. Zamiast tego można podjąć świadomą decyzję, korzystając z niektórych wniosków wyciągniętych z analiz wykresów.

Najlepszy wybór dla dewelopera

Wcześniej wspomniałem o niższym progu wejścia do Vue - Rzeczywiście, pozwala to nieco szybciej skupić się na faktycznym rozwoju aplikacji, korzystając z narzędzia i skracając do minimum czas potrzebny na zapoznanie się ze środowiskiem, mechaniką i różnymi przypadkami użycia.

Ogólnie uważam, że Vue jest bardziej odpowiednia dla osób, które nie miały jeszcze do czynienia z bibliotekami front-endowymi. Z pewnością pozwoli w bardziej zachęcający sposób uzyskać zadowalające efekty w krótkim czasie.

Powiedzmy to sobie jednak głośno - brak znajomości języka, w którym korzystamy z konkretnych narzędzi, prędzej czy później nam zaszkodzi. Jest to element pomijalny przy prostych rzeczach, ale wraz ze wzrostem złożoności tworzonych aplikacji, coraz trudniej będzie budować aplikacje w przyzwoity sposób bez dobrej znajomości języka. JavaScript.

Nie odnoszę się tutaj do umiejętności pisania skomplikowanych funkcji, ponieważ ta część może być w dużej mierze zastąpiona np. przez dostawców. Odnoszę się do pewnych typowych błędów, które można popełnić w języku i nie zdawać sobie sprawy, że nieprawidłowe zachowanie nie wynika z użycia biblioteki, ale z użycia języka. Najczęstszym błędem, który się tu objawia jest tzw. immutability - czyli znajomość mechanizmu referencyjnego w JavaScript.

Nie jestem w stanie zasugerować, która biblioteka jest lepsza dla programistów mniej lub bardziej zaznajomionych z JavaScript. Wiem natomiast jedno - jeśli chcesz mieć realny pogląd na to, jak wygląda "od kuchni" programowanie z wykorzystaniem obu narzędzi - spróbuj napisać aplikacje w każdym z nich. Da Ci to pogląd, pozwoli zobaczyć, które mechanizmy bardziej do Ciebie przemawiają i co jest dla Ciebie lepszym wyborem.

Jak wspomniałem wcześniej - obie biblioteki są zasilane przez podobne ekosystemy, mają podobne poglądy na budowanie aplikacji z małych komponentów. Obie biblioteki mają się dobrze - nic nie wskazuje na to, by któraś z nich miała zniknąć w najbliższej przyszłości. Co za tym idzie, oferty pracy w obu z nich pozostaną na podobnym poziomie.

Wnioski są proste - korzystaj z tego, co Ci odpowiada; zbieraj doświadczenia i oceniaj. Pomoże Ci to wypracować racjonalne podejście do tego, czy w danym projekcie lepiej użyć jednej czy drugiej biblioteki; staraj się też eksperymentować - nic tak nie uczy, jak błędy popełnione w przeszłości.

Najlepszy wybór dla CTO

Nie jest tajemnicą, że nie ma złotego środka, który będzie najlepszym rozwiązaniem dla konkretnego projektu. Szczególnie w przypadku front-endu, narzędzia wykorzystywane do budowania aplikacji szybko się starzeją i często trudno jest odnaleźć się w najnowszych trendach.

Wybór technologii nie jest jednak, a przynajmniej nie powinien być, rzutem na taśmę tego, co wpisuje się w aktualne trendy. Zamiast tego powinniśmy ukierunkować go na konkretne oczekiwania i założenia względem aplikacji, którą zamierzamy zbudować. Każda z porównywanych bibliotek ma swoje mocne i słabe strony, które dopasowane do przypadku użycia pozwolą nam dokonać najrozsądniejszego wyboru.

Ciekawą opcją mogą okazać się podsumowania technologiczne dużych korporacji, które często opisują swoje use-cases, jak przebiegał lub przebiega rozwój ogromnych aplikacji i jakie błędy popełniły w przeszłości. Być może znajdziemy wśród nich przypadki szczególnie interesujące w kontekście wyboru biblioteki do konkretnego projektu.

Cechy, które powinniśmy wziąć pod uwagę, aby wybrać odpowiednie narzędzia dla budowanej aplikacji, to: czas tworzenia aplikacji, łatwość tworzenia aplikacji, łatwość tworzenia aplikacji. konserwacja aplikacjizłożoność aplikacji i doświadczenie programistów w korzystaniu z określonych bibliotek.

Programiści to ludzie, którzy spędzają najwięcej czasu w porównywanych przeze mnie narzędziach i to oni mogą udzielić najlepszych porad i pomóc w dokonaniu najlepszego wyboru w wielkim starciu bibliotek. To właśnie podczas tworzenia aplikacji można dostrzec różne problemy, które wynikają bezpośrednio z wyboru technologii, i mieć najlepszy wgląd w to, jakie rzeczy podważają użycie konkretnego narzędzia do określonych funkcji.

Jak wspomniałem wcześniej - obie biblioteki nie wydają się znikać z rynekprzynajmniej nie w ciągu najbliższych kilku lat. Zamiast podejmować decyzje na podstawie statystyk i opinii
różnych osób z internetu - być może lepszą opcją jest po prostu rozmowa z deweloperami.

Przedstaw im, czego oczekujemy od aplikacji, jaki mamy czas na jej dostarczenie i pozwól na luźną wymianę opinii na temat tego, co sądzą o obu rozwiązaniach, zanim podejmiemy ostateczną decyzję.

Wnioski

Internetowe wojny zazwyczaj - a może w każdym przypadku - są bezcelowe. Zawsze znajdą się ludzie, którzy będą uparcie twierdzić, że ich wybór jest lepszy, nie podając przy tym żadnych racjonalnych argumentów potwierdzających ich decyzję.

Zamiast zaślepiać się konkretnymi wyborami - skupmy się na analizie, spróbujmy wyciągnąć odpowiednie wnioski i wykorzystać je do dostosowania lub odrzucenia konkretnego rozwiązania.

Tak jak sugeruje tytuł - nie zamierzam koronować żadnej konkretnej biblioteki jako lekarstwa na każdą bolączkę. Zamiast tego przedstawiam kilka hipotez oraz ujawniam mocne i słabe strony obu bibliotek. Dałem też kilka rad na co zwracać uwagę przy wyborze między nimi, aby podjąć mądrą decyzję i nie kierować się trendami czy przypadkowymi osobami z internetu.

Każde narzędzie może wystarczająco dobrze odpowiadać potrzebom projektu. Żadne z nich nie zniknie szybko z rynku w nadchodzących latach. Oba mają potężne społeczności i dość dużą dojrzałość, co pokazuje nam, że radzą sobie całkiem dobrze.

Ostateczny wybór leży w Twoich rękach. Jeśli jednak masz jakiekolwiek wątpliwości lub po prostu chcesz omówić swoją sprawę z The Codest - skontaktuj się z nami!

Czytaj więcej:

Dlaczego (prawdopodobnie) powinieneś używać Typescript

Jak nie zabić projektu złymi praktykami kodowania?

Strategie pobierania danych w NextJS