SULTHAN: OK, asi ctem jiny clanky, ja tam teda cet “React je pomalej kvuli IE kompatibilite a asi jde udelat rychlej, ale tady jsou data ok tomu te to skoro nikdo (zejmena pro mobily) nezvladne (i kdyz tvrdi opak, protoze to testuje ze svyho high endu), a benefity Reactu (jako to deklarativni UI) uz dneska muzete mit v XY jinejch pristupech co nemaj ten problem”.

YMMV, mam asi bias protoze poslednich ~10 let sem delal na trech velkejch produktech, vsechny tri maj React FE a ty problemy co popisuje maj vsechny.

SULTHAN: Rozumim ze to tak pusobi, nicmene pokud to nekoho zajima, doporucil bych mu cist dal. Autor neni proti SPA ani nekope za konkretni framework.

Jeho nazor se nevzal ve vzduchoprazdnu, ale na datech a trochu ho radikalizovala stagnace webu no :) Kdyby nahodou nekoho zajimala tahle cast, tak zacatek je tady

Reckoning: Part 1 — The Landscape - Infrequently Noted
https://infrequently.org/2024/08/the-landscape/

To teda vychazi z toho, ze delal mereni na rychlosti webu na prumernejch mobilech a pripojenich.

Vzhledem k tomu ze krom toho ze webari delal Alex primo na Chromu a na nejakejch WHATWG standardech, mam tendenci ho brat trochu vaznejc, nez normalni blogisek s nazorem.

ALMAD: Tam si stačí přečíst
In short, nobody should start a new project in the 2020s based on React. Full stop.
A víš, že je to zaujatý článek, který dál nemá smysl moc číst.

Na tema SPA flamu podle me pise vyjimecne dobre Alex Russel, a zrovna nedavno podle me i dobre definoval, kdy ma SPA smysl :)

If Not React, Then What? - Infrequently Noted
https://infrequently.org/2024/11/if-not-react-then-what/

JARDABEREZA: Upřímně, za cca 8 let, co dělám web frontendy jsme formulář nepoužili - a to jsem nedělal jen v Reactu. Ony ty formy moc nejdou dohromady s JSONama, co se teď používají prakticky v každém API.
A z DOM používám fakt malý subset jako jsou listenery, activeElement apod.
Jinak tohle je stejné nadávání jako že BE vývojáři už sami neumí ani navázat socket.

SULTHAN: Strilet do nohou se muzes cimkoliv, to je pravda, ale nevazany pouzivani useState a useEffect hooku je zas vyjimecne kvalitni footgun :-).

BESH: Střílet do nohou se můžeš čímkoliv. A dropdown není zas tak jednoduchá věc, zejména pokud má být responsive & accessible

JARDABEREZA: Tohle nebyla stiznost na React, ja sam na FE nic jineho nepouzivam uz leta a ani to nemam v planu. Spis takova pravidelna fascinace, jak se Reactem nekteri lidi umi brutalne strilet do nohou. Zamotavaji se do spleti state hooku, z kterych se pak vymotavaji effect hooky, vsechno silene prekombinovane a obcas mi z toho proste zustava rozum stat. U rozbalovaciho seznamu odkazu je to proste do oci bijici over-engineering. React je dobry sluha, ale moc zly pan.

PJOTRIK: Vsechno mas ve FE je prave to SPA. Nerikal bych tomu extrem, to je realita dneaka a industry standard.

Puvodne zasny SPA neexistovalo a vsechno se psalo na serveru. Jenze tam se neda resit interakce a delit to na server a klient cast se u tech slozitych aplikaci ukazalo neprakticky.

FARIN: drag&drop nebo file upload jako argument beru. I kdyz si myslim ze to jde ekvivalentne resit nejakou izolovanou komponentou, ktera tuhle funkcionalitu vyresi a osobne bych vybral tohle reseni. Ale chapu ze to je osobni preference.

Validace si myslim ze jde stejne dobre resit roundtripem pres server, kde je to megajednoduchy volani, odpadne ti duplikace. Opet, prinejlepsim osobni preference IMO.

U toho stavu ale nerozumim. Stav muzes resit na serveru, typicky naopak musis (viz KEJML). API je v tomhle reseni ekvivalentni aplikaci, takze server vi, co se ma v UI vyrenderovat a vrati to. Cache na klientu neexistuje, takze invalidace odpada.

PJOTRIK: složítý je typicka ta aplikace kterou skrz SPA tvoříš, resp. její vnitřní stav. Dokud děláš neco co je spíš web kde jsou od sebe jasně oddělený stránky a dobře to pasuje na model request / response a potřebuješ to obohatit nějakou interaktivitou tak htmlx (případně alpine.js) je hezká přímá možnost bez toho aby člověk musel setupovat nejaký komplikovaný stack.

Nejde tolik o rychlost (i když SPA je většinou pocitově o něco responzivnější) ale o management stavu. U těch komplexních aplikaci to není tak že by jsi s nějakou uživatelskou akcí vyrenderoval jeden fragment html a ten na stránce vyměnil. Často se změna propisuje do více míst, invaliduje cache apod.

Navíc přístup všechno na serveru dost naráží třeba u formulářu. Tam řešíš validace, drag&drop reoredring seznamů, file upload přes drop souboru .... stejně to obsluhuješ netriviálně na straně klienta.

Druhá věc je že ty deklarativní knihovny hezky fungují dokud to jde dobře deklarativně popisovat. A jak se to začne komplikovat tak to jde do špaget. V tohmel jsou knihovny jako React / Svelte univerzálnější a umožnují lepé aplikaci strukturovat a i ten syntax cukřík je tak hezčí.

Ale možná pod tímhle rozumíš právě to graficky intenzivni UI.

FARIN: no a k tomu bych rad slysel argumenty, proc nenahradis? Ja v tom vidim sanci nechat fakt veskerou logiku na serveru a web mit opravdu trivialni.

Chapal bych nejaky graficky intenzivni UI, ktery musi okamzite reagovat (i kdyz i to Datastar tvrdi ze zvlada dostatecne rychle, nemam vyzkouseno, ale furt tam musis pocitat s latenci site). Ale co je na SPA inherentne slozityho?