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.