Preskočiť na hlavný obsah

Frontendové zvesti #6

· Čítanie na 7 min

React Server Components sú náročné na premýšľanie. Framework TanStack Start dosiahol verziu 1.0. Majú dnes frameworky ešte zmysel? Budúcnosť Deno. Útoky na NPM ekosystém nekončia. Hackovanie webmailových klientov pomocou CSS. Bootstrap je späť.

React Server Components sú náročné na premýšľanie​

Nie je to tak dávno, čo som si myslel, že RSC sú budúcnosť a je len otázkou času, kedy ich implementujú všetky meta frameworky založené na React-e. Avšak čím dlhšie ich používam, tým menej som nadšený. Hoci mi samotné rozdelenie na serverové a klientské komponenty stále dáva zmysel, tak sa pomerne často ocitám v situácii, kedy potrebujem vedieť, či sa niektorý komponent rendruje na serveri alebo na klientovi. A pokiaľ tento v sebe nemá direktívu use client, tak to znamená pátranie po celom rendrovacom strome.

Ešte väčšie komplikácie spôsobujú serverové funkcie (use server). Keď ich použijete v kóde, tak to navonok vyzerá ako bežné volanie funkcie. V skutočnosti sa tam ale deje odoslanie regulérneho http requestu z browseru na server. Pokiaľ si tohto programátor nie je vedomý, tak to môže byť vcelku nebezpečné.

Postupne si tak stále viac začínam myslieť, že kým RSC mali riešiť správny problém (priveľa JS v browseri), tak poskrývali priveľa dôležitých vecí za navonok dobré DX (Developer eXperience).

Lenže dobré DX by sa nemalo robiť tak, že vývojárom skryjeme infraštruktúrne a/alebo architektonické hranice do takej miery, že je veľmi jednoduché sa stratiť alebo urobiť chybu.

Som veľmi rád, že nie som jediný, komu toto prekáža. Nedávno som dočítal článok od Valentina Prognauda presne na túto tému. Celá myšlienka článku sa točí okolo toho, že je ťažké je premýšľať o systéme, pokiaľ hranice medzi jeho časťami nie sú dobre viditeľné. Valentin dokonca naprogramoval nástroj nazvaný RSC Boundary, čo je akýsi vývojársky panel do React aplikácie, ktorým si vieme nechať zobraziť, ktoré vykreslené komponenty sú serverové a ktoré klientské.

TanStack Start vo verzii 1.0​

Tanner Linsley na blogu oznámil vydanie React-ového frameworku TanStack Start vo verzii 1.0. Oznámenie podľa mňa stojí za prečítanie, pretože Tanner veľmi pekne rozoberá, prečo sa rozhodol vytvoriť nový framework, čo bolo na začiatku (Router s typovou kontrolou), a ako chcel postaviť framework, ktorý dá ľuďom slobodu výberu štýlu stavania aplikácie.

Ešte som nemal príležitosť si tento framework vyskúšať, ale myslím, že ak sa budem v blízkej dobe rozhodovať pre pouzitie nejakého frameworku, tak TanStack Start bude veľmi vážny kandidát.

Tanner v blogu píše aj o tom, že investovali veľa času a energie do podpory RSC a nepáčilo sa im, že React ich tlačil do určitého spôsobu implementácie. Nakoniec sa rozhodli neprispôsobiť sa a majú tak iný model použitia RSC, než napríklad Next.js, s ktorým sú síce spokojnejší, ale RSC zjavne nie je ich obľúbená časť frameworku. Majú voči tomu ešte viac výhrad, než som spomínal o pár odstavcoch vyššie.

Majú dnes ešte frameworky zmysel?​

Brooks Lybrand (Remix devrel) napísal článok, kde sa snaží zamýšľať nad tým, či majú frontendové frameworky v dnešnej dobe AI ešte zmysel. Rôzni ľudia majú na toto rôzne názory a tak sa snaží dopátrať k vlastnej odpovedi na túto otázku a niektoré ďalšie.

Niektoré z otázok, na ktoré hľadá odpovede:

  • má zmysel iný frontend framework ako React, keď k Reactu mali AI modely dostatok trénovacích dát?
  • nebolo by lepšie použiť jQuery, ku ktorému muselo byť ešte viac trénovacích dát?
  • nie je toto zrovna doba, kedy by sme mali všetci prejsť na používanie Web Components?
  • keď mi AI agent vie na počkanie vytvoriť nový framework presne pre moje potreby, má zmysel siahnúť po existujúcom?
  • a má dnes zmysel investovať čas do tvorby nových frameworkov?

Autor dospel k odpovedi, že používanie frameworky ešte stále zmysel dáva. Pretože nám poskytujú abstrakcie, štruktúru a kostru, podľa ktorých staviame aplikácie. Všetko toto je rovnako užitočné pre človeka, ako aj pre AI agenta.

