Ostatnie tygodnie to istne szaleństwo jeśli chodzi o nowości z obszaru Server Side Rendering. W tym tygodniu wydany został Gatsby 5, który znacznie usprawnia Incremental Builds i dodaje eksperymentalne wsparcie dla React Server Components.
1. Gatsby 5
Zeszłotygodniowy przegląd zaczynaliśmy od wspomnienia, że w obszarze Server Side Renderingu sporo się dzieje. Przełom października i listopada jest kulminacją tego trendu. Najpierw Vercel zaprezentował światu Next.js 13, potem Shopify ogłosił, że przejmuje Remix i oprze o niego swój framework Hydrogen, a teraz na języki wszystkich wraca wyblakła gwiazda renderowania po stronie serwera – Gatsby. Jeszcze ciepła wersja 5 biblioteki wprowadza sporo nowości i dzisiaj pokrótce się im przyjrzymy.
Największą nowością w Gatsby 5 jest Slices API, które za zadanie ma znacznie przyspieszyć Incremental Builds. Slice to komponent, który wykorzystywany jest przez wiele podstron, ale jego modyfikacja nie będzie wymagać ponownego zbudowania tychże stron. Delikatnie upraszczając sprawę, Slice to komponent który przechowywany jest na serwerze jako markup, jego modyfikacja automatycznie propaguje się wszędzie tam gdzie jest używany i nie wymaga do tego przebudowania całego projektu. Jak podają twórcy, takie zachowanie w niektórych przypadkach może przyspieszyć budowanie nawet o 90%.
W zeszłym tygodniu pisaliśmy o tym, że Hydrogen porzuca na razie React Server Components. Wygląda na to, że React znalazł już innych sprzymierzeńców na jego miejsce. Gatsby 5 będzie wspierał proces częściowej hydracji wykorzystując właśnie React Server Components.
Podobnie jak w Next.js 13, w Gatsby wszystkie komponenty domyślnie staną się React Server Components. Dzięki temu Gatsby nie będzie wysyłał do klienta prawie żadnego kodu JavaScript, dopóki nie zaczniemy wprost definiować Client Components.
Na tym nowości w Gatsby 5 się nie kończą. Nowy Script Component umożliwia spersonalizowanie sposobu pobierania poszczególnych fragmentów kodu JavaScript. Nowe Head API jest alternatywą dla popularnego `react-helmet` i pozwala w wygodny sposób manipulować metadanymi poszczególnych stron tak, aby optymalizować wyniki SEO. Na zakończenie warto jeszcze wspomnieć, że Gatsby 5 to też paczka sporych optymalizacji. Jeśli wierzyć twórcom budowanie powinno przyśpieszyć co najmniej 10 krotnie, a w niektórych przypadkach nawet 1000 krotnie.
Źródła
https://www.gatsbyjs.com/blog/gatsby-5/
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Rome v10
Nie od razu Rzym zbudowano i nie od razu Rome zaimplementowano. Po niespełna dwóch latach światło dzienne wreszcie ujrzała pierwsza stabilna wersja Rome (nie pytajcie dlaczego jest to wersja 10). Jeśli historii Rome nie śledzicie na bieżąco, to trochę ostudzę Wasz entuzjazm. Z oryginalnych obietnic narzędzia zastępującego Babela, ESLinta, webpacka, Prettiera i Jest’a na razie otrzymaliśmy tylko solidną alternatywę dla ESLint i Prettiera.
Jeśli do tej pory o Rome nie słyszeliście, to postaram się w telegraficznym skrócie przybliżyć historię projektu. Głównym deweloperem odpowiedzialnym za jego rozwój jest Sebastian McKenzie, czyli współtwórca Babela, Yarna oraz Lerny. Cel projektu jest jasny – zunifikować i usprawnić narzędzia z których na co dzień korzystają programiści JavaScript. Biorąc pod uwagę osobę stojącą za projektem oraz przyświecający mu cel, nic dziwnego, że nadzieje JavaScript-owej społeczności są spore.
Prace nad Rome rozpoczynają się początkiem 2020 roku. Sam McKenzie przechodzi najpierw z Facebooka do Discorda, aby następnie otworzyć własną firmę Rome Inc. Startup w pierwszej rundzie finansowania gromadzi 4.5 miliona dolarów – całkiem pokaźna suma jak na budowę narzędzia dla deweloperów.
W tak zwanym międzyczasie popularności zaczynają zyskiwać narzędzia takie jak esbuild czy swc, napisane w niskopoziomowych językach. Rome napisany w TypeScript pod względem wydajności zaczyna odstawać od konkurencji. Dlatego też jesienią 2021 roku podjęta zostaje drastyczna decyzja – Rome zostanie przepisany na Rusta.
W ten oto sposób docieramy do dnia dzisiejszego, kiedy zobaczyć możemy pierwsze efekty projektu Rome. Nowy linter jest znacznie szybszy od ESLint i oferuje lepsze narzędzia diagnostyczne. Czy to wystarczy, aby skłonić deweloperów do przesiadki? Czas pokaże, ale moim zdaniem na ten moment argumentów jest jeszcze zbyt mało. Z niecierpliwością czekam, za jakie funkcjonalności zabierze się teraz zespół i jakie synergie między tworzonymi narzędziami uda im się uzyskać.
Źródła
https://rome.tools/blog/2022/11/08/rome-10/
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Ionic łączy siły z outsystems
Ionic to kolejna firma w naszym dzisiejszym przeglądzie, która zdecydowała się zbudować biznes wokół otwartoźródłowej biblioteki. Ionic zaczynał jako framework do budowania mobilnych aplikacji oparty o anguraj.js i Cordovę. Na przestrzeni lat sporo się jednak zmieniło. Dzisiaj Ionic jest niezależną od frameworku biblioteką komponentów i nie jest jedynym narzędziem rozwijanym przez firmę. Nadmienić należy chociażby Stencila, czyli abstrakcję nad API Web Components, czy Capacitora, czyli mentalnego następcę Cordovy.
W minionym tygodniu internet obiegła informacja o przejęciu Ionica przez firmę OutSystems. Firma ta od 2001 roku zajmuje się budowaniem narzędzi low-code. Jeśli zastanawiacie się skąd oni na to wszystko wzięli pieniądze, to już śpieszę z odpowiedzią. Na przestrzeni lat firmie udało się zgromadzić w 7 rundach finansowania ponad 500 milionów dolarów. Niestety kwota przejęcia nie jest publicznie dostępna.
Jak twierdzą przedstawiciele obydwu firm, z perspektywy użytkowników niewiele się zmieni. Ionic jak i inne biblioteki utrzymywane przez firmę nie zmienią licencji i nadal będą rozwijane. Więcej na temat wspólnej wizji dowiemy się na Ionic Show, który będzie mieć miejsce początkiem grudnia.
Ionic to jeden z tych projektów, do których mam ogromny sentyment. Vived nie korzystamy bezpośrednio z biblioteki komponentów Ionic, ale wykorzystujemy całkiem sporo niskopoziomowych API udostępnianych przez bibliotekę (Ionic Router, Ionic Animations czy Ionic Geasturess). Mobilna aplikacja początkowo oparta była o Cordovę, ale niedługo po zaprezentowaniu Capacitora, wiedzieliśmy, że jest to dla nas idealne rozwiązanie. Od początku mojej pracy w Vived regularnie mam do czynienia z bibliotekami spod skrzydeł Ionica i dlatego bardzo cieszy mnie, że firma dostanie teraz świeżego wiatru w żagle.
Źródła
https://ionic.io/blog/ionic-outsystems-the-future-of-enterprise-app-development
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
