Today, I checked the date of the first commit to my personal framework.

It was made in August 2022 – over 4 years ago!

I've never made any money from it. I simply enjoy developing and maintaining something of my own. And it still works great!

Every new website I build is powered by it.

Ps: It's not a project aimed at an audience. I build it purely for myself.

If you have something like that - please share.

As far as I understand, the tc39 decorator proposal is already implemented in most engines. But didn't see any framework elaborating this feature.
Any real world usage out there?

Staxis is coming. The first preview of the website is live. Staxis is a modular toolkit for Node.js. Start with the free Core, assemble your stack with Layers Packs, or build your own layers.

We’re getting the first pages of the official documentation ready as we work toward the Kickstarter campaign and the 1.0 release. If you’d like to help us get there, you can already support or sponsor the project.

Take a look → https://staxis.dev

One encrypted file with named secrets for a Node.js app, plus a CLI to manage it.

You keep app.safebox next to the app: in the repository, in the deploy package. The app opens it with a password it gets from somewhere else and has every API key, database password and private key it needs. Without the password the file is useless.

• AES-256-GCM with a key from scrypt, the whole file authenticated

• TypeScript source with only Node.js built-in modules, no runtime dependencies

• CLI as one bundled file, dist/safebox.js

• Status: beta (0.1.0-beta.1), the file format may still change before 1.0

Requires Node.js 22 or newer.

Personally, I'm really enjoying Hono. Its automatic endpoint inference is a big win. I previously enjoyed using Fastify with Zod Provider for OpenAPI schema generation, but Hono cuts that extra step and makes the workflow feel much smoother.

Curious what everyone else is using!

A follow-up to Nolan Lawson’s AI framework benchmark

I've already been using Lit for a while in JS and I see many places where they recommend using private _property = value so that it is more readable, even though it does not really make it private.

Others recommend using #property = value because it makes it private so that if you try to use it from outside the scope it throws an error. But I still see places where they don't like using this.

I don't really know what should I use or if it doesn't really matter.

A small experiment you can paste into Node or a console:

const a = new Date("2026-03-10");
const b = new Date("2026-03-10T00:00");

console.log(a.toISOString());
console.log(b.toISOString());
console.log(a.getTime() === b.getTime());
console.log(a.getDate(), b.getDate());

I ran it in Node 22 with the TZ environment variable set to four zones:

What’s going on: per the ECMAScript spec as I understand it, a date-only ISO string is parsed as UTC, while a date-time string without an offset is parsed as local time. So the first is always midnight UTC, and the second is midnight wherever the code runs.

Where it bites:

• In zones behind UTC (like the Americas), a.getDate() returns the previous day, because the local getters convert from UTC midnight. A “date of birth” or “due date” can display as one day earlier.

• On a dev machine set to UTC the two agree, so tests pass locally and the bug shows up only for users elsewhere (or on a CI box with a different zone).

• In my run, new Date("2026/03/10") and new Date(2026, 2, 10) behaved like the local-time form. Slash-separated strings aren’t standard ISO, though, so I’d not rely on them being consistent across engines.

Ways to avoid it:

• If the value is a calendar date and not an instant, don’t store it as a Date at all. Keep "2026-03-10" as a string, or as year/month/day numbers, and format it without converting.

• If you need a Date, be explicit: new Date(Date.UTC(2026, 2, 10)) and read it back with the getUTC* methods, or always include an offset ("2026-03-10T00:00:00Z").

• For testing, run your suite under a few TZ values, as above, rather than only on your own machine.

• The Temporal proposal is designed to separate dates from instants. I haven’t checked its current status in each runtime, so look at the compatibility tables before depending on it.

Caveat: my results are from one Node version. Browsers should follow the same spec for the ISO forms, but test where it matters.

How do you represent calendar dates (not timestamps) in your codebases: strings, a library, or something else?

Hi r/javascript. I’ve been using Angular since the AngularJS and the Angular 2 betas. When ByteDance created Lynx, I really liked it, but it only came with React and Vue. So it's time for an Angular one to exist!

The aim is for it to be ordinary idiomatic Angular, not a subset or deviation, and it follows Angular's major.minor versions:

