62. Du har gett mig något att tänka på
lyssna! 
Anton BABBLAR på om sitt nya sidoprojekt Fredagslunchen samt det nya heta ramverket som det är byggt med, Remix, och tro det eller ej så blir Thérese faktiskt lite såld. Dessutom en hel del om en skriva dig på näsan-attityd i sin marknadsföring, ett väldigt avancerat excelark, back to basics-strategin, filbaserad routing och att använda formulär istället för fetch för att skicka data.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Länkar
Avsnittets skämt:
Why do you never see Lucifers programs?
He only runs daemons.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) "Varför ser du aldrig Lucifers program?"
Jag vet inte.
"Han använder bara dämoner."
Det var kul. Jag tycker det var roligt.
Jag blev så mindfuckad när jag skämtade på engelska och jag trodde att det skulle komma på svenska.
Och sen säger jag ändå "jag vet inte på svenska" och då kände jag mig så jävla dum.
Det hade också varit jättekonstigt om du började prata engelska.
Jag håller med.
På tal om Lucifer och Demons såg jag någon som hade gjort en dal i den här OpenAI-modellen som spottade ut såna här bilder som alla använder.
Han hade skrivit någon prompt som hade med "show me what it looks like to program a demon"
Och då var det verkligen typ en demon som satt vid en dator.
Väldigt kul!
Välkomna till ett nytt avsnitt av ASTF!
Varmt välkomna!
Gud, idag är det mitt ämne känner jag.
Vi ska prata om mitt senaste sidoprojekt som som alltid när det kommer till mina sidoprojekt så känns det just nu som att fan vad bra det är.
Helvete vad kul det är att bygga. Och sen får vi väl se hur länge den här hypen håller i sig.
Men det som jag tänkte på, och det är värt att prata om, är att det är byggt i React-ramverket, som heter Remix.
Som ändå är ganska nytt. Det släpptes väl, det har funnits bakom betalvägg förra året, och sen släpptes det väl open source i våras, eller lite längre?
Något sånt, tio år kanske.
Någonstans där i alla fall. Så det har inte funnits jättelänge för allmänheten att köra.
Trots den bilden folk kanske har av mig, att jag är en person som testar allt nytt och hoppar på nya saker.
Så har jag ändå varit så här "Äh, jag orkar inte testa remix".
Jag vet inte riktigt vart det kommer ifrån. Jag tror att det kommer lite ifrån att de har haft en liten sån här "skriva dig på näsan"-attityd i sin marknadsföring.
Om du förstår vad jag menar.
Ja, är det typ, jag har varit inne i en blogg som var så här "Den här bloggposten var skriven innan Remix fanns och Remix borde du använda för det löser alla dina problem".
Och verkligen så att marknadsföringar var det. Men vi är liksom det bästa sen skivat bröd och allting kommer bättre när du kör remix och hokus pokus fram och tillbaka.
Typiskt osvenskt. Så alla svenskar blir såhär "Ooooh".
Exakt. Och det har då gjort att jag inte riktigt orkat köra remix.
remix. Men sen fick jag den här idén när jag började på ett nytt uppdrag.
Väldigt kort bakgrundsstory till vad det här är för något är att det kallas
för fredagslunchen. Den här appen som jag byggt och det kommer från att när jag var på ett uppdrag för massa år sedan så hade
vi ett avancerat Excel ark där vi förde in.
Vi gick ut och käkade lunch varje fredag tillsammans och då förde vi in då de här lunchen i det här Excel arket och
och satte betyg på dem och lite sådana saker.
Det i sin tur ledde till att Excel-arket spottade ur sig
"Vems tur är det att välja lunch?"
För vi hade ett problem med att
"Vart ska vi gå och äta idag?"
Och så var det ingen som visste riktigt vart vi skulle gå.
Det blev liksom kaos.
Så det här avancerade Excel-arket löste det problemet.
Men då började jag på ett nytt uppdrag i våras
med en kollega från det där gamla uppdraget.
Då kom jag ifrån att "Ska vi inte bygga den här appen nu?"
-från det här Excel-arket.
Vi har pratat om att vi gjort det flera år tidigare, men aldrig blev av.
Och nu sa vi "ja, men vi gör det tillsammans".
Och sen byggde jag den på semestern själv.
Vilket är ett dåligt exempel på hur man ska göra.
Men det var då för att jag testade Remix-
-och tyckte att det funkade så jävla bra.
Om jag ska vara ärlig, liksom.
-För... -Är det det bästa sen skivat bröd?
Nej, jag vet inte om det är det bästa sen skivat bröd.
Men det passade extremt bra till den här typen av hemsida eller den här typen av applikation.
Jag kan försöka förklara lite grann vad Remix är för dig så får vi se om du fattar.
Och du fattar förhoppningsvis de som lyssnar också.
Men om man liksom... vänta jag ska ta upp Remix-dokumentation framför mig så jag kan få pitchen.
Men jag tänker först, min grundtanke kring Remix är att det väldigt mycket går tillbaka till att använda native-grejer i browsern och är extremt bra egentligen för formulär.
Exakt. Det är i stort sett idén bakom att vi vill använda så mycket som finns inbyggt i JavaScript, browsern och HTML som möjligt.
Utan att lägga på massa lager ovanpå.
Läser man på deras hemsida så står det typ så här "Focused on web standards and modern web app UX. You're simply going to build better websites."
Och det här är också så här "Aaah, det är lite säljigt."
"Remix is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick and resilient user experience. People are gonna love using your stuff."
Och det är som du säger, de har en ganska stor fokus på att man ska använda de byggstena som finns.
Väldigt mycket är att du skickar FormData-objekt istället för JSON
när du gör anrop.
Det var den stora grejen.
Istället för att du gör en onClick-handler på din knapp
och sen så har du ditt state i någon useState-hook
som fångar upp allt från ditt formulär med onChange-grejer
Istället för det har du en "form"-komponent som kommer från Remix.
Det den gör är att rendera ett formulär, alltså ett form-element.
Sen lägger den på lite magi och så har du en "Submit"-knapp.
Istället för att ha allt det här manuellt, att du skickar nåt och kör "fetch" och ett request med din data och allt sånt.
Så har du bara att du submittar ditt formulär.
Det här finns inbyggt, och det känns som att många har glömt bort det.
Du kan submitta ett formulär, du kan köra en post request från ett formulär, du kan köra ett get request från ett formulär och så vidare.
– Men det är väldigt mycket då kör de liksom uncontrolled components. – Ja, precis.
– Men det är mer som inbyggt React-hooks form då?
– Ja, exakt. Du skulle lätt kunna köra React-hooks form
ovanpå det här, bara att skita i
submit-vitarna eller "wrappa" Remix Submit i React Hook Form.
Så att när du submitar så submittar du formuläret.
Det finns ju lite hooks för att när man bygger applikationer idag så blir de ju till slut väldigt interaktiva.
Det går ju att göra det i Remix också.
Så att det finns hooks för att "use form" och så kan du få ut en submit-funktion som du kan anropa för att submita formuläret istället för att klicka på knappen till exempel.
Då skulle man kunna använda React Hook Form för att köra avancerad validering eller logik på vilka fält man skulle visa och sånt där.
Men hittills har jag inte utgjort det.
Jag tänker att om någon lyssnar på det här och vill gå in och titta på den här sajten så finns den på fredagslunchen.club.
Den ligger också i beskrivningen.
Men då kan man gå in och titta lite grann och klicka runt om man vill.
Medans vi pratar så kanske man fattar hur den ser ut.
Just det. Men för någonting, för jag vet att när jag tittar på det här så var det fortfarande så att någonting som man tänkte att det kanske skulle lösa men inte riktigt löste var formvalidering.
Ja, precis. Det gör det ju inte. Alltså server-side kan du göra, för det är en viktig grej här att Remix är liksom ett fullstack ramverk.
Så det är inte bara ett frontend-ramverk, utan du får även en server-side med handlers för de här endpoints som du skapar upp.
Eller formulär-postningarna egentligen.
Men det finns ju ingen inbyggd client-side-validering för formulär.
Men däremot finns det inbyggt i browsern ganska mycket.
Det finns ju det här formulär-constraints, jag kommer inte ihåg exakt vad det heter, men form-constraints tror jag.
som är när du sätter en "required" attribut på ett element, eller på en input-element till exempel.
Eller du sätter min och max på ett "type number" element, och så vidare.
Så de kör jag i stort sett bara i Fredagslunchen.
Och sen har jag "server-side-validering" då, som när den skickar tillbaka fel och då renderar man dem vid rätt element.
Ja, alltså det var länge sedan jag satt med formulär innan.
Alltså det var ett stort glapp liksom.
För då hade jag nog när jag kom tillbaka till formulär igen, notoriskt svårt.
Men hade glömt bort valideringen och hur extra notoriskt svårt det var.
Alltså det var som en kall dusch att komma tillbaka till det där.
Jag håller med, men det känns som att det här formulär constraint API räcker väldigt långt.
Det funkar väldigt bra för de flesta grejerna jag gör just nu.
Sen är det vissa saker som kanske inte riktigt kontrolleras.
Jag har ingen avancerad logik på att du ska ha ett telefonnummer input till exempel.
Det har jag inte att jag gör någon validering på.
Kan du styla?
I sådana fall skulle jag bara göra det server-side som det är just nu.
Just det, men kan du styla det som du vill eller blir det alltid bara browser-native?
Ja, de är väl browser-native bara. Jag har inte ens tänkt på hur jag skulle styla dem.
Faktiskt, om jag ska vara helt ärlig.
Vi funderar på om man kunde göra det på något per attribut.
Du vet när man kan säga om det här attributet har det här värdet så vill jag styla det så här.
Det kanske man kan.
Jo, jag undrar om det inte finns...
Jag tror att de slänger på om det är något data-attribut eller om det är något liknande.
När ett element har något fel.
Så att du skulle kunna rendera att borden blir röd eller bakgrunden blir röd.
Eller vad man nu vill göra.
Så det är det som jag känner igen när jag var inne och läste om det här form-constraints-apiet.
Just det.
Och sen det är ju som du säger, formulär i sig är ju lite mäckiga.
Det blir ju också lite mecket "vad händer när man klickar på save i formuläret?"
Och så ska det skickas till någon endpoint och sen blir det en redirect av sig själv när man håller på med formulär.
Men det är här en remix-magi kommer in som ligger ovanpå.
För det som händer är att om jag gör en ny route, för de använder också routingen i hela appen.
baseras på React Router.
Det är samma skapare bakom React Router som har skapat Remix.
De har tagit React Router-idéerna och gjort ett fullstäckt ramverk av det.
Jag vet också att de håller på att portar ganska mycket av den här dataladdningslogiken
in i React Router.
Så om du inte vill använda hela Remix-ramverket så ska du kunna köra
bara dataladdningen och routingen via React Router v6 eller v7.
Så det de har gjort egentligen är att du har en fil, eller så här konventionen ska säga, så det går det på flera sätt
Men konventionen är att du har en filbaserad routing, så att baserat på vilka filer du skapar och i vilken mappstruktur du lägger dem så får du en routing
Då kan det till exempel vara att du har en fil eller på Frihetslunchen kan man skapa en grupp
och i den gruppen kan du gå in på en massa olika saker.
Du kan titta på en specifik lunch som du har lagt upp eller en specifik användare.
Då är det en mappstruktur.
Du har en GroupID-mapp till exempel som mappar till GroupID-delen av URLen
som sedan används för att hämta upp gruppens data från databasen.
Det i sin tur. Sen kan man ha en undermapp till den som är en till del av Pathenson.
Du går på "groups/groupid/lunch" till exempel.
Då ligger "lunchrouten" som är en fil som ligger under den i mappstrukturen.
Med "nest" ladd ner.
Och så skapas allt det där upp automatiskt.
Och sen gör de massa magi här för att man ska slippa det här som kallas för "request vattenfall".
Så att om du laddar in flera komponenter på en sida, du har en föräldrakomponent som gör någon datanrop och sen så har du något barnkomponent som gör någon datanrop och så vidare.
Då blir det ofta att du väntar först på att föräldern ska rendera och gör klart sitt datanrop, sen kommer barnet göra sina datanrop och rendera och så vidare.
Och här gör de en massa saker som de smart räknar ut.
"Vilka andra ska vi göra?" Och så gör de alla de parallellt.
Och det gör ju att sajterna känns väldigt, väldigt snabba.
Och sen är det ju också server-sider underat såklart.
Men det tänkte jag vara det som alla råvaror är förfri.
– Blir det längre tid till time to paint då?
– Nej, det borde det inte bli.
Men innan man ser något?
Nej, utan den gör ju liksom alla de här anropena.
Om du skulle server-side-rendera, det spelar alltså så här,
om du skulle server-side-rendera med ett andra exempel,
så tar det längre tid att göra fler anrop sekventiellt än om du gör dem parallellt.
Just det, gör de parallellt, ja.
Ja, men jag tänker att innan du ens ser någonting så skulle det kunna ta längre tid,
För att om barnets anrop tar längre tid än förälderns anrop.
Ja, precis. Säg att det kommer ta lika lång tid som det längsta anropet tar.
Precis. Så om du då har ett barn som har ett jävla monsteranrop utan anledning.
Men säg det. Då kommer du kanske få en väldigt tydlig skillnad.
Ja, så skulle det kunna vara. Men det beror ju också lite på hur det är uppsatt.
Nu finns det ju halvfärdig support för suspens i React och server-side suspens är väl...
Jag vågar inte säga om det är implementerat eller inte för jag kommer inte ihåg.
Men där du kan säga att den här biten ska vara wrappad i suspens och då kan vi server-side-rendera allting fram tills den.
Om vi vet att den är långsam. Och sen så skickar vi in den biten när den är klar.
Vet inte hur supporten i Remix ser ut för det här, för jag har inte haft någon anledning att testa.
Men det är ju liksom en del av framtiden, React i stort sett, när du ska kunna streama in vissa delar och
rappa saker i Suspend Serverside och sen skicka tillbaka den utan att du behöver skicka all data igen.
Men sen då, det som jag tycker gör det så jävla lätt att jobba med det här sen är att
När du har skapat upp en route, alltså en fil.
Det kan vara till exempel att den heter "groups.tsx"
för jag kör TypeScript och tycker det är jävligt nice.
Så då har man skapat upp en "groups.tsx", man skapar upp en komponent som är det som renderas och allt sånt.
Och sen så kanske man behöver någon typ av data i den där routen.
Och det man gör då är att i samma fil som du har definierat din route så skapar du en "loader" som man kallar det.
Det är egentligen bara en funktion som du exporterar och kallar för Loader.
Då kommer Remix köra den när du laddar den routen.
Den skickas till din komponent genom en liten hook som heter UseLoaderData.
Vad du nu returnerar från din Loader får du ut ur den här UseLoaderData-hucken.
Det här är lite likt om man har Next som exempel där du har GetServerSideProps.
Det är samma tanke i stort sett, bara att istället för att det skickas som props så skickas det genom en hook.
Det som också är på det här spåret att de använder väldigt mycket native, eller inbyggda funktionalitet, är att du kan returnera ett request-objekt.
Som är det som browsern använder för att visa ett request, eller server-side i Node använder för att visa ett request.
Det kan vara att du returnerar ett request och sätter vilken statuskod du vill ha.
Till exempel 200 och såna grejer.
Det funkar extremt bra.
Sen har de visst att de laddar om de här lite grann i klienten också.
För det är klientnavigering när du väl har laddat in sidan.
Så om du går mellan olika routes så kommer den automatiskt köra din loader och ladda in datan till den routen som du går till.
Och det är liksom så man spesar det. Och det är ganska likt hur det funkar i Next.
I att du spesar din loader eller du spesar din getServerSideProps och så kan du matcha data från servern med din route-komponent.
Om det låter vettigt.
– Ja, men alltså för att det där... Jag kommer ihåg att jag läste lite om det där.
Och det var som att de sa att vi till andra håller vårt egna API, liksom.
Men jag fick nog aldrig riktigt någon fjong på det där.
För du säger att jag då väljer vilka egna statiskkoder jag vill returnera.
Men vad är...
Säg att jag behöver koppla ihop det här med en databas.
Är det den delen som gör det då?
Eller snackar vi fortfarande att jag har det till backen?
Nej, den körs ju på servern, så att säga.
Sen beror det ju på lite grann vad du har för databas och sånt.
Alltså, pratar vi i fredagslunchen till exempel, då har jag bara en SQLite-databas.
som ligger bredvid servern.
Och sen kör jag Prisma som är ett ORM för att hantera den.
Så jag har egentligen bara skapat upp några filer för att prata med databasen.
För att ha det lite separerat.
Och då anropar jag bara några funktioner som jag har i dem.
Och då läser de och skriver från databasen direkt i loader-funktionen.
Men du skulle ju kunna ha att "här gör jag ett anrop till min databas som ligger någon annanstans".
- Ja, du skulle också kunna ha någon typ av back-end API som ligger och kör för att hantera större saker.
- Ja, precis. Skulle du ha ett separat API, då skulle du kunna anropa vad du vill därifrån.
- Ja, men då blir det... Säg att du har ett API som vill pussla ihop flera olika tjänster och databaskopplingar och grejer.
Då skulle du ändå då... Är det då servern som kommer göra anropan och sen skicka ett nytt request upp till klienten?
Ja, om du lägger i loader-funktionen, för de kör ju alltid på servern.
Just det, men jag skulle kunna göra det direkt från klientkod också.
Ja, du skulle kunna lägga det i komponenten som du vill.
Alltså skriva det som att det var ett spa, så kan du lägga det i en ljuseffekthook och göra ett androp därifrån.
Några gånger missar jag allt det göttiga när vi...
Man missar lite av det göttiga, det gör man absolut.
Det som är nice sen är att när det kommer till formulären.
Så om man skapar en sådan här form eller man importerar den här formkomponenten som de har och så kör man den
som sitt formulär och så specerar man sin data som vanligt.
Du har inputs med names på som du sätter till det värde du vill ha och
med alla typer du vill ha och sedan har du en submit-knapp.
När du då klickar submit på den, då kan du på samma sätt skapa upp en funktion och
exportera den i din route-komponent som då heter Action istället.
Så du gör Export Const Action och det är då en funktion som tar emot
requestet och all information på det.
Och det är den funktionen som kommer att köras när du submittar ditt formulär.
Och då kommer den hantera den informationen som kommer därifrån.
Så då kan du plocka ut från det här formdata-objektet som skickas.
Så kan du plocka ut all information och göra om du vill göra någon
-som för exempel side-validering, och svara tillbaka med om du vill skicka tillbaka felkoder-
-eller om du vill redirekta till en annan sida, eller vad det nu kan vara.
Allt sånt görs ur action-funktionen, som också ligger i samma fil som hela routern.
-Men kör den också bara på servern? -Ja, den kör också bara på servern.
Så man kan jämföra med att action-funktionen skulle kunna jämföras med en API-endpoint.
Bara att den är hårt knuten, eller inte hårt knuten, men den är knuten till ditt formulär som du har i din route.
–Okej, men det gäller bara formulär, eller?
–Ja, det går att göra. Du kan ju skapa upp API-routes, så att säga.
Skillnaden blir att du skapar inte upp någon loader eller komponent i din fil.
Du exporterar bara den här action-grejen.
Då kan du anropa den som vanligt.
Du skulle kunna skicka JSON till den om du vill, och du kan skicka formdata och sånt där.
Då blir det mer en API-route än något annat.
- Men ponerar att jag ska bygga en applikation som inte har ett enda form.
Är det värt att använda Remix?
Det beror ju på vad den ska ha i stället.
Alltså vad du ska göra för information och sånt.
Det kan vara värt det, för en grej som är med Frihetslunchen till exempel är att
hela applikationen funkar nästan, det är väldigt nära, utan JavaScript som det är just nu.
Och det är utan att jag har försökt göra det så.
Anledningen till att det inte funkar är att jag kör några komponenter som inte har en fin fallback.
Jag har lite avancerade typ Select, Dropdance med Autocomplete och grejer.
Och de har ingen bra fallback till när du har JavaScript avstängt.
Men annars funkar i stort sett hela min applikation utan JavaScript.
Alltså även att skapa nya grupper och logga in och registrera sig och allting sånt.
Och det är ju väldigt trevligt.
Och det beror ju då på att jag använder formulären istället för JavaScript för allting sånt.
Och då menar du att det är för att allting är serverenderat?
Ja, precis. För allting serverenderas.
Och formulären används för att skicka data.
Så du behöver ingen JavaScript i klienten för att ett formulär ska skicka sin data.
- Ja, det är det nya som är det gamla.
- Så är det verkligen.
Många pratar om att det är en pendel, allting.
Nu har vi svingat ganska långt till client-siden.
Det är att allt ska vara ett spa.
Och nu håller pendeln på att svinga tillbaka lite grann.
Och sen får man väl se hur långt det tar vägen.
Men förhoppningsvis kan man hitta det här väldigt svåra ordet "Equilibrium".
Alltså ett nollläge, eller vad fan det är, när den står still.
Där det liksom är toppen.
Equilibrium?
Equilibrium, så kanske heter det.
Är det?
Jag har ingen aning.
Det är nog samma sak.
Det är ett klassiskt ord som känns här.
Det heter nog så här på engelska, det borde heta så här på svenska.
Ja, jag vet inte.
Men en fråga då.
Om man som till exempel jag skulle sitta och vela mellan Next och Remix.
Vad har du för tankar där?
Jag tycker det är svårt att avgöra för att jag inte har kört tillräckligt mycket Remix som det är just nu.
Jag tycker att för det här ljusgreset jag pratar om, där det är väldigt mycket formulär och datavisning och sånt.
Där tycker jag att Remix är magiskt bra hittills.
Jag har jobbat kanske två månader på det här till och från.
Och tycker att det funkar skitbra.
Det är sällan jag har byggt en applikation som jag har känt två månader senare att "fan vad enkelt det är att lägga till nya features".
"Fan vad enkelt det går att ändra saker och uppdatera saker och bygga om hur routern funkar och allting sånt".
Där tycker jag det är väldigt bra.
Jag vet att för nästa del så har de en RFC ute för att de ska uppdatera hur routerna funkar.
Då kommer det komma väldigt mycket av det som Remix har.
Alltså att du har den här nästladde routstrukturen där det beror på vilka mappar du har så kan du få olika.
Det finns också en sak i React Router som jag inte tror att jag nämnde.
Du kan ha en outlet-komponent.
Om du har en index-route eller en groups-route.
Den listar en vänstermeny med alla grupper i.
Den kan också rendera en outlet som är resten av skärmen.
När du då klickar på en av de här länkarna i menyn, då kanske den går till "groups/id".
Id kommer att renderas i den här outlet-komponenten.
Då kan du ha flera routes som renderar nästlade grejer på olika ställen på skärmen.
Det är väldigt svårt att förklara utan att visa det visuellt.
Men kolla på Remix eller på React Router så förstår man hur det funkar.
Och de bitarna kommer att komma till Next också.
Och jag tycker det är ett väldigt bra sätt att strukturera sina routes på.
Det blir väldigt tydligt.
Så svarta frågan är... Jag vet inte riktigt.
Okej.
Nej, bara den här outlet-grejen, jag visste inte om det. Det är ganska coolt egentligen.
För att jag har tidigare så här att vi byggde en sidodrawer som hade ett eget routing-system.
Till skillnad mot resten av skärmen.
Och då blev det så att man fick ha två history-objekt istället för att köra en memory-router och en browser-router.
Då skulle man slippa göra det i det här fallet.
Ja, precis. Jag har sprungit på den här outlet-idén några gånger tidigare och det har aldrig riktigt fastnat för mig.
Men nu tycker jag att det funkar väldigt bra, även om jag inte använder det supermycket i Frihetslunch-nappen.
Jag tycker att det är en väldigt bra idé, särskilt när man har den här tydliga hierarkin på sitt innehåll.
Jag tror att Remix skulle vara en dröm för att bygga en dashboard.
Då skulle du kunna ha outlets på lite olika ställen som baserat på vad du väljer i undermenyer.
Rendera saker på olika ställen.
Det tror jag den passar extremt bra för.
Du har gett mig lite att tänka på.
Ja, det är bra.
En annan grej som jag tycker är jättebra med Remix, som inte är hur ramverket funkar, men ur dokumentationsperspektiv och utvecklar DX-perspektiv, som vi pratade om innan, är att de har något som de kallar för stacks, som egentligen är bara ett annat namn för templates.
Men de har väldigt väl utbyggda templates på hur saker skulle kunna funka.
Så att Fredagslunch är baserat på något som kallas "The Indie Stack".
Och jag tror att de döper efter musikgenrer av någon anledning.
Så det finns ett metal stack och ett pop stack och allting sånt.
Men det här var liksom "The Indie Stack" om jag minns rätt.
Och då fick jag med en väldigt bra boilerplate med en SQLite databas.
Med ganska basic användarlig loggning.
med TypeScript support och allt man vill ha runt omkring.
Det gör att det är väldigt lätt att komma igång och testa hur man känner kring Remix
utan att behöva sitta och tänka "Fy fan vad jobbigt det är att sätta upp det här"
"Och hur skulle det funka om jag kör en databas?"
"Och hur skulle det funka med det här?"
Du kan testa Remix ganska lätt utan att behöva kommitta så mycket.
Hur är det med att bygga sida?
För i Next så kan man välja om man vill ha ett serverbygge static eller en klientbara.
Finns det möjlighet till remix eller är allting server?
Allting är server.
Och om jag minns rätt så är det ett väldigt medvetet val att de som har gjort det inte tror på statiskt genererat.
De tror att serverkraft är så pass billigt idag att du kan lika gärna server side-rendera än att statiskt generera någonting.
Ja, det kan jag väl känna.
Jag har liksom ingen riktigt åsikt. Jag tänker mig att statusgenererade saker kan ju också vara väldigt trevligt att slippa ha en server.
För att nu jag hostar den här på något som heter fly.io med en docker, container och sådär.
Och det funkar ju bra, men jag vet ju också att det skulle kunna strula.
Och jag hatar ju att gå ner i någon jävla infrastruktur och gräva utan att veta vad jag håller på med riktigt.
Känner du dig träffad? Jag vet att du har exakt det här du sitter med just nu.
Ja, jag är i ett sånt djupt aveshål.
Men det kan man ju spara till en annan gång.
Det känns som att jag har rantat i 30 minuter om Remix och att det är väldigt trevligt.
Funderar du på något mer? Det känns som att det är en perfekt tillfälle för dig att göra en fråga.
Nej, jag är lite mer fascinerad över att du har lyckats andas samtidigt.
Jag vet inte om jag har gjort det, jag kände att det är lite anfådd.
Ja, det har gått undan, men jag tycker det har varit extremt matnyttig information.
Jag vet inte, jag har varit lite sugen på att prova Remix, men sen gick jag in och började läsa och fastnade också lite för den här
"Bäst sen skivat bröd, vi löser alla problem." Då kände jag lite...
Och så la jag ner. Men du har fått mig lite taggad än.
Jag funderar på om jag kanske ska välja det över Next nästa gång.
Jag tycker definitivt att det är värt att testa.
För jag tycker utvecklarupplevelsen är väldigt bra.
Och jag tycker idéerna bakom är väldigt bra.
Jag tror jag skrev någon tweet när jag började testa det.
Jag tänkte inte hoppa på Remix-tåget, men det är väldigt bra.
Jag är väldigt glad att jag gjorde det.
För att det är väldigt lätt att lägga på nya features och bygga nya saker.
Sen kanske det spricker.
Frihetslunchen-appen är inte jättestor, men den är inte jätteliten heller.
Jag har ändå hunnit bygga ett gäng features som jag inte trodde skulle hinna bygga så här snabbt.
Det är ganska stora namn bakom det. Eller det är ganska bra grejer bakom det.
Det är Rec Router, Testing Library.
Ja, det är Kenzie Dodds, Ryan Florens, Michael Jackson och lite sådana folk om man känner igen dem.
Ja, så det känns som beprövade. Eller de har gjort mycket också.
De har extremt mycket erfarenhet kring många av de här grejbitarna.
Ja, verkligen. Jag tycker att man ska ge det ett försök.
Nu var det ett tag sedan, men jag testade ju Astro också som är ett mycket mindre moget ramverk för ett tag sedan.
Jag nämnde det kort i podden någon gång.
Men det fastnade jag inte alls för på samma sätt.
Det kanske är superbra också, men här var det verkligen så här att "oj, vad enkelt det är" var min upplevelse.
Och det tycker jag är ett gott betyg.
Hur är communityn och grejerna? Finns det hjälp att få när man hamnar i trubbel?
Jag har med mig någon Discord community, vilket uppenbarligen är en nya heta för alla saker.
Men de har en Discord community där folk är väldigt hjälpsamma.
Och det är extremt hög aktivitet. Men det kanske inte riktigt finns det här ekosystemet runt omkring det som det finns för Next.
Next, där finns det i stort sett plugins och extensions för allt.
Och på samma sätt mycket fler frågor och svar på Stack Overflow.
Men det är inte obefintligt heller.
Det är ganska många som kör Remix redan och tycker att det funkar väldigt bra.
Ja, det är nice. Där vill jag ha statisk information.
Jag vill ju inte behöva prata med människor direkt.
Nej, exakt. Du vill inte behöva skriva i någon jävla chatt.
Nej, för fan.
Nej, men det håller jag med dig om. Att behöva leta efter saker i någon Discord är helt värtlöst.
Ja.
Men ja, det kanske ska runda av remix-resan för den där gången.
Vi kanske får göra det. Jag kan andas litegrann igen.
Ja, så att du inte drunknar i luften.
Men ja, annars då? Vi finns på samma gamla vanliga ställen.
Exakt vad det är. Vi finns där vi finns. Vi hörs igen om två veckor.
Ha det bra, hej då!
Bye bye!
[Outromusik]
