SvelteKit, łamanie własnych zasad i pojedynek z samym sobą

Ostatnio dzieliłem się swoimi wrażeniami z Tauri, w którym rozwijam aplikację desktopową. Do przygotowania interfejsu wybrałem SvelteKit, meta-framework, który ma niecałe 4 miesiące (premiera 12.2022). Tym samym złamałem większość zasad, które opisywałem mówiąc o mądrym wyborze stacku technologicznego. Na myśl nasuwa się obrazek poniżej. Ale czy na pewno?

Eksploracja możliwości

Teoretycznie mogłem skorzystać z bardziej znanego mi ekosystemu Vue i gładko przejść przez cały projekt. W tym jednak nie byłoby zabawy. Tym bardziej, że nie zawsze mamy możliwość tak swobodnego podejmowania decyzji o wyborze stacku. W dodatku po ukończeniu projektu, przy założeniu, że wszystko pójdzie w porządku, będę mógł sięgać po SvelteKit również w przypadku większych aplikacji. I to jest właśnie jeden z ciekawszych elementów rozwijania projektów na własne potrzeby.

Takie podejście świetnie rozwinęła we mnie książka: Think Like a Rocket Scientist, którą zawsze bardzo chętnie polecam. Pozornie oczywiste jest, że nasze nastawienie wobec niepewności jest kluczowe w kontekście odkrywania nowych możliwości. Przykładowo sięganie po narzędzia, których nie znamy dość dobrze, wzbudza mnóstwo wątpliwości i dyskomfortu. Jednocześnie wystawia nas na odkrywanie obszarów, z którymi do tej pory nie mieliśmy do czynienia. W tej książce pojawia się jeszcze jeden, mniej oczywisty wniosek, mówiący o tym, że produktywność jest wrogiem oryginalnych myśli. Inaczej mówiąc, poruszając się w doskonale Ci znanym otoczeniu, trudno jest trafić na niespotykane dotąd rozwiązanie.
Muszę jednak podkreślić, że sam Svelte nie był mi całkowicie obcy, ponieważ realizowałem w nim jeden z wcześniejszych projektów. Jednak połączenie Tauri, SvelteKit i Rust nie było już takie oczywiste. Piszę o tym dlatego, że całkowite wychodzenie poza swoje aktualne możliwości, mogłoby łatwo prowadzić do frustracji. Poniższy wykres przedstawia stan "flow". Jednak skuteczna nauka wymaga wychodzenia lekko poza granice swojego komfortu i poruszanie się na granicy tego, co już znasz i tego, czego chcesz się nauczyć.

(Źródło)

Powyższa myśl nie pochodzi bezpośrednio ode mnie, lecz opiera się o słowa Dr Andrew Hubermana. Mówi on o trzech niezbędnych elementach procesu nauki, w skład w których wchodzą: pobudzenie, skupienie, powtórzenia, popełnianie błędów i odpoczynek.

Mam nadzieję, że tak zarysowany kontekst jest dla Ciebie wartościowy. Przejdźmy więc teraz do konkretów.

Zatarta granica pomiędzy warstwami

React, Svelte czy Vue same w sobie działają wyłącznie po stronie front-endu. W przypadku meta-frameworków, mamy do czynienia z połączeniem tych dwóch warstw. Daje to ogromną wygodę oraz elastyczność, ale jednocześnie zwiększa barierę wejścia, szczególnie dla osób nieposiadających "full-stackowego" doświadczenia. Konieczna staje się wiedza na temat koncepcji backendowych (np. routing czy middleware/sequence) oraz sposobach renderowania widoków (ssr/csr/ssg). Granica pomiędzy nimi jest bardzo cienka i niewystarczająca wiedza na ich temat, może prowadzić do trudnych do wykrycia błędów.

To wszystko sugeruje, że idealna ścieżka rozwoju w kierunku meta-frameworków powinna uwzględniać:

• solidne poznanie fundamentów JavaScriptu
• poznanie ekosystemu i toolingu (pnpm, vite itd.)
• przynajmniej zorientowanie się w node.js
• swobodne poruszanie się w Svelte
• i dopiero później, wejście w SvelteKit

Problem w tym, że SvelteKit rozwiązując wiele problemów za nas, wprost zniechęca do wyboru dłuższej drogi. Jeżeli jednak weźmiemy pod uwagę to, ile czasu potrzebujemy na odkrywanie tych zagadnień od końca, to tylko pozornie będzie to wymagać od nas mniej wysiłku.

Przykładowo poniższa struktura katalogów, odpowiada ścieżce /snippets/[slug], gdzie [slug] to dynamiczna wartość. Na pierwszy rzut oka, nie ma w tym nic złożonego. Jeżeli jednak uwzględnimy konieczność dodania np. uwierzytelnienia, to sytuacja zaczyna się komplikować.

