i'll go first. i was writing .then().catch() chains for like two years before i actually started using async/await. i knew it existed, i'd seen it in tutorials, but my code "worked" so i never bothered switching. then i refactored an old project and realized half my bugs were from mishandled promise chains that async/await would have caught immediately.

also took me way too long to start using optional chaining. i had nested ternaries and && checks everywhere like some kind of animal. the day i discovered user?.address?.city i mass-replaced like 40 lines across a project.

what's yours?

This is not about UI, read more if you are into DAGs, Declarative Programming, or if you just like to do things differently

Hey Community,

We explore Grok Build, the new terminal-based TUI coding agent from x.ai. We also look at Appless, an experiment from the creators of OpenUI that bypasses chat bubbles to stream live native UI components using openui-lang.

Finally, we dive into Maestro MCP, a new tool context protocol server that lets AI agents automatically build and run YAML test flows from plain English instructions.

If the Rewind made you nod, smile, or think "oh… that's actually cool" — a share or reply genuinely helps ❤️

I'm building a web platform for visual novels made in Godot. Stack: SvelteKit, Vite 8, rolldown, Node.js.

The games are compiled for web and injected as static assets at build time, then deployed together with the app. And they're heavy: ~20 MB of wasm plus ~150 MB of pck per game.

My builds were taking ~5 minutes, which felt wrong. After some profiling it turned out the actual bundling takes ~10 seconds. Everything else was precompressing all that static into gz, br and zstd with node:zlib.

So I wrote a rolldown plugin that does the compression in native Rust via napi-rs:

• rayon to saturate all CPU cores
• native compression libs instead of node:zlib bindings
• full LTO + codegen-units = 1, which alone made it ~2x faster than node:zlib
• then PGO + BOLT on top, squeezing out another ~10%

Everything is built automatically in a GitHub workflow and shipped to npm already optimized, no compilation on install.

Real project results (measured with time on an actual project with games):

before: npm run build 639.62s user 5.84s system 235% cpu 4:34.06 total
after: npm run build 527.60s user 5.23s system 784% cpu 1:07.95 total

If you're precompressing large static assets in your build, give it a try. Happy to answer questions about the napi/rayon/PGO setup.

Covering the main ways Date misleads you in production: parsing, mutation, 0-based months, timezone/DST, arithmetic, and serialization, with safe patterns for code that can't migrate yet, and a practical look at where Temporal fixes the design rather than just the syntax.

I've been using TypeScript professionally for several years, and recently wrote up some lessons learned from a long-running React/Firebase side project.

The article covers the TypeScript patterns that ended up giving me the biggest return, along with a few mistakes I'd avoid making again. These aren't intended as universal rules, just approaches that worked well for this particular project and the problems I was solving.

If you're a JavaScript developer who's moved to TypeScript (or is considering it), I'd be interested to hear which patterns have been most valuable for you as well.

Recently, I noticed there is no proper s3-fifo implementation in NPM.

s3-fifo is highly efficient cache algorithm, especially for "one-hit-wonders" case such as web traffics. It is specialized when cache coverage is under 50%. (like, whole DB is 100% and cache contains 50% of data)

The famous "lru-cache" package is almost default for nodejs ecosystem I think, and I thought it would be great if there is good alternative choice for caching.

My goal was:

1. Faster or at least same throughput performance compared to lru-cache

2. Much higher cache hit rate than lru-cache

bold, right?

It was fun enough just for challenge itself.

But it was actually achieved! I used bunch of optimization skills like pre-allocation, lazy eviction, bitwise tricks, ring structure and etc... you can see bench result in repo or NPM page.

It is just v0.1 for now, so I would LOVE to get your harsh feedback, advice, or even contribution!

NPM page

Super thanks for reading!

----

I typed almost of the code by my hand. Not because I don't believe AI, but it was all about concepts and decisions. Typing by hand was fastest way to understand what I'm doing correctly. And it was fun.

I used AI(gemini) for test codes, some advices and polishing when most of things were done.

Though it requires quite new ES2024/ES2025 features, it works very well for numeric types, also faster (not drastically, but modest gains) against Array in PACKED FIXED ELEMENT TYPES representation used under the hood by engines.

.NET WebAssembly apps with WasmBundlerFriendlyBootConfig=true can indeed be bundled by modern JS bundlers and I personally love it. The development experience however is not optimal.

• The bundlers cannot consume the output from dotnet build
• The bundlers can consume the output from dotnet publish but the dev loop is painfully slow.
• Getting the publish path working still requires bundler surgery
• Once it works the bundler produces warnings that are impossible to fix without changing the source files produced by the WebAssembly SDK.

These points of friction are why I have made unplugin-dotnet-wasm.

It's a bundler plugin that lets your bundler consume the output from dotnet build so your dev loop stays fast. It also supports dev servers, provides type information to TypeScript and IDEs (integrates dotnet.d.ts thats coming in .NET 11), and patches the known warnings so your build output stays clean.

Features

• Easy bundler setup through plugin registration
• Faster dev loop by consuming .NET WebAssembly dotnet build output
• Dev server support
• Brings SDK type definitions to TypeScript and your IDE
• Supports Vite, Rollup, Rolldown, Webpack, Rspack, Rsbuild, esbuild, farm and bun.

I hope you'll give it a try, I'd be happy to hear your feedback.

This is a free/non profit unapologetically claude code vibe-coded project; the approach is explained here: https://lia.jeyswork.com/story

If you like it, please don't hesitate to show your support with a star on GitHub!

LIA acts as a true personal assistant. It is proactive, featuring its own distinct personality and a complex emotional system, an evolving structured memory, its own reflective memory of your conversations, and all the standard tools (image creation/editing, RAG, skills, MCP, scheduled tasks, etc.)—all wrapped in a seamless "one-click" interface (details here: https://lia.jeyswork.com/why).

I paid special attention to code quality and documentation, treating it exactly like a professional enterprise-grade project. This ensures that anyone can easily take ownership of the source code and build upon a clean, robust, and highly scalable foundation (details here: https://lia.jeyswork.com/how).

On another note, once self-hosted, it can double as a family AI server. As an administrator, you have full control to manage and monitor the API consumption of your family members, friends, etc.

Full details are available on the landing page: https://lia.jeyswork.com/

And the GitHub repository: https://github.com/jgouviergmail/LIA-Assistant