Hvordan Oxide bruker HTMX, Hono og WebAssembly for å bygge en raskere, klarere webarkitektur

Team mister sjelden fremdrift fordi de valgte feil JavaScript-rammeverk. De mister fremdrift når UI-tilstand, forretningsregler, datatilgang og distribusjonstopologi glir fra hverandre.

Oxide tester en annen premiss: behold webens forespørsel-respons-modell, flytt beregningstungt arbeid inn i WebAssembly, og kjør serverlaget på en portabel edge-runtime.

Tesisen

En moderne web-stack bør optimere for fire ting:

  1. Arkitektonisk koherens
  2. Plasseringsfleksibilitet (nettleser vs. edge vs. region)
  3. Eksplisitte tillitsgrenser
  4. Empirisk ytelse fremfor anekdotiske påstander

I Oxide fører det til en firelagsmodell:

  1. HTMX + spesialbygde klient-JS-moduler for hypermedia-interaksjoner og progressiv forbedring
  2. Hono routes på Cloudflare Workers for edge-sikker forespørselshåndtering
  3. Rust og Zig WebAssembly-moduler for beregningstunge og deterministiske kjerner
  4. Lagdelt lagring med D1, Neon Postgres og DuckDB-WASM for forskjellige analyseoppgaver

Resultatet er et system som forblir forståelig etter hvert som det vokser.

Hva Oxide faktisk leverer

Oxide er ikke en konseptpresentasjon. Det kjører med disse konkrete kapabilitetene:

  • En samarbeidseditor drevet av Rust yrs, med SSE-basert live-synkronisering og gradvis degradering til tekst-synkronisering når WASM-modulen ikke klarer å laste
  • En benchmark-suite som sammenligner WASM og JavaScript på tvers av krypto- og algoritme-arbeidsmengder
  • En finansberegningsmodul i Rust WASM for mønstergjenkjenning og prognostisering
  • En Zig WASM-sorteringsmodul brukt som et komparativt benchmark-artefakt i det flerspråklige WASM-sporet
  • En SQL-analysekonsoll med skrivebeskyttet validering som tillater SELECT/WITH og blokkerer mutasjonsnøkkelord og stablede utsagn
  • Doble analyseveier: edge D1-kjøringer og utforskning med DuckDB-WASM i nettleseren
  • Historisk tversgående sesjonsanalyse via Neon Postgres-synkronisering

Appen eksponerer for øyeblikket fire WASM-moduler i produksjonsruter og brukergrensesnitt:

  • bench-wasm
  • crdt-wasm
  • finance-wasm
  • sort-zig-wasm

Hvorfor denne modellen fungerer bedre enn standard SPA-refleksen

Standard SPA-modellen overfokuserer på nettleser-runtime. Du kan fortsatt lykkes med den modellen, men bare hvis domenet ditt krever en langvarig lokal applikasjonsshell.

For de fleste produkter er de dominerende behovene:

  • pålitelige interaksjonsflyter
  • serverresponser med lav latens
  • klart dataeierskap
  • forutsigbare sikkerhetsgrenser

HTMX holder interaksjonen nær HTTP- og HTML-semantikk. Hono holder serverlaget kompakt og portabelt. WASM holder tung logikk eksplisitt og testbar. Sammen reduserer de utilsiktet kompleksitet.

Den arkitektoniske fordelen: Grenseklarhet

I Oxide er grensene strenge per design:

  • Views importerer ikke ruter
  • Services importerer ikke views
  • SQL-utførelse for ad-hoc-analyse er skrivebeskyttet validert
  • Edge-ruter håndhever inndata-skjemaer med Zod
  • Beregningstung logikk er isolert inne i WASM-moduler

Denne separasjonen har sekundære effekter:

  • Mindre sprengningsradius under endring
  • Enklere sikkerhetsrevisjon
  • Renere teststrategi
  • Mer pålitelig onboarding for nye ingeniører

Beregningplassering som en førsteklasses beslutning

Nøkkelinnsikten fra Oxide er ikke "WASM er alltid raskere." Det nyttige poenget er plasseringsvalgfrihet for den samme kjernen.

