Hyeseong Kim

Hyeseong Kim

@hyeseong.kim

Integration engineer / Open source hitchhiker / DX enthusiast @rescript-lang.org committer

882 followers435 following239 posts

Hyeseong Kim reposted

Spaces like @e18e.dev, where maintainers can gather, share their journeys, and collaborate, are more important than ever. Hats off to everyone who keeps making the e18e community such a special place in the ecosystem. And the same to all of you who are out there building bridges between oss projects

James@43081j.com

A new text encodings library, iconv-nano, was posted in the @e18e.dev discord. A day later, the author (Jeremy) is collaborating with @hyeseong.kim on making it ~80% smaller! 🤯 Always impressed by how e18e has managed to join up people with knowledge in such niche subjects 😄

Hyeseong Kim reposted

A new text encodings library, iconv-nano, was posted in the @e18e.dev discord. A day later, the author (Jeremy) is collaborating with @hyeseong.kim on making it ~80% smaller! 🤯 Always impressed by how e18e has managed to join up people with knowledge in such niche subjects 😄

Hyeseong Kim reposted

ECMAScript excitement 😉 Congrats to @peet.bsky.social from TechAtBloomberg advancing JSON.parse Options to Stage 2.7 at @TC39 today 🎉 There are two independent opt-ins. 🔶 deep freezing the entire object 🔶 non-array objects get a null prototype Names may change ⚠️

Hyeseong Kim reposted

we're changing tpuf's storage architecture so we can keep pushing the search frontier the new engine (v3) now passes CI, but we have to make it fast before we ship it to prod we're grinding query plans in public until v3 wins on everything follow along: turbopuffer.com/v3

Hyeseong Kim reposted

ECMAScript excitement 😉 Congrats to @ashley-c.bsky.social from TechAtBloomberg on advancing the Composites proposal to Stage 2 at @tc39.es today 🎉 Composites are objects that are compared by value instead of identity. They are an evolution of Record & Tuple proposal.

Hyeseong Kim reposted

Preact 11 is out 🎉 We’ve been hard at work at making our diffing use modern features like moveBefore , leveraging ESM for tree-shaking Preact Compat and ensuring you have a great experience with resumed hydration.

Hyeseong Kim reposted

I thought I’d have some breathing room right after leaving my job, but my home setting is taking a huge amount of time. I'm not sure if I'll be able to finish everything in this month.

Hyeseong Kim reposted

DwarfStar running DeepSeek v4.1 Flash on a 128GB M5 Max at steady 15 t/s. I didn't expect with SSD streaming it could be so fast. Recent SSD streaming changes to retain the right experts surely helped, but also maybe DS4.1 uses the same experts more. Will push online when ready QA > ASAP.

ulottie compiler is now SSR-ready, which means the compiler can extract the initial frame as a static markup. (even it includes dynamic bodymovin expressions) Your Lottie animation can be in the initial document, and the client side script only hydrates.

Who said that interface files are no longer needed? Writing interfaces yourself and delegating implementation is a great method to collaborate with your agent.

Hyeseong Kim reposted

Z AI's GLM-5.3: Built to Code. Ready for Cyber Defense. (open-weight soon) - Top-tier coding and agentic capabilities, achieved through post-training on the 743B base model - A major leap in cybersecurity, setting a new standard among open models z.ai/blog/glm-5.3

Hyeseong Kim reposted

Today we’re launching Bluesky Protocol Services, a new brand and website for the infrastructure Bluesky operates. And Jetstream v2, the best way for developers to use atproto at scale, now with network replay. atproto.com/blog/introdu...

atproto.comIntroducing Bluesky Protocol ServicesA new home for the infrastructure Bluesky runs on the open network — including Jetstream v2 with network replay, a new Jetstream SDK, and a lex-based TypeScript SDK

Umm, it seems Claude doesn't really like the AOT approach. It keeps resisting it, calling it an overcomplication, and arguing that runtime dispatch is a simpler solution. Of course, that is true... but it wasn't what I wanted.

