For å skjønne mer om hvorfor de kule kidsa om dagen liker Remix/Next så holder jeg på å lage en side med Remix hostet på Cloudflare, og kan til en viss grad forstå entusiasmen din. Det går fort å få opp noe "som virker", men det følger med en god del kompleksitet på lasset. Har f.eks akkurat skjært tenner når jeg skulle sette opp noe så enkelt som sesjonshåndtering med Cookies i Remix. Det funka ikke på Cloudflare fordi deres runtime ikke var helt node-kompatibelt. Så da må man inn og skrive sin egen sesjonshåndterer i Remix

Det minner meg veldig om Rails, bare i frontend

litt mindfuck i begynnelsen med serverkode og frontendkode i samme fila

Skulle akkurat til å nevne Rails 😅

Jeg har jobbet nok med rammeverk til å vite det jeg trenger å vite om "use server", og det skaper ingen entusiasme for meg.

men for all del, man kan være veldig produktiv så lenge man tegner innenfor boksa

Det eneste som går fortere er som @U0PS4MS80 sier å komme igang. Det er rimelig uinteressant å optimalisere for ass.

f.eks litt digg å lage en ny route ved å bare putte ei fil som heter minNyeRoute.ts i routes-mappa

men det er ikke helt gratis 😄

For all del. Men man kan lage seg sånne conveniences selv også

kunne vært interessant å undersøke hvordan man kunne fått til noe lignende for clj(s) i biblioteks-form. I praksis ender man jo opp med helt “plain” js-filer som har funksjoner som bruker env vars, tar imot js-data og returnerer js-data. Så slipper du å navngi paths i API-et, deployment av front-end følger deployment av back-end 1:1, osv osv

@U0MKRS1FX sånn, BFF-rammeverk for clojure?

haha, æsj

jeg vil ikke avfeie det helt, til noen ting så kan det passe bra

hmm ja kanskje, på sett og vis (sier jeg, etter å ha skumlest om BFF). Om alt du har er én klient og én backend så har det vel ikke så mye å si hva man kaller patternet, siden det er 1:1 uansett i det tilfellet

@U0MKRS1FX kanskje det jeg tenkte mest på var at det APIet du får autogenerert er spesialsydd for frontenden din (typisk)

det fine er jo at selve implementasjonen som nevnt ender opp som helt plain funksjoner som bruker env vars. Så det er nokså portabelt om man skulle ønske å deploye det på andre vis senere

ja riktig, i den grad man kan kalle det autogenerert - du skriver jo koden selv, så det “eneste” man slipper å gjøre er å manuelt pakke det inn i URL-routes (byggesteget gjør det for deg) og deploye det separat

har eksperimentert litt med next + vercel sin “use server”, og namespacene med “use server” ender opp med å vite null og niks om next + vercel

kan man snu på det? Hva er verdien av å skille på deployment av frontend og backend når koden i praksis er 1:1?

i mitt tilfelle er “use server” noe jeg putter i toppen av separate backend-filer, ikke noe jeg putter inni handler-kode embedda i rendringen. Så for meg oppleves hovedforskjellen som at jeg kan kalle const res = await myBackendFunction() direkte der jeg gjør I/O, i stedet for å kalle const res = await fetch("/my_backend_function") og deploye den separat

siter med å se ulempen - helt åpen for at det er jeg som bare er blind for et eller annet her 😄

Byggesystemer og rammeverk har som kjent ingen kostnad 😅

hmm det er sant, mindsettet mitt her er vel at jeg allerede bruker next + vercel