Welcome 👋
쓰고싶은대로 포스팅하는 블로그입니다.
최근 포스트
모두 보기 →stax-xml v1 설계 노트 1: JavaScript에서 StAX를 다시 만든 이유
stax-xml의 출발점인 StAX 스타일 pull parser와 streaming writer, 그리고 대용량 XML에서 이 API가 성능과 편의성의 균형점이 되는 이유를 설명합니다.
stax-xml v1.0.0 설계 노트 · 1편 Project > stax-xml #stax-xml#XML#StAX#SAX#JavaScript#TypeScript
stax-xml v1 설계 노트 2: SAX API의 문제는 callback보다 깊다
SAX push API가 복잡한 XML 처리에서 상태와 제어 흐름을 어떻게 애플리케이션 callback으로 밀어내는지 살펴봅니다.
stax-xml v1.0.0 설계 노트 · 2편 Project > stax-xml #stax-xml#XML#SAX#StAX#Streaming#API Design
stax-xml v1 설계 노트 3: Node XML 생태계에서 찾지 못한 StAX 스타일 API
기존 Node XML 라이브러리와 async byte stream, typed object 사이에서 pull reader가 맡는 역할을 정리합니다.
stax-xml v1.0.0 설계 노트 · 3편 Project > stax-xml #stax-xml#XML#Node.js#Streaming#TypeScript#Web Streams
stax-xml v1 설계 노트 4: 가장 빠른 tokenizer를 버린 이유
Rust·napi-rs·SIMD로 만든 native XML tokenizer가 JavaScript object와 string 경계에서 장점을 잃고 결국 pure JavaScript보다 불리해진 과정을 회고합니다.
stax-xml v1.0.0 설계 노트 · 4편 Project > stax-xml #stax-xml#XML#Rust#Node.js#N-API#WebAssembly#SIMD#Performance
stax-xml v1 설계 노트 5: JavaScript string이 XML parser에 만드는 한계
immutable UTF-16 string과 V8의 내부 표현, native·Wasm 경계가 streaming XML parser 설계에 어떤 제약을 주는지 살펴봅니다.
stax-xml v1.0.0 설계 노트 · 5편 Project > stax-xml #stax-xml#XML#JavaScript#V8#String#WebAssembly#Performance