Du kan kjøre tilsvarende logikk:

  • i nettleseren (null nettverk, klient-CPU-bundet)
  • på edge (nettverkskostnad, sterkere kontroll og styring)
  • i regiontjenester (sentralisert integrasjon og aggregering)

Oxides edge-finansendepunkter anvender strenge forespørselsgrenser (transactionsJson opptil 500 KB og transaksjonstall begrenset til 2 500 for edge-mønstergjenkjenning) for å holde runtime-kostnadene forutsigbare. Dette er nivået av ressursbevisst design produksjonssystemer krever.

Dataarkitektur: Tre motorer, tre oppgaver

Oxide tvinger ikke én database til å løse alle problemer.

  • D1 håndterer edge-lokale skrivinger og operasjonelle benchmark-data
  • Neon Postgres støtter tversgående historisk aggregering og trendanalyse
  • DuckDB-WASM tilbyr interaktive klientbaserte analysekjøringer med lav iterasjonsfriksjon

Målet er ikke nyhet. Målet er å tildele hver lagringsmotor til sin optimale arbeidsmengde.

Sikkerhet og QA som designinndata, ikke oppryddingsarbeid

Oxides QA-tilnærming er ikke ettermontert:

  • Typede grenser håndheves gjennom TypeScript og Zod
  • SQL-utførelse for brukerinndata-analyse er begrenset til validerte skrivebeskyttede utsagn
  • Feilhåndteringsveier er eksplisitte og feiler høylytt i stedet for stille
  • Arkitektur-begrensninger dekkes av tester, inkludert lag-valideringssjekker som beskytter importretning og sikkerhetsregler
  • SSE-kanaler inkluderer begrensede ressurskontroller

Prosjektet har et høyt antall tester på tvers av ruter, services, WASM-integrasjoner og arkitektur-begrensninger. Den disiplinen er ikke valgfri i en arkitektur som spenner over nettleser, edge og kompilerte moduler.

Hvor denne stacken passer godt

Bruk denne arkitekturen når du trenger:

  • server-rendret arkitektur med hypermedia-drevne interaksjoner
  • portabel edge-runtime-oppførsel
  • deterministiske høyytelseskjerner
  • mindre og mer reviderbare klientflater
  • gradvis kapabilitetsvekst uten rammeverkslåsing

Vær forsiktig når kjerneproduktet ditt fundamentalt er:

  • offline-først med komplekse lokale tilstandsgrafer
  • tung klientbasert visuell redigering
  • dypt tilstandsfulle interaksjoner som virkelig krever en persistent klientapp-runtime

I disse tilfellene kan en SPA eller hybrid-shell være den riktige beslutningen.

En praktisk adopsjonsvei

Team trenger ikke å skrive om alt for å bruke denne modellen. En realistisk sekvens er:

  1. Flytt én høyverdi-interaksjon til HTMX delvise oppdateringer
  2. Introduser Hono for en avgrenset ruteoverflate
  3. Porter én hot-path-funksjon til WASM
  4. Legg til eksplisitt ytelsesfangst (wasm_ms, js_ms, speedup)
  5. Legg til arkitekturtester for å beskytte grenser

Dette skaper målbare gevinster uten en plattform-tilbakestilling.

Det strategiske poenget

Rammeverks-utskifting er ikke kjernerisikoen. Koherenstap er.

Hvis stacken din fortsetter å mangedoble bevegelige deler, blir leveransesystemet ditt til slutt flaskehalsen. Oxide viser et levedyktig alternativ: slanke UI-semantikker, portabel edge-rutering, kompilerte beregningskjerner og disiplinerte databaner.

Målet er ikke å være anti-rammeverk. Målet er å være pro-klarhet, pro-kontroll og pro-endring.

Det er det full-stack-team bør optimere for i 2026 og fremover.

Appendiks: AWS-formen av denne stacken (ECS Express Mode)

Plasseringsvalgfrihet er bare reell hvis du faktisk kan plassere den samme stacken et annet sted. Oxide kjører Hono på Cloudflare Workers i dag. Det parallelle spørsmålet de fleste CTOer nå står overfor er: hvordan ser denne formen ut på AWS, uten å starte et plattform-engineering-prosjekt?

