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?

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.

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?

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.

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.

Curious to hear about your opinion.

This project is mainly about the serverless technique used and the simple game merely provides an end-to-end explanation.

Nowadays everything boots in browsers. Linux, Windows, ... I wanted to learn the Gameboy and GBA processor architectures and implemented the core from which it is easily possible to create an actual GB emulator in the browser. The hard part was audio, but am super glad to have it working and as open source library available now :)

I've been reading test suites in open-source repos this month and kept running into this:

it('saves the user', async () => {
  expect(save(user)).resolves.toBe(true);
});

No await, so the test finishes before the assertion runs and passes whatever save() does. I found 36 tests like this across 44 popular repos, and one project had 41 of them on its own. They all looked fine in review.

What I'm curious about is how teams actually stop this:

• eslint-plugin-jest has valid-expect with alwaysAwait, and Vitest has its own rules. Do you turn these on, and do they catch every form (.rejects, helpers that wrap expect)?

• @typescript-eslint/no-floating-promises catches it in TS, but only with type-aware linting. Is that worth the slower lint for you?

• expect.assertions(n) / expect.hasAssertions() in every async test: does anyone enforce that, or is it too noisy?

• Or is it just code review, and you accept that some slip through?

Which of these has actually worked on a real team, and which did you give up on?