Super odcinek, wszystko fajnie zobrazowane i wytłumaczone. Takich filmów mi u Ciebie brakuje, są to oczywiste rzeczy ale myślę że ucząc się technologii 'w locie' niektórym z nas (przynajmniej mi) zdarza się pominąć ważną część dokumentacji. Tak miałem z Gatsbym, do dziś byłem pewny że to generator stron statycznych i nierozumiałem niektórych jego zachowań aż do momentu kiedy obejrzałem filmik ;)
Super tłumaczysz. Diagramy dużo pomagają. Jestem ba etapie ze potrafię zakodować prosty layout do html/css, a słuchając Ciebie az chce się wejść w programowanie :) Super odcinek!
Bardzo dobry odcinek, czułem się jak na wykładzie na studiach, że już miałem ochotę notatnik wyjąć i zapisywać :D ale dzięki za rozjaśnienie "co z czym się je" :)
Hej. Odnośnie Next.js trzeba wspomnieć o kilku ważnych rzeczach: 1. Tylko pierwsze wgranie strony jest renderowane po stronie serwera. Potem routing jest już po stronie przeglądarki i kolejne strony działają podobnie jak na czystym Reakcie, pobierając dane z cms po stronie klienta bez SSR. 2. Pierwsze wczytanie strony przy SSR będzie odrobinę wolniejsze niż przy stronach statycznych bo serwer musi wykonać pracę aby wysłać nam HTML z danymi z cms. Kolejne podstrony będą już działać tak samo szybko niezależnie czy to czysty React, Next czy Gatsby. 3. Next.js podobnie jak Gatsby może działać jako generator stron statycznych oraz w trybie hybrydowym, od wersji Next 9 zostało to super zoptymalizowane i next automatycznie dla stron bez GetInitialProps renderuje strony statyczne i tylko tam gdzie wcześniej pobieramy propsy (np z api) robi SSR. 4. Wersja 9 Next jest dużo lepsza, warto poczytać. Od 9.1 uprościli też routing dla dynamicznych zmiennych w adresie. 5. Next jest mimo wszystko najbardziej skomplikowaną i czasochłonną z tych 3 opcji. Więc jeśli nie zależy nam na SEO i performance nie jest krytyczny to najprościej będzie zrobić App w czystym React. Jeśli SEO i performance są b.ważne ale strona rzadko będzie się zmieniać, nie jest to aplikacja typu czat czy social media a raczej blog czy serwis informacyjny, to najlepszy będzie Gatsby. Natomiast jeśli SEO i performance są ważne ale treści bardzo często się zmieniają, są generowane np przez użytkowników, to najlepiej sprawdzi się Next.js
@@helloroman dziękuję pięknie za miłe słowa :D Odezwałem się ponieważ większość ludzi używa w Polsce Gatsby i porównując go do Next pomijają fakt, że Next/Nuxt to dwa w jednym. Przemilczają ten fakt nawet prelegenci na konferencjach. Next jest najtrudniejszy do opanowania i wdrożenia ale daje też najwięcej możliwości i ogromną elastyczność, co w dłuższej perspektywie może się opłacić. Więc jeśli ktoś jeszcze nie wie jak często będą dodawane treści (konieczność robienia build w Gatsby) ale planuje funkcje z User Generated Content, to IMHO bezpieczniej będzie wybrać Next.js (przy dużej skali może zaoszczędzić masę kasy na CI/CD robiące build wielokrotnie w ciągu dnia ;) )
Z drugiej strony, jeśli wybierzemy Next.js a potem się okaże, że treści się zmieniają 1 raz dziennie to zmarnujemy masę kasy na dodatkowy czas potrzebny na Development oraz przy dużym ruchu masę zasobów serwera na SSR (ale wtedy możemy wygenerować strony statyczne i np tylko home page zostawić jako SSR jeśli na niej najczęściej się treści pojawiają). Reasumując: trudny wybór ;)
OH MAN! zajebisty odcinek! tego było mi trzeba!!! przezajebisty, trafiłeś idealnie w moment, kiedy czytam o next.js i się zastanawiam, a może by tak next.js, na codzien w większości używam gatsbiego
Podsumowując: Czy można jednoznacznie stwierdzić, że Gatsby bierze co najlepsze z Next.js i vanila React, a przynajmniej próbuje? Co na podstawie doświadczenia, polecił byś klientowi Roman, jeśli chodzi o SEO, szybkość reakcji robotów Googla? Świetny merytoryczny film, bez górnolotnych słów :)
Podczas doradzania klientom zawsze biorę pod uwagę mnóstwo czynników - nie ma tutaj jednej odpowiedzi. Czasem polecam Reacta, czasem Nexta a czasem Gatsbyego (często konsultując to też z innymi devami, bo zawsze można być po prostu w błędzie). A czy Gatsby bierze to co najlepsze? Moim zdaniem tak, ale nie można zaprzeczyć że te wszystkie technologie są po prostu fajne i mają swoje niezaprzeczalne zalety (oraz wady ;)).
[Gatsby] 15:55 Niby tak, ale na froncie można sobie doczytać z back-endu nowe rzeczy, więc aby je widzieć nie trzeba robić za każdym razem builda, [Next] 16:07 Niby tak, ale Next również generuje, cachuje statyczne strony. Tak tylko mówię, że różnice bywają niewielkie ;)
@@helloroman A jakaś podpowiedź do konkretnego przypadku jak choćby oklepanego ToDo? Często używa się modułów IIFE w tym celu. Ale jakiś czas temu ostatnio widziałem, ciekawą architekturę tutaj: github.com/Colt/webpack-demo-app , gdzie autor stworzył JS'owe klasy do obsługi konkretnych elementów HTML ne jako dzieląc je na komponenty, a następne połączył to wszystko całość przy pomocy funkcji run-która jest jak mniemam odpowiednikiem Mediator patterns.
Kończe Twój trzeci kurs na eduweb-ie. Swoją drogą to Twoje kursy podniosły znacznie poziom całej platformy, uważam je za bardzo dobre, czasem 10 min. kursu przerabiam godzine, aby dokładnie zrozumieć rozwiązania. Wg. mnie to taki materiał do którego trzeba wielokrotnie wracać, aby w pełni opanować wzorce. Jedna uwaga/prośba/spostrzeżenie: widać że rozwiązanie przychodzą wraz z rozwojem projektu. Natomiast wydaje mi się że jeden zabieg podniosłoby jeszcze jakość i używalność kursu. Mógłbyś po danym rozdziale nagrywać i dodawać na wstęp krótkie podsumowanie w krokach co będziesz robił. Nagranie przed zrobieniem działu może być trudne bo jak rozumiem wizja może się zmienić. Mi tego bardzo brakowało, gdy chciałem coś zrealizować w przód przed Tobą. Brakowało mi takiej roadmapy dokąd zmierzasz. Dzięki za kursy i czekam na Gatsbego.
Czy Next.js nie jest czasem najbardziej "uniwersalny"? Poprawcie mnie jeśli się mylę, ale wydaje mi się, że Next jest technologią pomiędzy Gatsby i Vanilla React, która może mieć zarówno CSR, SSR i SSG. Swoją drogą świetny odcinek. Bardzo starannie wytłumaczone. Pozdro!
Wydaje mi się, że faktycznie można Nexta nazwać najbardziej uniwersalnym - pytanie tylko czy to faktycznie jest jakaś ogromna zaleta. W moim odczuciu nie ma dla mnie zbyt wielkiej różnicy w czym pisze jeśli chodzi o te trzy technologie. Biorę tę, która najbardziej pasuje do danego projektu.
Akurat z tego co mi wiadomo SSR Netflixa jest jeszcze ciekawsze. Mianowicie Netflix nie jest typową apką SPA. Zmiana podstrony wywołuje całkowite przeładowanie Netflixa. Nie jestem ekspertem, ale prawdopodobnie framework back-endowy przekazuje swoje dane bezpośrednio do templatów wysyłanych później klientowi, bez pośrednictwa API. Oznacza to więc, że "cały react" jest wysyłany za każdym przeładowaniem? Nie. Ta ciekawa technika łączy standardowe używanie template enginów z MPA z SSR znanym z tego z Nexta. Reactowi wydaje się, że dostał te dane od programisty z palca, że one cały czas tam były, a w rzeczywistości do template'u wpisał je framework backendowy, który później tę mieszankę renderuje i wysyła .html do klienta. :)
Mogłeś jescze coś wspomnieć o Nuxt.js który jest tym dla Vue czym Next.js dla Reacta oraz dodatkowo Nuxt.js oferuje opcje Pre Renderingu, którą omawiałeś w ramach Gatsby.js, wydaje mi się to ciekawe ponieważ nie wymaga to od nas nauki kolejnego framweorka tylko po to aby zrobić pre rendering
Co nie zmienia faktu, że Nuxt podobnie jak Next wymaga serwera Node'owego nawet jak sobie wyrenderujesz statyczne strony w niektórych miejscach (chyba?).
@Roman Niestety na każdym kroku spotykam się z porównaniami w stylu 'Gatsby do statycznych, Nuxt/Next do SSR'. Niemal wszyscy miłośnicy Gatsby totalnie pomijają fakt, że Next to 2 w 1, co jest bardzo stronnicze i krzywdzące. Nie zakładam złej woli tylko brak wiedzy, ale spotykam się z tym tak często i to na konferencjach od prelegentów = autorytetów, że mnie to denerwuje... Next pozwala na super elastyczność w projekcie jeśli jeszcze nie jesteśmy pewni czy i które strony naszej aplikacji będą wymagały SSR 'live', a dla których wystarczy statycznie wygenerowana strona.
@@MrLumatic no tak, tylko przede wszystkim trzeba zdawać sobie sprawę z tego jak działa SSR i czy jest Ci on w ogóle potrzeby. Koszty infrastruktury rosną nieporównywalnie w stosunku do zwykłego serwerka dla Reacta czy Gatsbyego.
Ja chciałbym zobaczyć mały poradnik "z drugiej jakby praktycznej strony". Tzn chce zbudować stronę firmową - wybieram to, chcę zbudować bloga - wybieram tamto, potrzebuję zrobić mały sklep - wybieram jeszcze coś innego. Bo tak niby wiem czym się różnią te rozwiązania, a i tak nie wiem które wybrać, wybór odpowiedniej bazy danych też sprawia mi problem . I jeszcze pytanko czy gatsby będzie znacząco szybszy niż dobrze zoptymalizowany Wordpress z wtyczką LiteSpeed Cache?
Wiesz dobór narzędzi często zależy wyłącznie od preferencji developera. Jeden wybierze Postgresql, inny MongoDB, trzeci ogarnie Firebase (o ile wszystkie trzy spełniają wymagania projektowe). Podobnie jest z frontendem. Nikt Ci nie da recepty na jakieś rozwiązanie :) Musisz sam sobie to wykminić. A co do WP vs. Gatsby - to nie robiłem porównania, ale z dużą dozą pewności mogę założyć, że Gatsby by wygrał ten pojedynek
Fajny odcinek, ale z tego co zrozumiałem, to niekoniecznie SSR Gatsbiego nadaje się do tworzenia każdego projektu. Przykładowo, mamy aplikacje w której jest panel zarządzania dzięki któremu można tworzyć użytkowników razem z osobną podstrona dla każdego z nich (example.com/{user}). Z tego co zrozumiałem, to przy każdym stworzonym takim użytkowniku należy zbudować aplikacje na nowo by wygenerowała pliki, czyż nie? Wtedy taki e-commerce jaki został podany w filmiku odpada. Tak przynajmniej zrozumiałem.
W którym momencie kończysz pracę? Np. W większych projektach w React wchodzisz w Redux czy to już jest dla backendu? Przy Gatsby idziesz w Graphql czy nie musisz? 🤔
@@helloroman To teraz Nexcior! Jest super, wiele ludzi musi się o nim dowiedzieć. Korzystałem z CRA, Gatsbiego i Next'a i z tej trójeczki najlepszy był subiektywnie Next. Swoboda z jednoczesnym nafaszerowaniem przydatnymi funkcjami. Żyć nie umierać. :)
@@helloroman Jest bardzo podobna do JS, więc nie powinno być problemu. Jakbyś miał czas, to spróbuj, naprawdę warto. Tworzysz jedną apkę i wykorzystujesz ją na Web, Android i IOS. Ale wiadomo - kto co woli. :)
Panie Romanie i drodzy komentujący :) Czy może wyjaśni mi ktoś jak spiąć Gatsby z Wordpressem. Załóżmy że mam postawionego WP na serwerze gdzie mam dodane posty i strony. Chcialbym z niego zasysać dane do mojej strony w Gatsby i to wiem jak dziala, pobieram plugin do wordpressa i graphem wyciagam sobie potrzebne dane itd. Jednak jak to sie ma przy deployu ? wystawiam gatsbyego na domene ***** ***.pl , a wordpress ktory przeciez dziala w PHP gdzie ma byc postawiony ? Lokalnie albo na jakiejs subdomenie np forever.***** ***.pl ? A druga sprawa jest taka, czy po kazdej zmianie w CMS/wordpressie np dodaniu nowego posta lub jego edycji musze odpalać projekt, budować na nowo (gatsby develop i gatsby build) i znów wrzucać recznie na serwer ? Rozumie, że to nie dziala jak typowy wordpress, gdzie zaloguje sie do wp-admina, dodam post i od razu widze zmiany na docelowej domenie. Mam nadzieję że zbytnio nie zamieszałem i liczę na odpowiedzi. Pozdro:)
1. WP najlepiej trzymać gdzieś na serwerze, żebyś mógł się z tym komunikować podczas buildowania strony 2. Przy zmianie czegoś w CMS najlepiej używać Webhooks ale nie mam pojęcia jak to zrobić na WP Generalnie WP pomimo tego, że ma te headlessowe ficzery teraz, to moim zdaniem nie nadaje się do tego jakoś szczególnie, głównie przez to, że sporo rzeczy trzeba tam zrobić naokoło albo totalnie customowo i tak. No ale jest darmowy :P
hello roman dzięki za odpowiedz, wiem ze pewnie są lepsze rozwiązania ale na codzień koduje w php customowe theme do wp i znam dobrze jego architekturę z tad padło właśnie na wp. No ale może czas coś poszukać innego :) w każdym razie dzięki , pozdro i ******* ***** !
Cześć. Jakbyś mógł to zaktualizuj proszę z kursu "W praktyce" część dotyczącą Storybook ze względu na kompletnie inną składnię. Chociażby tutaj na YT. Pozdrawiam.
@@helloroman Zastanawiałem się nad tym, ale nie znam póki co żadnego JS'a, więc chciałem stopniowo zacząć go wprowadzać. Póki co robiłem tylko kopiuj-wklej co nie do końca mnie zadowala, pojawiają się błędy i nie wiem o co chodzi :D
Nie wiem w sumie czy to jest 1:1 przełożenie, ale skojarzyła mi się w sumie nazwa - niech ktoś mądrzejszy może się wypowie - jest coś takiego jak NEST.JS, framework no właśnie po stronie serwera, Nodejs-owy, oparty o Express js. Ciekawostka, twórcą Nest.js jest Polak, Kamil Myśliwiec, także, no, heh "wspierajcie polskie rap płyty"..eee.. "wspierajcie polskie frameworki"
Ale co jak chcę zrobić np. stronę gdzie mogę dodawać posty, które od razu się pojawi to przecież Gatsbyy można od razu wyeliminować ? Bo nie wyobrażam sobie czekać parę min, aż apka sie zbuilduje i wyśle na server, czy ja tu czegoś nie zrozumiałem ?
Tak - dlatego trzeba rozważyć za i przeciw. Jeśli masz aplikację, która np. ma informować o jakichś super pilnych newsach gdzie liczy się każda sekunda no to Gatsby pozwala Ci jedynie korzystać z normalnego API reactowego i np. zapiąć tam axiosa. Ale to wtedy nie jest w 100% Gatsby-way. Jeśli natomiast masz bloga, stronę z artykułami gdzie czas nie jest czynnikiem mission-critical i możesz mieć opóźnienie rzędu kilku minut, to wtedy Gatsby będzie nadal świetną opcją. Kwestia indywidualnych potrzeb projektu ;)
Super odcinek, wszystko fajnie zobrazowane i wytłumaczone. Takich filmów mi u Ciebie brakuje, są to oczywiste rzeczy ale myślę że ucząc się technologii 'w locie' niektórym z nas (przynajmniej mi) zdarza się pominąć ważną część dokumentacji. Tak miałem z Gatsbym, do dziś byłem pewny że to generator stron statycznych i nierozumiałem niektórych jego zachowań aż do momentu kiedy obejrzałem filmik ;)
Spoko odcinek, łapka w górę od razu i oglądamy. Może odcinek o Rx.js ? Ewentualnie o GraphQL ;)
Ale super, czytasz w myślach z tymi swoimi kursami! Już się nie mogę doczekać 😀
Super tłumaczysz. Diagramy dużo pomagają. Jestem ba etapie ze potrafię zakodować prosty layout do html/css, a słuchając Ciebie az chce się wejść w programowanie :) Super odcinek!
Bardzo dobry odcinek, czułem się jak na wykładzie na studiach, że już miałem ochotę notatnik wyjąć i zapisywać :D ale dzięki za rozjaśnienie "co z czym się je" :)
Dzięki wielkie! ❤️ Cieszę się, że pomogłem :)
chciałbym sie czuc na wykładzie, tak jak tutaj :D
Gatsby jest mega 😁 nie pozostaje nic innego, jak czekać na kurs - tym bardziej, że od dzisiaj mam abonament na eduwebie 😉
Hej. Odnośnie Next.js trzeba wspomnieć o kilku ważnych rzeczach:
1. Tylko pierwsze wgranie strony jest renderowane po stronie serwera. Potem routing jest już po stronie przeglądarki i kolejne strony działają podobnie jak na czystym Reakcie, pobierając dane z cms po stronie klienta bez SSR.
2. Pierwsze wczytanie strony przy SSR będzie odrobinę wolniejsze niż przy stronach statycznych bo serwer musi wykonać pracę aby wysłać nam HTML z danymi z cms. Kolejne podstrony będą już działać tak samo szybko niezależnie czy to czysty React, Next czy Gatsby.
3. Next.js podobnie jak Gatsby może działać jako generator stron statycznych oraz w trybie hybrydowym, od wersji Next 9 zostało to super zoptymalizowane i next automatycznie dla stron bez GetInitialProps renderuje strony statyczne i tylko tam gdzie wcześniej pobieramy propsy (np z api) robi SSR.
4. Wersja 9 Next jest dużo lepsza, warto poczytać. Od 9.1 uprościli też routing dla dynamicznych zmiennych w adresie.
5. Next jest mimo wszystko najbardziej skomplikowaną i czasochłonną z tych 3 opcji.
Więc jeśli nie zależy nam na SEO i performance nie jest krytyczny to najprościej będzie zrobić App w czystym React.
Jeśli SEO i performance są b.ważne ale strona rzadko będzie się zmieniać, nie jest to aplikacja typu czat czy social media a raczej blog czy serwis informacyjny, to najlepszy będzie Gatsby.
Natomiast jeśli SEO i performance są ważne ale treści bardzo często się zmieniają, są generowane np przez użytkowników, to najlepiej sprawdzi się Next.js
Dzięki za to uzupełnienie. Nie ukrywam, że Nexta z tej trójki znam najsłabiej - tego typu komentarze to czyste złoto ❤️
@@helloroman dziękuję pięknie za miłe słowa :D
Odezwałem się ponieważ większość ludzi używa w Polsce Gatsby i porównując go do Next pomijają fakt, że Next/Nuxt to dwa w jednym. Przemilczają ten fakt nawet prelegenci na konferencjach.
Next jest najtrudniejszy do opanowania i wdrożenia ale daje też najwięcej możliwości i ogromną elastyczność, co w dłuższej perspektywie może się opłacić.
Więc jeśli ktoś jeszcze nie wie jak często będą dodawane treści (konieczność robienia build w Gatsby) ale planuje funkcje z User Generated Content, to IMHO bezpieczniej będzie wybrać Next.js (przy dużej skali może zaoszczędzić masę kasy na CI/CD robiące build wielokrotnie w ciągu dnia ;) )
Z drugiej strony, jeśli wybierzemy Next.js a potem się okaże, że treści się zmieniają 1 raz dziennie to zmarnujemy masę kasy na dodatkowy czas potrzebny na Development oraz przy dużym ruchu masę zasobów serwera na SSR (ale wtedy możemy wygenerować strony statyczne i np tylko home page zostawić jako SSR jeśli na niej najczęściej się treści pojawiają).
Reasumując: trudny wybór ;)
OH MAN! zajebisty odcinek! tego było mi trzeba!!! przezajebisty, trafiłeś idealnie w moment, kiedy czytam o next.js i się zastanawiam, a może by tak next.js, na codzien w większości używam gatsbiego
Podsumowując: Czy można jednoznacznie stwierdzić, że Gatsby bierze co najlepsze z Next.js i vanila React, a przynajmniej próbuje?
Co na podstawie doświadczenia, polecił byś klientowi Roman, jeśli chodzi o SEO, szybkość reakcji robotów Googla?
Świetny merytoryczny film, bez górnolotnych słów :)
Podczas doradzania klientom zawsze biorę pod uwagę mnóstwo czynników - nie ma tutaj jednej odpowiedzi. Czasem polecam Reacta, czasem Nexta a czasem Gatsbyego (często konsultując to też z innymi devami, bo zawsze można być po prostu w błędzie). A czy Gatsby bierze to co najlepsze? Moim zdaniem tak, ale nie można zaprzeczyć że te wszystkie technologie są po prostu fajne i mają swoje niezaprzeczalne zalety (oraz wady ;)).
Fajnie to opisałeś. Brakuje w necie szerszego kontekstu n/t filozofii działania webowych aplikacji. Masz dar do tłumaczenia takich rzeczy to fakt.
Postaram się w przyszłości tworzyć więcej takich odcinków, bo widzę że Twoja opinia nie jest odosobniona ❤️ Pozdro!
[Gatsby] 15:55 Niby tak, ale na froncie można sobie doczytać z back-endu nowe rzeczy, więc aby je widzieć nie trzeba robić za każdym razem builda, [Next] 16:07 Niby tak, ale Next również generuje, cachuje statyczne strony. Tak tylko mówię, że różnice bywają niewielkie ;)
Cześć Roman dzięki za odcinek. Mógłbyś zrobić serie o skalowanej architekturze aplikacji frond-endowego vanilla JS?
Nie ma uniwersalnego rozwiązania - architektura musi być dopasowana do potrzeb projektu, a nie odwrotnie.
@@helloroman A jakaś podpowiedź do konkretnego przypadku jak choćby oklepanego ToDo? Często używa się modułów IIFE w tym celu. Ale jakiś czas temu ostatnio widziałem, ciekawą architekturę tutaj: github.com/Colt/webpack-demo-app , gdzie autor stworzył JS'owe klasy do obsługi konkretnych elementów HTML ne jako dzieląc je na komponenty, a następne połączył to wszystko całość przy pomocy funkcji run-która jest jak mniemam odpowiednikiem Mediator patterns.
Przejrzyście wyjaśnione. Super !
Świetnie wytłumaczone:) Ale jeśli chodzi o Gatsbiego, to nie widzę za bardzo ofert pracy z tą technologią, czy firmy w Polsce korzystają z niego?
Raczej oferują Reacta po prostu. A korzystać korzystają :) My w Netguru na przykład używamy w kilku projektach
@@helloroman Aa, to spoko:))
Genialny film! Dzięki wielkie!
Kończe Twój trzeci kurs na eduweb-ie. Swoją drogą to Twoje kursy podniosły znacznie poziom całej platformy, uważam je za bardzo dobre, czasem 10 min. kursu przerabiam godzine, aby dokładnie zrozumieć rozwiązania. Wg. mnie to taki materiał do którego trzeba wielokrotnie wracać, aby w pełni opanować wzorce. Jedna uwaga/prośba/spostrzeżenie: widać że rozwiązanie przychodzą wraz z rozwojem projektu. Natomiast wydaje mi się że jeden zabieg podniosłoby jeszcze jakość i używalność kursu. Mógłbyś po danym rozdziale nagrywać i dodawać na wstęp krótkie podsumowanie w krokach co będziesz robił. Nagranie przed zrobieniem działu może być trudne bo jak rozumiem wizja może się zmienić. Mi tego bardzo brakowało, gdy chciałem coś zrealizować w przód przed Tobą. Brakowało mi takiej roadmapy dokąd zmierzasz. Dzięki za kursy i czekam na Gatsbego.
Siemka! Wielkie dzięki za tak miłe słowa, na maksa doceniam ❤️ Feedback naturalnie wezmę pod uwagę na przyszłość
Czy Next.js nie jest czasem najbardziej "uniwersalny"?
Poprawcie mnie jeśli się mylę, ale wydaje mi się, że Next jest technologią pomiędzy Gatsby i Vanilla React, która może mieć zarówno CSR, SSR i SSG.
Swoją drogą świetny odcinek. Bardzo starannie wytłumaczone. Pozdro!
Wydaje mi się, że faktycznie można Nexta nazwać najbardziej uniwersalnym - pytanie tylko czy to faktycznie jest jakaś ogromna zaleta. W moim odczuciu nie ma dla mnie zbyt wielkiej różnicy w czym pisze jeśli chodzi o te trzy technologie. Biorę tę, która najbardziej pasuje do danego projektu.
Akurat z tego co mi wiadomo SSR Netflixa jest jeszcze ciekawsze. Mianowicie Netflix nie jest typową apką SPA. Zmiana podstrony wywołuje całkowite przeładowanie Netflixa. Nie jestem ekspertem, ale prawdopodobnie framework back-endowy przekazuje swoje dane bezpośrednio do templatów wysyłanych później klientowi, bez pośrednictwa API. Oznacza to więc, że "cały react" jest wysyłany za każdym przeładowaniem? Nie. Ta ciekawa technika łączy standardowe używanie template enginów z MPA z SSR znanym z tego z Nexta. Reactowi wydaje się, że dostał te dane od programisty z palca, że one cały czas tam były, a w rzeczywistości do template'u wpisał je framework backendowy, który później tę mieszankę renderuje i wysyła .html do klienta. :)
To mega ciekawe, dzięki
Mogłeś jescze coś wspomnieć o Nuxt.js który jest tym dla Vue czym Next.js dla Reacta oraz dodatkowo Nuxt.js oferuje opcje Pre Renderingu, którą omawiałeś w ramach Gatsby.js, wydaje mi się to ciekawe ponieważ nie wymaga to od nas nauki kolejnego framweorka tylko po to aby zrobić pre rendering
Co nie zmienia faktu, że Nuxt podobnie jak Next wymaga serwera Node'owego nawet jak sobie wyrenderujesz statyczne strony w niektórych miejscach (chyba?).
@@helloroman nope możesz sobie zrobić nuxt generate i potem wrzucić na Netlify zobacz sobie tutaj: nuxtjs.org/guide/
@@kanowstudio9198 o widzisz :) No to mega. Ciekawa alternatywa w takim razie.
@Roman Niestety na każdym kroku spotykam się z porównaniami w stylu 'Gatsby do statycznych, Nuxt/Next do SSR'. Niemal wszyscy miłośnicy Gatsby totalnie pomijają fakt, że Next to 2 w 1, co jest bardzo stronnicze i krzywdzące. Nie zakładam złej woli tylko brak wiedzy, ale spotykam się z tym tak często i to na konferencjach od prelegentów = autorytetów, że mnie to denerwuje...
Next pozwala na super elastyczność w projekcie jeśli jeszcze nie jesteśmy pewni czy i które strony naszej aplikacji będą wymagały SSR 'live', a dla których wystarczy statycznie wygenerowana strona.
@@MrLumatic no tak, tylko przede wszystkim trzeba zdawać sobie sprawę z tego jak działa SSR i czy jest Ci on w ogóle potrzeby. Koszty infrastruktury rosną nieporównywalnie w stosunku do zwykłego serwerka dla Reacta czy Gatsbyego.
Fajny odcinek, pomógł mi wybrać technologię najlepszą do strony, którą aktualnie będę tworzył. Pozdrawiam!
Mega dobra robota hello roman !
Zajebisty odcinek!
niestety "/dupa" przekierowała mnie na stronę główną a nie 404 :c
O widzisz, możliwe że usunąłem 404.js - dzięki za info
@@helloroman Powinieneś zrobić specjalną stronę na temat dupy w takim wypadku. :D
@@cholewciax To jest myśl :D
hehe. też musiałem sprawdzić :D szybka pauza i zawód. miałem trochę nadzieję na easter egga.
z innej bajki: jaki model okularów nosisz? Ewentualnie gdzie je kupiłeś? :) Pozdrawiam serdecznie ps. odcinek jak zawsze na plus :)
Muscat :) dzięki
Proponuje poruszyć temat Vue oraz Nuxt ponieważ jest to również ciekawy temat.
Ja chciałbym zobaczyć mały poradnik "z drugiej jakby praktycznej strony". Tzn chce zbudować stronę firmową - wybieram to, chcę zbudować bloga - wybieram tamto, potrzebuję zrobić mały sklep - wybieram jeszcze coś innego. Bo tak niby wiem czym się różnią te rozwiązania, a i tak nie wiem które wybrać, wybór odpowiedniej bazy danych też sprawia mi problem . I jeszcze pytanko czy gatsby będzie znacząco szybszy niż dobrze zoptymalizowany Wordpress z wtyczką LiteSpeed Cache?
Wiesz dobór narzędzi często zależy wyłącznie od preferencji developera. Jeden wybierze Postgresql, inny MongoDB, trzeci ogarnie Firebase (o ile wszystkie trzy spełniają wymagania projektowe). Podobnie jest z frontendem. Nikt Ci nie da recepty na jakieś rozwiązanie :) Musisz sam sobie to wykminić. A co do WP vs. Gatsby - to nie robiłem porównania, ale z dużą dozą pewności mogę założyć, że Gatsby by wygrał ten pojedynek
Fajny odcinek, ale z tego co zrozumiałem, to niekoniecznie SSR Gatsbiego nadaje się do tworzenia każdego projektu. Przykładowo, mamy aplikacje w której jest panel zarządzania dzięki któremu można tworzyć użytkowników razem z osobną podstrona dla każdego z nich (example.com/{user}). Z tego co zrozumiałem, to przy każdym stworzonym takim użytkowniku należy zbudować aplikacje na nowo by wygenerowała pliki, czyż nie? Wtedy taki e-commerce jaki został podany w filmiku odpada. Tak przynajmniej zrozumiałem.
Masz racje, choc w ecommerce rzadko uzykownicy maja swoje podstrony. Ale przyklad rozumiem i jak njabardziej jest poprawny.
@@helloroman Tak, przykład użytkowników i e-commerce nie był do końca przemyślany, ale wystarczy zamienić userów na produkty i wychodzi na to samo :)
W którym momencie kończysz pracę? Np. W większych projektach w React wchodzisz w Redux czy to już jest dla backendu? Przy Gatsby idziesz w Graphql czy nie musisz? 🤔
Redux to frontend przeciez :) w Gatsby graphql masz zaszyte praktycznie
@@helloroman jeszcze daleka droga przede mną... :) dzięki za odpowiedź
Super odcinek! Moze jakies male wprowadzenia praktyczne do Nexta i Gatsby na kanale tak na zachęte? ^^
Gatsby już było ;)
@@helloroman To teraz Nexcior! Jest super, wiele ludzi musi się o nim dowiedzieć. Korzystałem z CRA, Gatsbiego i Next'a i z tej trójeczki najlepszy był subiektywnie Next. Swoboda z jednoczesnym nafaszerowaniem przydatnymi funkcjami. Żyć nie umierać. :)
No tylko koszt infrastruktury nieporównywalnie wyższy :p
@@helloroman Ło cholera. O tym jeszcze nie pomyślałem.
Hejka, w czym robiłeś te diagramy? Bardzo fajne
Siema, w Figmie - jak wszystko co robie ostatnio :P
Co sądzisz o Flutterze? Ja nie cierpię Reacta, za to Flutter Web jest po prostu genialny w mojej opinii.
Nigdy nie korzystałem, ale składania Darta mi średnio siedzi
@@helloroman Jest bardzo podobna do JS, więc nie powinno być problemu. Jakbyś miał czas, to spróbuj, naprawdę warto. Tworzysz jedną apkę i wykorzystujesz ją na Web, Android i IOS. Ale wiadomo - kto co woli. :)
Panie Romanie i drodzy komentujący :) Czy może wyjaśni mi ktoś jak spiąć Gatsby z Wordpressem. Załóżmy że mam postawionego WP na serwerze gdzie mam dodane posty i strony. Chcialbym z niego zasysać dane do mojej strony w Gatsby i to wiem jak dziala, pobieram plugin do wordpressa i graphem wyciagam sobie potrzebne dane itd. Jednak jak to sie ma przy deployu ? wystawiam gatsbyego na domene ***** ***.pl , a wordpress ktory przeciez dziala w PHP gdzie ma byc postawiony ? Lokalnie albo na jakiejs subdomenie np forever.***** ***.pl ? A druga sprawa jest taka, czy po kazdej zmianie w CMS/wordpressie np dodaniu nowego posta lub jego edycji musze odpalać projekt, budować na nowo (gatsby develop i gatsby build) i znów wrzucać recznie na serwer ? Rozumie, że to nie dziala jak typowy wordpress, gdzie zaloguje sie do wp-admina, dodam post i od razu widze zmiany na docelowej domenie. Mam nadzieję że zbytnio nie zamieszałem i liczę na odpowiedzi. Pozdro:)
1. WP najlepiej trzymać gdzieś na serwerze, żebyś mógł się z tym komunikować podczas buildowania strony
2. Przy zmianie czegoś w CMS najlepiej używać Webhooks ale nie mam pojęcia jak to zrobić na WP
Generalnie WP pomimo tego, że ma te headlessowe ficzery teraz, to moim zdaniem nie nadaje się do tego jakoś szczególnie, głównie przez to, że sporo rzeczy trzeba tam zrobić naokoło albo totalnie customowo i tak. No ale jest darmowy :P
hello roman dzięki za odpowiedz, wiem ze pewnie są lepsze rozwiązania ale na codzień koduje w php customowe theme do wp i znam dobrze jego architekturę z tad padło właśnie na wp. No ale może czas coś poszukać innego :) w każdym razie dzięki , pozdro i ******* ***** !
@@hxllxrr A to jak znasz WP to może być całkiem spoko opcja w takim razie. Ja nie znam, dlatego raczej bym tego nie wykorzystał.
W FAQach na Twojej stronie brak odpowiedzi na pytanie "dokąd tupta nocą jeż?"
No bo do dzisiaj nie wiem :C
Może ankietę zrobić? ;)
Cześć. Jakbyś mógł to zaktualizuj proszę z kursu "W praktyce" część dotyczącą Storybook ze względu na kompletnie inną składnię. Chociażby tutaj na YT. Pozdrawiam.
Hej, a czy przypadkiem stara składania nadal nie jest poprawna? Bo ostatnio pisałem w nowym Storybooku i wydaje mi się, że jest
Co sądzisz o używaniu next.js z generowaniem statycznej strony?
Słyszałem, że super opcja, ale nie korzystałem. Jeden pies wtedy czy używasz gatsby czy next moim zdaniem.
@@helloroman tylko jakbyś z czasem stwierdził że jednak potrzebujesz SSR to chyba lepiej być na next.js 😅?
@@ElGovanni niby tak, ale są projekty gdzie od początku wiadomo, że SSR to overkill
Dzieeeki
SupA ;)
A nie mówiłeś w którymś odcinku, o react'cie, angularze i vue js ? Czyli react to nie tylko framework js, tak?
Po czym poznac Frontendowce na plazy? Zaczepia panny i łączy stringi
Jaki JS najlepiej zagra z Django?
Nie wolisz napisać frontendu jako osobnego serwisu?
@@helloroman Zastanawiałem się nad tym, ale nie znam póki co żadnego JS'a, więc chciałem stopniowo zacząć go wprowadzać. Póki co robiłem tylko kopiuj-wklej co nie do końca mnie zadowala, pojawiają się błędy i nie wiem o co chodzi :D
Myślę że front na django można zrobić żeby wiedzieć o co chodzi ale potem juz bym się zabrał za rest api żeby jednak front był osobnym bytem
Czyli wszystko zmierza do tego żeby taki sobie front-end-człowiek stał się full-stack-człowiekiem
React: *NEXT*
Vue: *NUXT*
Angular: *NAXT*??? XD
Angular: Angular
Nie wiem w sumie czy to jest 1:1 przełożenie, ale skojarzyła mi się w sumie nazwa - niech ktoś mądrzejszy może się wypowie - jest coś takiego jak NEST.JS, framework no właśnie po stronie serwera, Nodejs-owy, oparty o Express js. Ciekawostka, twórcą Nest.js jest Polak, Kamil Myśliwiec, także, no, heh "wspierajcie polskie rap płyty"..eee.. "wspierajcie polskie frameworki"
@@jankiel3284 Angular sam w sobie ma wbudowany ssr, nie potrzeba niczego innego.
i Svelte. NVXT
Ale co jak chcę zrobić np. stronę gdzie mogę dodawać posty, które od razu się pojawi to przecież Gatsbyy można od razu wyeliminować ? Bo nie wyobrażam sobie czekać parę min, aż apka sie zbuilduje i wyśle na server, czy ja tu czegoś nie zrozumiałem ?
Tak - dlatego trzeba rozważyć za i przeciw. Jeśli masz aplikację, która np. ma informować o jakichś super pilnych newsach gdzie liczy się każda sekunda no to Gatsby pozwala Ci jedynie korzystać z normalnego API reactowego i np. zapiąć tam axiosa. Ale to wtedy nie jest w 100% Gatsby-way. Jeśli natomiast masz bloga, stronę z artykułami gdzie czas nie jest czynnikiem mission-critical i możesz mieć opóźnienie rzędu kilku minut, to wtedy Gatsby będzie nadal świetną opcją. Kwestia indywidualnych potrzeb projektu ;)
A jak się ma do tego vue.js bo podobno najprostrzy do nauki?
Vue = React, Nuxt = Next, Gridsome = Gatsby
@@helloroman Nest != Next
@@filip69955 thx, literówka
Ja pisze w Reactcie
Jak piszesz w React'cie to piszesz też w Next i Gatsby :P Różnice nie są jakieś ogromne