Poniższe podejście w praktyce sprawdza się dość dobrze, ale ma swoje wady. Przykładowo utrudnia nawigacje po plikach projektu, bo każdy ma dokładnie taką samą nazwę.

Takie problemy są jednak stosunkowo niewinne, w porównaniu do przykładu omówionego w dokumentacji na temat zarządzania stanem po stronie klienta i serwera. Brak wystarczającej wiedzy na ten temat może doprowadzić do błędów w działaniu aplikacji, a nawet do ujawnienia danych użytkowników. Oczywiście to nie jest tak, że takie sytuacje nie mogą zdarzyć się w innych frameworkach. Jednak tutaj jest to szczególnie proste.

Przykładem mniejszego problemu z którym miałem do czynienia, jest sposób renderowania dynamicznych stron. Faktycznie powstał on w wyniku mojego błędu, jednak dowiedziałem się o nim dopiero na etapie budowania produkcji. W trakcie developmentu wszystko działało perfekcyjnie. Nie muszę chyba podkreślać, że w efekcie miałem sporo dodatkowej pracy.
Pozostałe funkcje, które wykorzystywałem przy tworzeniu aplikacji desktopowej, działały wręcz zaskakująco dobrze. Trzeba jednak przyznać, że to dość prosta aplikacja, wykorzystująca kilka widoków, ustawień, bazę danych i zapytania do zewnętrznego API. W związku z tym zarządzanie stanem z pomocą kontekstu i store sprawdziło się doskonale.

Integracja z TypeScriptem również stoi na bardzo dobrym poziomie. Jednak momentami widać jeszcze dość wczesny etap rozwoju Svelte. Spotkałem się z brakami po stronie IDE (IntelliJ), w wyniku których nie mogłem skorzystać z niesamowicie wygodnego zapisu $lib i każdy z importów musiałem poprawiać ręcznie.

Szybkie, zabawne, elastyczne doświadczenie

Na stronie SvelteKit padają trzy słowa opisujące doświadczenie towarzyszące korzystaniu z tego narzędzia: Szybkie, Zabawne, Elastyczne. Po kilku tygodniach pracy mogę powiedzieć, że nie są to puste hasła i nie wiem, czy byłbym w stanie opisać to lepiej. Nawet, teraz gdy przygotowując ten wpis, przeglądałem kod mojej aplikacji, odnosiłem wrażenie, jakby wszystko było "na swoim miejscu". Biorąc pod uwagę jej funkcje, kod źródłowy wydaje się wręcz banalnie prosty. Jednak dla osób, dla których koncepcje backendowe są obce, dodałbym jeszcze jedno słowo:
"Trudne".

Trzeba zwrócić uwagę na fakt, że ogólna struktura aplikacji, komunikacja pomiędzy komponentami i wczytywanie dynamicznych danych, działają wprost fenomenalnie. Rozwijając kolejne elementy aplikacji, miałem poczucie jakby wszystko "samo" wskakiwało na swoje miejsce. Z jednej strony Svelte narzuca na nas pewne konwencje. Z drugiej nie są one na tyle sztywne, aby jakkolwiek nas ograniczać.

Zdecydowanie odradziłbym korzystanie z SvelteKit (czy w ogóle meta-frameworków) osobom, które nie mają wystarczającego doświadczenia z podstawową wersją frameworków. Oczywiście nie jest to wymagane, ale po prostu wskazane.

Bardzo polecam nawet chwilową interakcję ze SvelteKit. Instalacja i konfiguracja projektu sprowadza się do przejścia przez kilka kroków. Doświadczenie możliwości jakie oferuje ten framework, jest na tyle godne uwagi, że dla każdego mniejszego i średniego projektu, w najbliższym czasie moim wyborem numer 1, będzie SvelteKit. Warto jednak pamiętać, że w międzyczasie na rynku pojawiło się sporo ciekawych alternatyw. Na szczególną uwagę zasługuje Astro.

Trzy mało znane technologie i pojedynek z samym sobą

Nietrudno zauważyć, że od kilku miesięcy GPT-3 i ChatGPT są częścią mojej codzienności. Nie inaczej było tym razem. Gdy na początku tego wpisu mówiłem o poruszaniu się "na granicy swoich możliwości", to jeszcze kilka miesięcy temu miałbym na myśli delikatne wychodzenie poza obszar swoich kompetencji. Doświadczenie tworzenia aplikacji desktopowej w trzech mało znanych narzędziach przypominało bardziej skok na głęboką wodę.

