<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href="/rss/pretty-feed.xsl" type="text/xsl"?><rss version="2.0"><channel><title>Adrian Zawadzki - Blog</title><description>Notatki, posty i przemyślenia o web developmencie.</description><link>https://adrianzawadzki.dev/</link><language>pl-pl</language><item><title>Złudzenie zrozumienia: dlaczego dopiero pisanie pokazuje, co naprawdę wiesz</title><link>https://adrianzawadzki.dev/pl/blog/writing-to-understand/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/writing-to-understand/</guid><description>Czujesz, że rozumiesz closure - dopóki nie usiądziesz, żeby wytłumaczyć go krok po kroku. Wtedy pojawia się dziura. Psychologia poznawcza nazwała to złudzeniem głębi wyjaśnienia: nasze poczucie wiedzy jest systematycznie zawyżone, a widać to dopiero, gdy trzeba odtworzyć mechanizm. O tym, czemu pisanie - a najlepiej zbudowanie działającego dema - jest najlepszym sprawdzianem tego, co naprawdę wiesz.</description><pubDate>Sun, 28 Jun 2026 10:00:00 GMT</pubDate><category>thoughts-and-learning</category><category>learning</category><category>writing</category><category>habits</category></item><item><title>Big-O bez matematyki: ile naprawdę kosztuje twój kod</title><link>https://adrianzawadzki.dev/pl/blog/big-o/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/big-o/</guid><description>Twój kod działa idealnie na dziesięciu elementach i zacina się na dziesięciu tysiącach - mimo że ani jedna linijka się nie zmieniła. Big-O nie mówi „jak szybko”, tylko „jak koszt rośnie, gdy rośnie ilość danych”. O tym, jak rozpoznać kształt tego wzrostu w zwykłym kodzie frontendowym - i jak zamienić pętlę w pętli na coś, co nie zwalnia przy dużej ilości danych.</description><pubDate>Sat, 27 Jun 2026 10:00:00 GMT</pubDate><category>algorithms</category><category>big-o</category><category>complexity</category><category>data-structures</category><category>performance</category></item><item><title>Dlaczego dobre decyzje techniczne przegrywają z biznesem</title><link>https://adrianzawadzki.dev/pl/blog/engineering-decisions/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/engineering-decisions/</guid><description>Najlepsza technicznie decyzja może przegrać, bo przedstawiono ją w niewłaściwy sposób. Biznes nie kupuje „czystego kodu” - kupuje koszt, ryzyko i czas. O tym, jak przełożyć refactor, tech debt i „good enough” na te trzy miary - i kiedy „nie” jest właściwą odpowiedzią.</description><pubDate>Fri, 26 Jun 2026 10:00:00 GMT</pubDate><category>career-and-business</category><category>tech-debt</category><category>trade-offs</category><category>decision-making</category><category>communication</category><category>leadership</category></item><item><title>Jak odpowiedź pisze się słowo po słowie: streaming po HTTP</title><link>https://adrianzawadzki.dev/pl/blog/streaming-over-http/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/streaming-over-http/</guid><description>Odpowiedź AI pojawia się stopniowo nie przez efekt wizualny, tylko przez streaming: ciało odpowiedzi HTTP jest strumieniem, więc serwer może odsyłać je kawałkami, a przeglądarka pokazywać każdy od razu. Na froncie czyta się to na dwa sposoby - prościutkim `EventSource` (SSE) albo elastycznym `fetch` ze strumieniem - i dokładnie tego drugiego używają pod spodem biblioteki do LLM-ów.</description><pubDate>Thu, 25 Jun 2026 10:00:00 GMT</pubDate><category>ai-in-development</category><category>streaming</category><category>sse</category><category>fetch</category><category>http</category><category>ai</category></item><item><title>Gdzie żyje cache: ile kopii jednej odpowiedzi istnieje naraz</title><link>https://adrianzawadzki.dev/pl/blog/where-cache-lives/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/where-cache-lives/</guid><description>Ta sama odpowiedź serwera może w jednej chwili leżeć w kilku cache&apos;ach naraz - pamięci aplikacji, Service Workerze, cache HTTP, na CDN - a całą stronę trzyma jeszcze bfcache. Każdy ma innego właściciela i co innego go czyści, więc „wyczyść cache&quot; trafia w jeden z nich, czasem w żaden. Zostaje pytanie, od którego zaczyna się każde takie debugowanie: która warstwa trzyma starą kopię i co ją unieważnia.</description><pubDate>Sun, 31 May 2026 10:00:00 GMT</pubDate><category>performance-and-accessibility</category><category>caching</category><category>cdn</category><category>bfcache</category><category>service-worker</category><category>performance</category></item><item><title>Service Worker - kod, który odpowiada zamiast serwera</title><link>https://adrianzawadzki.dev/pl/blog/service-worker-cache-api/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/service-worker-cache-api/</guid><description>Wyłącz internet, odśwież stronę - a ona dalej działa. Stoi za tym Service Worker: osobny skrypt, który wchodzi między stronę a sieć i przechwytuje każde żądanie o plik, zanim trafi ono do serwera. To on decyduje, czy odpowiedzieć z sieci, z własnego cache (`Cache API`), czy po swojemu - a z tej jednej decyzji biorą się wszystkie strategie cache&apos;owania, tryb offline i klasyczna pułapka &apos;po wdrożeniu user widzi starą wersję&apos;.</description><pubDate>Sat, 30 May 2026 10:00:00 GMT</pubDate><category>performance-and-accessibility</category><category>service-worker</category><category>cache-api</category><category>offline</category><category>pwa</category><category>caching</category></item><item><title>HTTP caching: czemu druga wizyta na stronie jest natychmiastowa</title><link>https://adrianzawadzki.dev/pl/blog/http-caching/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/http-caching/</guid><description>Weź jeden plik `style.css` i prześledź jego dzień na działającej stronie: najpierw pobiera go przeglądarka, potem serwuje go z pamięci bez pytania serwera, później pyta serwer, czy jej kopia jest nadal aktualna, i zwykle dostaje samo potwierdzenie zamiast całego pliku, a po wdrożeniu nowej wersji pobiera go od nowa. Z tej jednej historii wychodzi cały HTTP caching - `Cache-Control`, `ETag`, `304` i `stale-while-revalidate`.</description><pubDate>Fri, 29 May 2026 10:00:00 GMT</pubDate><category>performance-and-accessibility</category><category>http</category><category>caching</category><category>cache-control</category><category>etag</category><category>performance</category></item><item><title>SSR, SSG, ISR, CSR - kiedy powstaje HTML i jakim kosztem</title><link>https://adrianzawadzki.dev/pl/blog/rendering-strategies/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/rendering-strategies/</guid><description>Cztery strategie renderowania nie są wyborem z menu, tylko decyzją per route: gdzie powstaje HTML i kiedy. Każda ma inny moment generacji, inny TTFB, inny koszt infrastruktury i inny stosunek &apos;świeże dane vs prędkość&apos;. Rozkładam mechanikę czterech podejść i pokazuję, kiedy które ma sens.</description><pubDate>Thu, 28 May 2026 10:00:00 GMT</pubDate><category>tools-and-workflow</category><category>rendering</category><category>ssr</category><category>ssg</category><category>isr</category><category>csr</category></item><item><title>Same-origin policy i CORS, czyli kto może czytać dane z innego serwera</title><link>https://adrianzawadzki.dev/pl/blog/same-origin-and-cors/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/same-origin-and-cors/</guid><description>Same-origin policy (SOP) w przeglądarce blokuje kod JavaScript z jednej strony przed czytaniem danych z innej domeny - chyba że serwer wprost pozwoli przez CORS. W poście opisuję, jak działa ten mechanizm zgody serwera i czemu czasem widzisz preflight OPTIONS, a czasem nie.</description><pubDate>Wed, 27 May 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>cors</category><category>security</category><category>fetch</category><category>same-origin</category><category>http</category></item><item><title>Od HTML do piksela: jak przeglądarka renderuje stronę</title><link>https://adrianzawadzki.dev/pl/blog/browser-rendering-pipeline/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/browser-rendering-pipeline/</guid><description>Każdy element DOM przechodzi przez pięć etapów, zanim go zobaczysz, niezależnie od frameworka. Niektóre style odpalają tylko ostatni etap, inne uruchamiają wszystkie pięć. Stąd różnica w kosztach animacji - od jednego etapu composite po pełny reflow.</description><pubDate>Tue, 26 May 2026 10:00:00 GMT</pubDate><category>performance-and-accessibility</category><category>performance</category><category>rendering</category><category>browser</category><category>dom</category><category>cssom</category></item><item><title>Garbage Collection w JavaScripcie - jak silnik sprząta po twoim kodzie</title><link>https://adrianzawadzki.dev/pl/blog/garbage-collection-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/garbage-collection-in-javascript/</guid><description>Każdy obiekt, który tworzysz w JS, zajmuje miejsce w pamięci komputera. JavaScript usuwa nieużywane obiekty automatycznie, robiąc miejsce na nowe. Silnik czasem jednak nie potrafi rozpoznać, że dany obiekt nie jest już potrzebny - i wtedy obiekt zostaje w pamięci. Tak powstają memory leaki. Post o mechanizmie tego sprzątania (mark-and-sweep), o najczęstszych pułapkach i o tym, kiedy faktycznie sięgać po `WeakMap` czy `WeakRef`.</description><pubDate>Thu, 07 May 2026 12:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>garbage-collection</category><category>memory</category><category>performance</category><category>podstawy</category></item><item><title>Event Loop w JavaScript - jak silnik decyduje, co odpalić następne</title><link>https://adrianzawadzki.dev/pl/blog/event-loop-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/event-loop-in-javascript/</guid><description>JavaScript ma jeden wątek, ale potrafi czekać na wiele rzeczy równocześnie. Sekret to event loop - prosty algorytm, który wybiera, co odpalić, gdy stack jest pusty. Microtaski wyprzedzają taski, render wpasowuje się między cyklami, a kolejność wykonania zaczyna mieć logiczny sens.</description><pubDate>Thu, 07 May 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>event-loop</category><category>async</category><category>microtasks</category><category>podstawy</category></item><item><title>Słowo kluczowe this w JavaScript - cztery reguły bindingu w jednym miejscu</title><link>https://adrianzawadzki.dev/pl/blog/this-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/this-in-javascript/</guid><description>`this` w JS zachowuje się dziwnie tylko dlatego, że ludzie patrzą nie tam, gdzie trzeba. Wartość `this` ustala się dopiero w momencie wywołania funkcji - są tylko cztery reguły, które to wywołanie może wybrać, plus arrow functions, które wyłamują się z całego systemu.</description><pubDate>Wed, 06 May 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>this-keyword</category><category>oop</category><category>podstawy</category></item><item><title>async/await w JavaScript - jak funkcja może czekać bez blokowania wątku</title><link>https://adrianzawadzki.dev/pl/blog/async-await-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/async-await-in-javascript/</guid><description>`async/await` wygląda jak magia: piszesz `await fetch(...)`, dostajesz wynik w kolejnej linijce, a wątek nie blokuje się ani na moment. Pod spodem nie ma magii - jest stary wzorzec generator + Promise + auto-runner, ukryty pod nowymi słowami `async` i `await`.</description><pubDate>Tue, 05 May 2026 14:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>async</category><category>await</category><category>promises</category><category>generators</category><category>podstawy</category></item><item><title>Generators w JavaScript - funkcja, która umie się zatrzymać</title><link>https://adrianzawadzki.dev/pl/blog/generators-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/generators-in-javascript/</guid><description>Zwykła funkcja w JS leci od góry do dołu, zwraca wynik i znika z pamięci. Generator jest inny - oznaczony `function*`, na każdym `yield` zatrzymuje swoje wykonanie, oddaje wartość i czeka na kolejne `.next()`. Mała zmiana w runtime, ale to ona stoi za sekwencjami liczonymi na żądanie i pod spodem `async/await`.</description><pubDate>Tue, 05 May 2026 11:50:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>generators</category><category>iterators</category><category>async</category><category>podstawy</category></item><item><title>Hoisting w JavaScript, czyli o czym tak naprawdę mówi ta metafora</title><link>https://adrianzawadzki.dev/pl/blog/hoisting-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/hoisting-in-javascript/</guid><description>Standardowe tłumaczenie hoistingu mówi, że deklaracje przesuwają się na górę kodu. [Specyfikacja ECMA-262](https://tc39.es/ecma262/ &quot;ECMA-262 - aktualna specyfikacja JavaScript&quot;) nie definiuje hoistingu jako mechanizmu, a `let` zachowuje się tak, jakby tej zasady nie znał. Co więc naprawdę dzieje się przed wykonaniem twojego kodu i dlaczego TDZ wygląda dokładnie tak, jak wygląda?</description><pubDate>Sun, 03 May 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>hoisting</category><category>scope</category><category>tdz</category><category>podstawy</category></item><item><title>Execution Context i Call Stack - jak JavaScript wykonuje twój kod</title><link>https://adrianzawadzki.dev/pl/blog/execution-context-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/execution-context-in-javascript/</guid><description>Każda linia JS musi gdzieś się wykonać, każda zmienna gdzieś żyć, każde wywołanie funkcji po sobie wrócić. Silnik trzyma to wszystko w dwóch strukturach - execution context (gdzie aktualnie jestem) i call stack (skąd przyszedłem). To one stoją za closure, this i asynchronicznością.</description><pubDate>Thu, 30 Apr 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>execution-context</category><category>call-stack</category><category>silnik</category><category>podstawy</category></item><item><title>new (i this) w JavaScript - co naprawdę robi to słowo kluczowe</title><link>https://adrianzawadzki.dev/pl/blog/new-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/new-in-javascript/</guid><description>Słowo new w JS wygląda na krótkie, ale silnik uruchamia za nim cztery kroki naraz - tworzy pusty obiekt, podpina this, linkuje go do prototype&apos;u funkcji i zwraca cały obiekt z powrotem. Bez new to samo trzeba napisać ręcznie z Object.create.</description><pubDate>Wed, 29 Apr 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>new-operator</category><category>this-keyword</category><category>prototype</category><category>oop</category><category>podstawy</category></item><item><title>Promises w JavaScript - od callback hell do microtask queue</title><link>https://adrianzawadzki.dev/pl/blog/promises-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/promises-in-javascript/</guid><description>Async w JS bez Promise to callback hell - kod nie ma jak odwoływać się do trwającej operacji, a obsługa błędów siedzi osobno w każdym callbacku. Promise to obietnica wartości, która przyjdzie później - kod układa się płasko, a błędy łapiesz w jednym miejscu.</description><pubDate>Tue, 28 Apr 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>promises</category><category>async</category><category>event-loop</category><category>podstawy</category></item><item><title>Closure w JavaScript, czyli jak funkcja może coś pamiętać</title><link>https://adrianzawadzki.dev/pl/blog/closure-in-javascript/</link><guid isPermaLink="true">https://adrianzawadzki.dev/pl/blog/closure-in-javascript/</guid><description>Funkcje w JS zwykle znikają ze swoją lokalną pamięcią. Closure łamie tę regułę - i to na niej opiera się module pattern, memoizacja, asynchroniczny JS i prywatny stan bez klas.</description><pubDate>Fri, 24 Apr 2026 10:00:00 GMT</pubDate><category>web-platform</category><category>javascript</category><category>closure</category><category>scope</category><category>podstawy</category></item></channel></rss>