Morn!

Morn, ja!

Morn!

God morn!

Morn!

Har dere forslag til greie backendspraak om man ikke vinner frem med argumenter for Clojure? Jeg tror det oenskes at spraaket skal vaere mest mulig mainstream. Jeg heller mot Python eller TypeScript da.

Java eller Kotlin - da kan du snike inn en Clojure-jar og starte en socket REPL. 🙂

Eller Erlang og Elixir hvis det ikke funker. Det er det nest beste etter Clojure IMO. Dog ikke "mainstream" nok, kanskje 😅

Jeg tror Kotlin kan vaere en mulighet. Mine kollegaer har brukt det en del tidligere.

Mest mulig mainstream må vel være Kotlin.

Du får spørre om de også bare spiser burger på McDonalds.

Mer seriøst ville jeg utfordret ønsket om et mainstream-språk. Vanskelig å få tak i utviklere (du konkurrerer med alle andre som bruker samme mainstream-språk). (Det er vanskelig å få tak i utviklere uansett, men artig å snu dette argumentet til Clojures fordel, da.)

😄

Jeg tror det hovedsakelig tenkes paa at det blir vanskelig med nye utviklere og stoerre teams, og at Clojure ikke har statiske typer.

Kan anbefale å unngå både nye utviklere og større teams. 🙈😅

😄

Men hvordan synes dere at et dynamisk spraak som Clojure fungerer i stoerre teams? Jeg vet jo om Nubank og Ardoq, men er det mer slit enn med et typet spraak? Jeg har en foelelse av at det krever mer disiplin.

Her er en brannfakkel! Jeg synes sterkt typa funker dårligere i større teams 🙂

Eller, det krever minst like mye disiplin som et dynamisk typa språk som Clojure.

Jeg vil si at statisk typede språk i stor grad løser problemer de selv er opphavet til. "De lar meg gjøre store refaktoreringer trygt" -> så er det ingen som stiller spørsmålet "Hvorfor må vi gjøre store refaktoreringer?" Jo, fordi dine custom typesignaturer er strødd i hele kodebasen, og lager en enorm rigiditet.

På den annen side så kan jeg se poenget med å lage rigide strukturer der hvor man ikke kan stole særlig på utviklerne, slik som i store team av nye utviklere. Da blir det fort Pull Requests og hele bøtteballeten, da.

Og vi/jeg ser i vår TS kodebase at vi har sykt mange “like” typer med samme navn, og at vi har alt for mange typer som har “alt” som optional.

Jeg tror det kan oppsummeres som at store systemer med mange utviklere krever disiplin og klar arkitektur uavhengig av språk/typer.

Store team, DON'T DO IT

Å være et lite team er det viktigste valget du tar

Skal du ha et stort team er teknologivalg mindre viktig, for det blir surr uansett

Jeg tenker at jeg i 2024 trenger å lære meg mer om frontend og ClojureScript. Inspirasjonen kommer nå sist fra adminkonsollet i Tailscale og ikke minst combobox-løsningen i Linear, som minner en del om Status- og Priority-knappene på https://ui.shadcn.com/examples/tasks. Én mulighet er React-sporet som disse virker å bruke, og da kanskje ting som uix/re-frame etc. Et annet spor er Stateless, data-driven UIs a la dumdom fra @christian767. For sistnevnte, er det noen åpenbare utgangspunkt for bra UI-komponenter? Når jeg ser på ting som shadcn/ui, Radix, Headless, Catalyst, virker det som at alle disse forutsetter React. TailwindUI har også en HTML-versjon av komponentene sine, så kanskje det ville være et ok utgangspunkt.. er det noen andre i samme gate? Ellers blir det vel egentlig å ta for seg shadcn/ui eller de andre her og rett og slett gjøre jobben med å reimplementere dette i Sasha elns, dette hadde vært god læring;) Alternativt en kombo, hvor mesteparten er stateless/data-driven og de mest avanserte komponentene oppgraderes til islands med React(!?).

Jeg ville startet uten UI-komponenter. Skriv HTML og CSS. Hvis du vil ha UI-komponenter for å slippe å drive med CSS, så bruk Tailwind.

Frontend er ikke så komplisert som alle disse rammeverkene skal ha det til.

Jeg har veldig lyst til å lage en hiccup-versjon av radix, det tror jeg kunne vært nyttig. Må få ferdig verktøyet som skal rendre dem først bare 😅

Er ganske motiver for å bygge opp frontend tooling som ikke lener seg på npm, og som er enklere enn react-økosystemet

Jeg digger når folk lager et like økosystem med selvstendige og fristilte biblioteker som allikevel drar nytte av- og bygger på hverandre. borkdude er helt rå på det.

Typ "jeg vil egentlig C, men først må jeg gjøre A og B," og deretter gjort det.

når jeg ikke har tailwind, skriver jeg CSS så jeg kan kode på samme måte som med tailwind 😄

TailwindUI ville jeg kanskje vurdert om jeg var litt mere i samlebånd-modus, men de tingene jeg holder i er langtlevende og relativt få prosjekter. Da foretrekker jeg å lage mine egne komponenter

liker idéen med headless GUI-komponenter, men har ikke tatt i bruk noen sånne biblioteker noe sted enda

På temaet front-end og design, er noen kjent med https://bradfrost.com/blog/post/atomic-web-design/ og har noen tanker om det? Jeg har hørt en del prat om det og synes det ser interessant ut i prinsipp.

Har skrevet en liten intro til Datomic sin datamodellering. Hadde egentlig tenkt å skrive litt mer avansert stoff, men @christian767 overtalte meg til å starte med basics. Det var nok lurt. Mer avansert stoff senere i serien. 😅 https://parenteser.mattilsynet.io/smak-av-datomic/