Browser APIs
wpisy (17)
- Sposoby komunikacji z backendem: od formularza HTML do GraphQL3/6
Fetch API: współczesny interfejs do HTTP w przeglądarce
fetch nie zmienił modelu komunikacji, tylko interfejs. Request i Response są obiektami, body jest strumieniem, a 404 nie jest błędem.
- Sposoby komunikacji z backendem: od formularza HTML do GraphQL2/6
AJAX: kiedy request przestał oznaczać przeładowanie strony
XHR nie zmienił protokołu, tylko czytelnika odpowiedzi. Status, nagłówki i granica origin przestały być sprawą przeglądarki, a stały się sprawą aplikacji.
- Sposoby komunikacji z backendem: od formularza HTML do GraphQL1/6
HTML Forms: komunikacja z backendem bez JavaScriptu
Formularz nie jest helperem do API. Przeglądarka sama serializuje kontrolki, buduje request i traktuje odpowiedź jako nowy dokument.
- Frontend Rendering: od server-side pages do hybrydowego renderowania4/17
Koszt wysyłania aplikacji do browsera
Transfer size to pierwszy koszt, nie jedyny. Liczy się praca, którą urządzenie musi wykonać, zanim aplikacja stanie się użyteczna.
- Frontend Rendering: od server-side pages do hybrydowego renderowania3/17
SPA i CSR: kiedy browser przejął aplikację
Browser pobiera dokument raz i sam zarządza przejściami między ekranami. Frontend przestaje być warstwą prezentacji, a staje się długowiecznym runtime'em.
- Frontend Rendering: od server-side pages do hybrydowego renderowania2/17
AJAX: moment, w którym strona zaczęła zachowywać się jak aplikacja
Request przestał oznaczać nawigację. Browser utrzymuje aktualny dokument i sam decyduje, co zrobić z odpowiedzią serwera.
- Frontend Rendering: od server-side pages do hybrydowego renderowania1/17
Server-rendered web: zanim frontend stał się aplikacją
Serwer składał pełny dokument dla każdego requestu, a browser był rendererem dokumentów. Model prosty, dopóki jednostką aktualizacji mógł być cały dokument.