Čo sa týka otázky okolo zmyslu tvorby nových frameworkov, tak odpoveď je zlozitejšia. Súhlasím s autorom, že keď prestaneme tvoriť nové veci, lebo si myslíme, že všetky problémy sú už vyriešené, tak sme v smutnom bode dejín. V skutočnosti je toho ešte veľa, čo sme okolo frameworkov ešte nevyriešili a k čomu treba stále hľadat odpoveď.

Aká je budúcnosť Deno?​

Ryan Dahl, ktorý kedysi vymyslel Node.js a posledné roky pracuje na novom JavaScript-ovom runtime nazvanom Deno, oznámil, že celý vývojový tím prechádza do Cloudflare.

Za normálnych okolnosti by to bola by to správa, ako každá iná, kde nejaký projekt oznamuje zmenu materskej firmy alebo sponzora. Ibaže v tejto Ryan priamo oznamuje, že celý tím sa bude venovať práci na Durable Objects a prestanú vyvíjať Deno runtime.

Deno runtime tak má pred sebou ešte jeden rok vývoja s mesačnými releasmi a bezpečnostnými updatami, ale potom na ňom prestávajú pracovať. Ak niekto chce, tak Deno je stále open-source pod MIT licenciou, takže môže prebrať jeho vývoj.

Ak ste náhodou používali Deno Deploy, tak máte pred sebou ešte pol roka fungovania.

Čo sa týka dôvodov, tak samotný Ryan Dahl sa vyjadril, že hoci je Deno dobrý runtime, tak Node.js funguje a vlastne nie je dôvod ho vymieňať. A kto sleduje dianie, tak už dlhšie mohol pozorovať, že Deno akosi prestal prinášať inovácie už dávnejšie.

Ja som Deno nepoužíval, ale som z toho mierne rozčarovaný. Páčilo sa mi, ako Deno dbá na bezpečnosť a stále čakám, kedy rovnaké defaultné správanie dostaneme v Node.js.

Pokus o kompromitovanie knižnice Zod​

V Hacker News diskusii si môžeme prečítať, ako sa knižnica Zod vyhla pokusu o kompromitovanie. AI agent v sandbox prostredí spustil skript z infikovaného NPM balíka, ktorý sa následne dostal k SSH kľúču. Útočníkom sa pomocou neho podarilo commitnúť kompromitovaný kód do Github repozitára pre Zod, ale opatrenia na úrovni CI a v jednom prípade aj na úrovni NPM zabránili tomu, aby bol priamo na NPM publikovaný infikovaný balík.

Aj na tomto prípade vidieť, že nové opatrenia, ktoré sa implementovali posledné mesiace na mnohých úrovniach majú naozaj zmysel. Situácia v ekosystéme nie je vôbec bezpečná a tak skoro ani nebude.

Ako hacknúť webového mailového klienta pomocou CSS?​

Kým som nezačal čítať tento článok, tak som si myslel, že som v relatívnom bezpečí, keď si pozerám emaily vo webovej verzii Outlook-u. Teraz uz viem, že nie. A viem aj to, že útočníkovi stačí obyčajné CSS na to, aby si vedel prečítať, čo potrebuje. úplne mi odpálilo dekel 🤯.

Pokiaľ niekde používate webového klienta na čítanie mailov (Gmail, Outlook, Yahoo, Fastmail, čokoľvek), tak by vás toto tiež mohlo zaujímať.

Priznám sa, že článok som stále nedočítal. Je tam toho veľmi veľa a moje znalosti CSS nie sú veľké, takže občas potrebujem odbehnúť pozrieť dokumentáciu 😅. Autor si je vedomý toho, že to nemusí byť ľahké čítanie, takže k článku prilozil aj obrázky a dokonca videá.

Bootstrap je späť​

Pár dní dozadu bolo oznámené, že chystá nová verzia CSS frameworku Bootstrap. Bude to verzia číslo 6, už je k dispozícii v alfa stave a dokonca stránka s oficiálnou dokumentáciou už predvolene ukazuje túto verziu.

Bootstrap za svojich čias spôsobil revolúciu a používal sa takmer všade. Medzičasom sa web a aj CSS samotné posunuli ďalej a Bootstrap zaostal. Ja som si popravde myslel, že už je to mŕtvy projekt a ďalšej veľkej verzie sa už nedočkáme. O to väčšie bolo moje prekvapenie, keď som narazil na ich oznámenie.

Uvidíme, aký ohlas a prípadný úspech to bude mať. Z toho, čo som zatiaľ pochopil, tak stále vo veľkej miere vsádzajú na flexbox a ja by som v dnešnej dobe očakával skôr grid. Ale ako som už spomínal vyššie, CSS nie je moja silná stránka, takže tomu možno len nerozumiem a flexbox je v skutočnosti dobrá voľba.