npm create angular-lynx my-app
cd my-app
ng serve # web preview, plus a QR code for the Lynx Explorer app
ng test
ng build --platform ios # or android: a native app you can open in Xcode / Android Studio

Signals, the router with lazy routes, forms, i18n, DI, ViewContainerRef.createComponent() and Tailwind all work. It idiomatically uses the Angular Router for the page stack, so there are no extra concepts. The one big difference is the templates: you write Lynx's elements (<view>, <text>, <scroll-view>) instead of HTML, and they become real UIView/Android views. The same app also runs in the browser.

How it works: Lynx has two threads, a main thread that owns the native element tree and a background thread. Instead of Angular's DOM renderer, AngularLynx implements Renderer2 on top of Lynx's element API (__CreateElement, __AppendElement, …), and the Angular app runs on the main thread, so updates go straight to the elements without crossing threads. Things that only exist on the background thread (native modules, fetch) are relayed. The build is an Rsbuild plugin that compiles Angular and splits the output into the two bundles Lynx expects, wrapped in Angular CLI builders so angular.json stays the usual one.

There's also a component library, Dolan UI: 54 components (sheets, dialogs, charts, forms…) that a CLI copies into your app, like shadcn/ui.

It's still early days, but it is feature rich, with a lot of examples and showcase apps. Lynx's main-thread JS engine is ES2019-level, so newer built-ins are polyfilled, and some web habits don't carry over (CSS is a subset: no inheritance outside text, no :hover or @media).

MIT licensed. The README has a GIF of the same app on iOS, Android and web. I'd love to hear what breaks, and I'm happy to go into the renderer internals. Please give it a star! It would mean the world if this takes off!

GitHub: https://github.com/Blotch-Smart-Frames/AngularLynx
Docs: https://angularlynx.js.org
Demo GIF: https://angularlynx.js.org/demo.gif

I've been exploring Phoenix LiveView lately, and it got me thinking.

We've spent years moving more state and logic into the browser. But what if we kept most application state on the server and used JavaScript mainly for rich interactions?

I'm not talking about replacing JS. Libraries like Monaco, AG Grid, and Chart.js are great and I'd absolutely want to keep using them.

Curious what frontend devs think. Would you consider a server-driven approach if you could still use your favorite JS libraries, or is there too much downside?

I have a free image-to-text tool that runs Tesseract.js in the browser (nothing gets uploaded). Screenshots worked great, 94-96% confidence. Then I took a phone photo of a kids' sunscreen bottle and got back lines like "v4 oR. a" and "EB ewraone".

What was actually wrong:

1. The photo was sideways. Phones save the pixels rotated and add an EXIF tag saying "turn this 90°". Browsers obey it, Tesseract doesn't. Fix: createImageBitmap(file, { imageOrientation: 'from-image' }) and work from that canvas.

2. White text on blue. Tesseract mostly expects dark text on light paper. I now make a grayscale copy with a contrast stretch plus an inverted copy, and read those with page segmentation mode 11 (sparse text) instead of the default.

3. No single pass gets everything. The normal pass found "Diana", the inverted one found "UVA UVB PROTECTION", the color one found "Water Resistant". So I merge the words by bounding box, keep the confident ones, and boost words that two passes agree on. Fun bug: picking the most confident word gave me "Pea" instead of "Peaceful", so longer words get a small bonus now.

4. Small print. Running the gray passes again on a 1.6x upscaled copy picked up "MOISTURISING" and "ALCOHOL FREE" on another bottle.

Result on the sunscreen: 92% confidence and every line of printed text. Screenshots skip all of this because the first pass is already confident, so they're not slower.

Still can't do: bubble fonts ("CUDDLES" comes back as "UDDLES"), script fonts, handwriting.

Has anyone found a better approach for mixed light/dark text in one image than running multiple passes? Curious what others do.

This is the resize animation of Openbar's island on Windows (Tauri + React). The Mac app is SwiftUI, so I ported its spring math to get the same feel on both. Width and height each get their own spring: a growing side may swing past its target, capped at 12 px, and a shrinking side never does.

The app shows Claude Code and Codex sessions in a Dynamic Island. Free, GPL.

Did you find or create something cool this week in javascript?

Show us here!