Bun 1.3.14, kas iznāca 8. jūlijā, pievieno iebūvētu attēlu apstrādes API (Bun.Image) un HTTP/3 atbalstu tīmekļa serverī. Abi risinājumi līdz šim prasīja ārējas pakotnes: sharp attēliem, trešo pušu QUIC bibliotēkas tīklam. Tagad to nav.
Runtaims ir rakstīts Zig valodā un balstīts uz WebKit JavaScriptCore dzinēju. Bun.Image metadatu nolasīšana notiek 70 reizes ātrāk nekā ar sharp 0.34.5 — nozares de facto standartu attēlu apstrādē Node.js projektos.
Bun.Image: attēlu apstrāde bez natīvām atkarībām
Bun.Image atbalsta JPEG, PNG, WebP, GIF un BMP visās platformās. macOS un Windows papildina ar HEIC, AVIF un TIFF. Nav vajadzīgas nekādas natīvās bibliotēkas — sharp savukārt ir atkarīgs no libvips, kas Docker konteineros un CI/CD vidēs nereti rada problēmas, jo bāzes attēls atšķiras no izstrādes mašīnas.
Ātrdarbības salīdzinājumi ar sharp 0.34.5, ko Bun komanda publicēja Bun blogā:
- Metadatu nolasīšana: 70× ātrāk
- 1080p PNG → 400×400 JPEG: 1,38×
- 4K JPEG → 800×450 JPEG: 1,27×
Metadatu ātrums ir tik liels tāpēc, ka Bun to nolasa bez pilna attēla dekodēšanas. Resize ātruma starpība ir mazāka — abas bibliotēkas izmanto efektīvus algoritmus pamata resize operācijām. Tur sharp dažos scenārijos joprojām konkurē.
Konstruktors new Bun.Image(ievade) pieņem faila ceļu, Blob, BunFile un S3File. Pēdējais nozīmē, ka S3 glabātus attēlus var apstrādāt bez lokālas lejupielādes — noderīgi tīmekļa pakalpojumos ar S3 kā multivides krātuvi. Apstrādes ķēde beidzas ar .encode({ format: "webp" }) vai .toBlob().
Metode .placeholder() atgriež ThumbHash izplūdumu kā data: URL — apmēram 400–700 baitu apjomā. Tas ir gatavs LQIP (Low Quality Image Placeholder) risinājums: mazs apjoms, pārlūks parāda izplūdumu, kamēr ielādējas pilnais attēls. Bun.Image.fromClipboard() nolasa attēlu no starpliktuves. Pilna dokumentācija atrodama bun.com/docs/runtime/image.
HTTP/3 ar QUIC: 2,7× lielāka caurlaidspēja
Bun.serve tagad atbalsta HTTP/3. Bun komanda salīdzinājumā ar HTTPS/1.1 iegūva 2,7 reizes lielāku caurlaidspēju savos testos. HTTP/3 darbojas uz QUIC transporta protokola (IETF RFC 9000), kas galveno starpību rada transporta slānī.
HTTP/2 uz TCP cieš no galvas bloķēšanas: viena zaudēta TCP pakete aptur visu straumi. QUIC darbojas virs UDP, kur katrs HTTP pieprasījums ir neatkarīga plūsma — viena pakete zaudēta ietekmē tikai to pieprasījumu, nevis visus pārējos.
HTTP/3 priekšrocība vislabāk redzama mobilajos tīklos un vietās ar augstu pakešu zudumu. Stabilā Ethernet vidē starpība ir mazāka, bet reālos interneta apstākļos — īpaši mobiliem lietotājiem — QUIC bieži samazina konkrēto latentumu.
Vienlaikus iekļauts izmēģinājuma HTTP/2 klients — piemērots testēšanai, bet nav atzīmēts kā stabils. HTTP/2 klienta pilna stabilitāte paredzēta nākamajā laidienā.
Ātrāka instalācija: globālais virtuālais krātuvs
Bun 1.3.14 ievieš globālo virtuālo krātuvi. Pakotnes glabājas vienā centrālā vietā, bet projektu node_modules saņem symlink saites uz šo krātuvi. Siltā instalācija kļūst līdz 7 reizes ātrāka, jo Bun nevajag kopēt failus — tikai atjaunināt saites.
pnpm lietotājiem pieeja šķitīs pazīstama: content-addressable store ir pnpm pamats kopš trešās versijas. Bun to dara iebūvēti, bez papildu konfigurācijas. Jaunums iespējojams ar --global-cache karogu vai bunfig.toml iestatījumu. Reāls ietaupījums galvenokārt redzams monorepos — vairāku projektu krātuvēs ar kopīgām atkarībām.
Windows atbalsts un procesu pārvaldība
Bun.Terminal tagad pieejams Windows, izmantojot ConPTY saskarni. Tas ļauj Bun skriet interaktīvas CLI programmas, kas gaida pilnīgu terminālim atbilstošu izvadi. Iepriekš šī funkcija bija tikai macOS un Linux.
Jauns karogs --no-orphans automātiski pārtrauc apakšprocesus, kad galvenais process beidzas. Bun 1.3.x agrāk atstāja šos procesus dzīvus, kas radīja resursu noplūdi ilgās sesijās ar bun run dev. Pilna versiju vēsture pieejama Bun GitHub releases lapā. Jaunināšanai pietiek ar bun upgrade.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.