kadajett

blECSd is a terminal UI library for Node.js where every UI element is an entity. Position, rendering, focus, animation are all plain data in typed arrays. Systems are pure functions that process that data each frame. The same architecture that renders a dashboard with form controls can also run physics-based animations, particle effects, or a Doom source port in your terminal.

The project started as a functional rewrite of the 11-year-old Blessed library. The majority of the code was written by Claude Code as a direct rewrite, with the non-vibe-coded work concentrated in the performance layer and Kitty graphics protocol support for the Doom demo. It was a full week of thousands of tests, examples, and rebuilding tools I'd previously written in Ink and open-tui.

What's in the box: 18 widgets (panels, tabs, tables, trees, virtualized lists), 7 form controls, 32 ECS components, collision detection, state machines, and a 3D rendering subsystem with five backends (braille, half-block, sextant, Sixel, Kitty). 10,234 tests across 256 files.

The performance is where it gets interesting. Instead of building on React and fighting memory issues, we leaned into game dev data structures. The hot paths all run on PackedStore, a dense array using the three-vector pattern (data[], dataIndex[], id[], generations[]) for O(1) swap-and-pop with cache-friendly iteration. Systems like spatial hashing went from 4 Map lookups per entity per frame to 1 packed lookup. Scroll physics, dirty rect tracking, collision detection, particle systems, visibility culling all iterate dense arrays instead of pointer-chasing through hash tables.

It's a library, not a framework. You own the world and the update loop. Every function takes world as a parameter. Use one widget or all of them. Works with workers in parallel environments. Written in strict TypeScript, purely functional (no classes), with Zod validation at boundaries.

The vibe coding ratio is honest: LLMs are great at cranking out the 50th widget following an established pattern. But the data layout decisions, the PackedStore design, and figuring out which stores actually need dense iteration vs point lookups required thinking about the problem. The createComponentStore<T>({ iterable: true }) API came out of that, a Map-compatible wrapper that lets you swap backing stores with one flag.

- GitHub: https://github.com/Kadajett/blECSd - npm: https://www.npmjs.com/package/blecsd - Examples: https://github.com/Kadajett/blECSd-Examples

I have been writing JS code for a long time. NestJS isn't my first choice in backend languages these days, but after I spent the last few months rewriting some services in it, I think I ran into about every foot gun there is with NestJS specifically.

I started writing this when I was having Claude review non-vibe coded apps I was rewriting, or building to study. As I ran into more frustrations, I added new notes.

Then, when vercel released their best practices, I loved the format so much, both for people to read, and for claude to review with, that I turned my chicken scratch (and some additional docs) into a NestJS skill for Claude.

Feel free to file issues, submit PRs, etc. Hopefully this makes Claude a little less bad for you as well.

I would recommend learning NodeJs with your current skillset. But for a restful library, I would prefer Koa compared to express. It brings in a lot of the es6 spec, so you are kind of future proofing yourself.

I use ghost.

a. I have been running blogs for a few years now, but just recently was happy with the feature set of Ghost.

b. I am a front-end engineer, so it made sense to find the thing that I have the most control over, as far as javascript functionality.

c. There is the new AI blogging system, but that is more of a try and walk away scenario. I would have little control, so it has no use in the long run.

d. The back-end is open source in nodeJs. This isn't necessarily the best backend language they could have used, but I know how to make changes so it is the best for me. With that, it is completely extendable. You don't like the tagging system, bring in your own. Want comments? You have like ten different pre-built options, or you can write your own with firebase or any other technology. I could go on forever, but you get the point.

e. I am not sure if I hate anything, but their default rendering/routing system is a little janky. I would prefer angular, as it has a little more finesse.

f. Not really, I had read through all of the documentation and GitHub issues before ever starting, which I would recommend doing for all technology.

It is a solid option if you have javascript experience, but there are many other options, including just writing your own. With things like loopback, and AngularJs Backbone/Marionette, and EmberJs, the ability to build something as simple as a blogging system is like a week long affair at most. Especially if you ignore things like user-defined templates, and any other feature that would make more sense in a SaaS CMS.

You can see the blog up now, if you disregard the URL. I just started a new job, and need to wait a paycheck or two to buy a new domain. It is sitting on an old one I bought for a now deceased project. http://compendiumjs.org