Hyeseong Kim reposted

Astro 7.2 is out now! Experimental incremental static builds are here: only re-render the pages that actually changed and watch your build times drop. Plus opt-out session support, background astro preview, and relative logger entrypoints. astro.build/blog/astro-7...

astro.buildAstro 7.2 | AstroAstro 7.2 adds experimental incremental static builds, an option to opt out of session support, background mode for astro preview, and relative logger entrypoints.

We all need to care about memory usage for sure. Especially JS libs. If you focus too much on CPU-centric microbenchmarks, there is a very high chance that you will accidentally over-allocate and retain objects/buffers.

James@43081j.com

had another good chat about @e18e.dev and what the community has been up to. check it out! 🎉 big thanks to @josh.bressers.name for having me along and for the good conversation 🙏

It is important to note that while it is not included in heap use, the code text itself allocates memory. The same applies to JIT compilation. Codegen and eval() are popular optimization tricks, but if misused, they spam gigabytes of duplicate text on the host and never release.

Hyeseong Kim reposted

Hyeseong Kim reposted

An enormous amount of the world’s CI and automation runs headless Chrome, all of it on x86—until last week. Chrome now ships official arm64 Linux builds. AWS says Graviton uses up to 60% less energy for the same performance. Chrome for Testing coming soon 🥳 calibreapp.com/blog/chrome-...

calibreapp.comChrome lands on arm64 | CalibreGoogle has shipped official arm64 Linux builds of Chrome. Here’s where to get them, and why it’s good news for anyone running browser automation.

Hyeseong Kim reposted

Cloudflare OS is an open-source platform that lets everyone in your company build apps, automate work, and safely access internal systems, shaped around what your organization knows and how it operates. https://cfl.re/4fGBl0w

blog.cloudflare.comCloudflare OS: an open platform for agents, apps, and workCloudflare OS gives every person an agent and workspace built around their company: how it works, what it knows, and the systems it relies on.

Hyeseong Kim reposted

View full thread

Most animations, excluding embedded image data, are shipped at an average size 20x smaller. Compilers can fold static frames to compress them into much smaller data. And any part of the runtime that isn't used by the animation will be completely eliminated!

One major milestone is to fully extract the initial frame markup and embedded image data. This allows the compiled animation module to be mounted even in static environments such as SSR and enables optimized resource loading for web-friendliness.

The runtime architecture has been fully rebuilt to better leverage the compiler's capabilities. No more JSON. It evaluates the initial frame, pretty compact keyframe data, and statically bounded operations. Animations are powered by optimized loops over a linear data stream.

github.com/cometkim/rky... allows Rust's rkyv from/to JS applications. You can (zero-copy) deserialize wire messages sent from JS in Rust, or vice versa! Would be useful for JS-Rust interop projects, e.g., a Rust CLI with Cloudflare Workers, a web app with a Rust backend, etc.

github.comGitHub - cometkim/rkyv-js: An unofficial library to use rkyv (Zero-copy deserialization framework for Rust) in JavaScript/TypeScript projects.An unofficial library to use rkyv (Zero-copy deserialization framework for Rust) in JavaScript/TypeScript projects. - cometkim/rkyv-js

github.com/cometkim/uni... unicode-segmenter `countGrapheme` speedup by avoiding unnecessary allocation and iterator overhead. If you are using `Intl.Segmenter` simply to count numbers, you could consider this. It is almost 15-30x faster (varying depending on the input corpus).

github.comRelease unicode-segmenter@0.17.1 · cometkim/unicode-segmenterPatch Changes e94d203: Add collectGraphemes(input) API that collects grapheme clusters into an array directly. This is a fast version of [...splitGraphemes(input)], which is acually the most used...

After much effort, it seems I have approached the lower threshold of the library's bundle size. When I make the code smaller, its compressed size actually becomes larger.

Hyeseong Kim reposted