Przykład rozwijanego przeze mnie projektu pokazał mi, że gdybym rzucił pojedynek samemu sobie, to bez cienia wątpliwości przegrałbym z wersją, która byłaby wspierana przez AI. Nie mam jednak na myśli sytuacji w której GPT-3 pomogło mi zrobić coś, co jest poza moim intelektualnym zasięgiem. Bardziej drastycznie przyspieszyło to, co w pojedynkę zajęłoby mi dni czy nawet tygodnie. W praktyce, mój side-project w ogóle mógłby nie być zrealizowany, bo zabrakłoby mi czasu na jego rozwój.

Jedna z funkcji mojej aplikacji uwzględnia możliwość przypisania skrótu klawiszowego. Zatem po aktywowaniu pola tekstowego chciałem, aby pojawiły się w nim klawisze funkcyjne oraz przyciski alfanumeryczne. Podjąłem próbę napisania takiej funkcji samodzielnie i choć udało mi się stworzyć podstawową mechanikę dość szybko, trudności pojawiły się przy detalach. Zaprosiłem więc do współpracy ChatGPT:

Kilka minut później wspólnie doszliśmy do rozwiązania widocznego poniżej. I choć sam kod potrzebuje jeszcze refaktoryzacji, na ten moment mam efekt o który mi chodziło. Opracowanie takiej funkcji nie jest wybitnie trudne. Jednak w moim przypadku na jej przygotowanie od podstaw, potrzebowałbym zapewne przynajmniej kilkadziesiąt minut.

W podobny sposób rozwiązywałem problemy dotyczące konfiguracji Tauri oraz możliwości, jakie oferuje o których nie wiedziałem. ChatGPT momentami zwracał nieaktualne przykłady, jednak skutecznie naprowadzał mnie na dostępne rozwiązania. Świetnie też radził sobie z wprowadzaniem sugerowanych przeze mnie zmian, choć niejednokrotnie musiałem resetować całą rozmowę, aby wyjść ze schematów, które starał się stosować.
W związku z tym, że frameworki front-endowe są momentami do siebie bardzo zbliżone, kluczowe okazuje się nadanie persony, na początku rozmowy.

W miejsce [JavaScript] możemy wpisać nazwę frameworka lub technologii o której chcemy rozmawiać. W ten sposób podawane przykłady będą znacznie bardziej dopasowane do naszych potrzeb. Nie rozwiąże to jednak problemu dotyczącego faktu, że ChatGPT pracuje na danych do 2021 roku. Premiera SvelteKit miała miejsce 4 miesiące temu. Aby upewnić się, że otrzymamy poprawne wyniki, możemy wkleić fragmenty dokumentacji, aby doprecyzować kontekst naszej rozmowy. Tak samo dobrze sprawdza się to w pracy z nowymi wersjami API czy innymi zestawami aktualnych danych.
Powyższym przykładem, chciałem tylko pokazać, że wykorzystanie GPT-3 na potrzeby nauki ma dużo sensu. Nie możemy jednak stawiać nierealnych oczekiwań i niejednokrotnie będziemy zderzać się ze ścianą. Pomimo ograniczeń aktualnego etapu rozwoju tych narzędzi, można czerpać z nich wiele wartości.

Odnalezienie się w nowych frameworkach

Już na etapie w którym królował React/Vue/Angular, odnalezienie się w dostępnych na rynku frameworkach i bibliotekach nie było proste. Do tego dochodzą frameworki back-endowe i rozwiązania all-in-one / meta-frameworki. Nasuwa się więc pytanie o skuteczność w poruszaniu się po tak bogatej palecie rozwiązań.
Chociaż powyższy przykład wykorzystania ChatGPT do szybkiego poruszania się w nowym środowisku i eksploracji możliwości, jest dobry, to nie jest wystarczający. Nadal nie jesteśmy na etapie w którym AI generuje kompletny kod za nas. Trudno powiedzieć, ile czasu potrzebujemy, aby dojść do takiego poziomu.
W moim przypadku największą różnicę odgrywa docieranie do źródeł i głębokie rozumienie narzędzi z którymi pracujemy. Mam na myśli zrozumienie samego JavaScriptu, toolingu, frameworków i na końcu meta-frameworków. Gdy będziesz budować swoje umiejętności w ten sposób, znacznie łatwiej przyjdzie Ci odnalezienie się w różnych narzędziach i środowiskach. Każde z nich jest niczym innym jak próbą rozwiązania konkretnych problemów i każde z nich współdzieli pewne wzorce i dodaje własne. Obecność SvelteKit i podobnych frameworków, jeszcze bardziej podkreśla to zjawisko.
Na koniec podkreślam, że powyższa ścieżka z pewnością nie jest jedyną słuszną i warto odnaleźć sposoby, które będą indywidualnie dopasowane do nas, naszych potrzeb, możliwości i planu na swoją karierę.