I 2026 er det ærlige svaret Amazon ECS Express Mode. Det er ikke en ny beregningsplattform. Det er et forenklet distribusjonslag oppå ECS og Fargate som provisjonerer de omkringliggende produksjonsprimitivene for deg — ECS-cluster og service, task definition, Application Load Balancer, autoskaleringsregler, en standard Route 53-basert URL, CloudWatch-logger og nettverkskomponenter. Standard-bootstrappen er bevisst liten: et container-bilde, en task execution role og en infrastruktur-rolle.

Hvorfor det passer HTMX + Hono

Arbeidsmengden Express Mode er designet for — tilstandsløs HTTP, én tjeneste, server-rendret, moderat kompleks — kartlegges rent på en HTMX + Hono-app. Hono kjører greit som en helt vanlig langvarig server i en container (Bun eller Node), som er formen Express Mode forventer. HTMX har ingen bundle-split-koreografi å orkestrere. Du får forutsigbar forespørsel-respons-oppførsel med fornuftige produksjonsstandarder, ikke en innboksa abstraksjon.

Det er derfor AWS nå peker App Runner-brukere mot ECS Express Mode. For denne klassen arbeidsmengde er det etterfølger-veien.

Hva det gir deg

  • Fjerning av seremoni. Du setter ikke sammen cluster, service, ALB, autoskalering og helsesjekker for hånd bare for å levere en web-app.
  • Kanarie-distribusjoner med alarmbasert rollback. Dette er meningsfullt bedre enn "bytt containeren og håp på det beste."
  • En rømningsluke som er reell. Underliggende ressurser forblir i kontoen din, forblir synlige, og hele ECS-funksjonssettet er tilgjengelig. Det finnes ingen graduering-migrering fordi du alltid var på ECS.
  • Kostnadskomposisjon. Ingen ekstra avgift for selve Express Mode; du betaler for Fargate, ALB, CloudWatch og datatrafikk. ALBer kan deles på tvers av flere Express Mode-tjenester med samme nettverkskonfigurasjon.
  • Ekte infrastrukturverktøy. Konsoll, CLI, SDKer, CloudFormation og Terraform — ikke bare en veiviser.

Hva det ikke løser

  • Det er fortsatt ECS + Fargate under. Enkelheten ligger i orkestreringen, ikke i kostnadsgulvet. For svært liten eller svært varierende trafikk kan Lambda fortsatt være billigere.
  • Skjevhet mot tilstandsløs HTTP. Designet for web-apper og APIer. Tilstandsfulle mønstre, uvanlig nettverk eller ikke-web-prosessformer argumenterer fortsatt for rå ECS.
  • Rømningsluka er også en styringsrisiko. AWS er eksplisitte: hvis du modifiserer underliggende ressurser med standard AWS-APIer, validerer Express Mode ikke om endringene kolliderer med styringsmodellen. Disiplinerte team bruker dette godt. Kaotiske team skaper halv-styrt infrastruktur med uklar eierskap.
  • Standarder produksjonsteam vil stramme inn. Log-grupper opprettes uten utløp. Produksjonsarbeidsmengder drar nytte av tre-AZ-spredning. Utgående restriksjoner, WAF-tilknytning og ALB-helsesjekk-tuning må typisk legges til direkte.

Et beslutningssignal, ikke en matrise

  • Foretrekk Cloudflare Workers (Oxides nåværende standard) når edge-native plassering, nær-null cold starts og samlokalisering med D1 og R2 er kjernen i produktet.
  • Foretrekk ECS Express Mode når appen er en enkelt tilstandsløs HTTP-tjeneste, AWS er en strategisk begrensning, og du vil ha produksjonsstandarder uten å bygge plattformen først.
  • Foretrekk rå ECS på Fargate når plattformens form er en del av produktarkitekturen, ikke et implementasjonsdetalj.
  • Foretrekk Lambda + API Gateway når trafikken er genuint liten eller svært variabel og en langvarig Hono-server ikke er et krav.

Den samme Hono-kodebasen kan målrette alle fire. Det er poenget hovedartikkelen gjør om plasseringsvalgfrihet — og ECS Express Mode er AWS-uttrykket av det.