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?

Ale abych nebyl jenom za zapsklyho dedka - uz chvili se divam na HTMX a Datastar a to vnimam jako zavan opravdu sveziho vetru a zpusob jak by mel fungovat webovy stack. Zadny JSON API, GraphQL, javascriptovy SPA, ale primocara opravdu RESTful aplikace... po 20 letech co jsem utekl pred javascriptem mam znova chut delat i frontend. Delate s tim nekdo, co si o tom myslite?

SH_PANDA: tak to me je mentalne 60 a vidim vsude naplasti a hlineny nozicky :)

BESH: většinou je za tím nějaký designér, který to tak nakreslil, a klient, který to chtěl přesně tak, jak je to nakresleno, a W3C, které nedovoluje (nedovolovalo) dostatečně stylovat formulářové prvky. Zrovna dropdown menu si každý browser renderoval po svém.

LITTLELI: Ad "reseni je slozitejsi nez problem". To mi povidej. Ja ted zrovna videl jedno React reseni dropdown menu s odkazama a byla to hierarchie nekolika komponent, kazda s nejakym vlastnim state a onChange callbackama, kde teda na konci byla implementace Listboxu z @headlessui. Netusil jsem, ze se mi jeste nekdy zasteskne po klasickem CSS ul->li menu, ale tohle bylo na me fakt moc. Proc si to ty lidi delaj. :(

Jo, je to zajimavy, cekal bych ze se vztah k LLM bude ridit osvedcenym

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.

Ale evidentne jsou i mezi nama starsima rozdily ve vnimani, taky mam stejne staryho kolegu, kterej je z chatgpt unesenej, nechava si radit s kodem, dela s nim obrazky do her co chysta pro deti atd. Ja mam k LLM instinktivni neduveru, parkrat jsem to zkusil pouzit prave na nejaky obrazky a nedokazal jsem ziskat nic co by bylo vzdalene pouzitelny, vylozene frustrujici zazitek. Na kod bych si od toho sahat nenechal

Ja jsem narazil na (pro me) zajimavy fenomen. Pred par mesici me kamarad (byvaly a ted uz zase soucasny kolega) abych mu vysvetlil jednu implemetacni techniku na praci garbage-collectovanymi referencemi ve (unmanaged) VM kodu. V zasade neco jako std::unique_ptr akorat jsou vsechny propojene do linked-listu nebo tak aby se to dalo snadno posbirat kdyz clovek pocita root set.

Predesilam, ze kamarad fakt neni blbej, programovat umi, a jako VM vyvojare ho respektuji a chodim si k nemu pro nazor kdyz jsem na pochybach nebo v koncich. A jak je take nadsenec do LLM tak hned ze to hodi do ChatGPT (nebo neco podobneho), ze takovou trivku nebude psat sam.

A hned mi to poslal jako ze to je "dobrej zacatek, ne uplne 100% ale doladi se par radku tady a tam", velke nadseni.

Ja se na to podival a i kdyz jsem do toho brejlil chvili, prislo mi to dost mimo a ze bude jednodussi to napsat z nuly nez se to snazit opravit - asi nikoho neprekvapi, ze ja jsem spis LLM-skeptik.

Takze mozna ta kvalita kodu zavisi i na tom, jak moc clovek chce, nebo naopak nechce, aby AI byla dobra :-)

SULTHAN: ano, udelali jsme copilotu metodu @BeforeEach (JTest) aby nakonec zustala prazdna a ve 20 @Test se opakovalo prvnich 5 radku systematicky :))