Oui, c'est toujours un coût supplémentaire pour un gain minable.

Use UIs instead of writing code. Ok.

I don't believe this is the case. In my opinion, LLMs do not represent a layer of abstraction, but rather a layer of automation. It doesn't abstract away the code layer, it automates it.

I believe in the importance of making understandable software. To this end, I'm working on projects that further this goal.

Primarily, I develop ReTangled, an Entangled-compatible bi-directional tangler written in Rust. It's meant to extend literate programming as far as it can go while integrating it as tightly into existing toolchains as reasonable. As of writing, it's in the early stages of development. I welcome contributions!

https://codeberg.org/liberty/retangled

YAGNI is not an excuse to never design as some critics have characterized it. If you need it, build it. YAGNI is a meditation on timing. Building structure too soon is as risky as building structure too late.

First bill: optionality

1. When you build structure before the feature arrives, you're committing on a guess.
2. The feature you prepared for usually isn’t the feature that shows up.

Second bill: NPV

3. Money has time value. Structure you build now for a feature due in three months is cost pulled forward and revenue pushed back.
4. The bill comes due even when your guess is right.
5. The cost of typing the code is not even considered. What about maintenance?

Encore un kudo pour Fabrice Bellard, cette fois de John Carmack.

A way to create demo from UI components: create video in the browser directly, so the recordings can be changed, replayed or its speed can be updated.

The reason I will never go back: it is code, so it is repeatable. A stat is wrong? Change a number and rerun. A beat feels rushed? Nudge one timestamp. Want the same demo for four different products? Loop over four pages and render them all while you make coffee. There is no take to redo and no quality lost to another export.

It seems what the UI does can be a browser extension.

I lost my notes. The post explains a lot that is not considered while "only a translation". From the other specific translations: dates, expressions, name format, etc...

to the undergoing system to be maintained: a N+1 feature (each changes needs to be internationalized and localized accordingly), testing, user tests needs to be in other languages too.

Vendor the dependencies in the project directly. It will avoid to install the dependencies every time.

So just by not updating dependencies automatically, you turn every single package in an ecosystem into a fire-break for supply chain attacks.

A high-reciprocity copyleft license designed to close the SaaS, API, and Code Generation loopholes. If they use your code, they must share theirs.

instead of letting the call stack implicitly control what happens next (as recursion does), store the pending work in an explicit data structure such as a stack, queue, or heap. This turns control flow into ordinary data that can be inspected, paused, modified, or resumed.

Explicit stacks makes interruptions, limits, cancellation or interleaving work easier to work with. It's more adaptable to real-world constraints and test.

A stack (LIFO) produces depth-first search behavior.
A queue (FIFO) produces breadth-first search behavior.

Stop complaining, build as much as possible while you can do it for (almost) free, and enjoy the assets for the rest of your life. Code that you build today will still be usable and valuable in 10 years, and if you build stuff that let you reduce your expenses, you could retire early.

Wordpress ships HTML and CSS, then JS when needed. They got it right.

What WordPress couldn’t do, in the way I wanted it to, was give me direct control over what shipped to the visitor.

In WordPress, fast is a project. In Astro, fast is the default.

The five killer features of Astro are:

• zero JasvaScript by default
• bring your own component framework
• the file-based router and content collections
• MDX for blog posts
• Astro gets out of the way and disappear

The author built the Astro theme "Astro rocket" to have 100 score on Lighthouse https://astro.build/themes/details/astro-rocket/

hey there, welcome to my website!
i'm isabelle a.k.a 'cr1ttr' --- i'm a software, tool, and game developer.
i made this website to ramble and show the things i'm working on.

The website looks like a modern terminal. We can clearly see the influence of neovim and Ratatui, but the owner didn't post anything yet. It's a lovely place.

A personal brand website

Even the best have "No idea" for "Safety" at some places. Another one: https://github.com/rust-lang/rust-analyzer/blob/932186d9c2046257c0a1fc38c1cecf7bc19736c3/crates/hir-def/src/lib.rs#L536

There is an "// SAFETY: Come fight me" in the rust uuid crate :D

#todo #rss

The client is not a thin view requesting permission to show data. The client is a node in a distributed system with its own database.

It’s overkill for simple CRUD apps with no offline or collaboration needs.

But here’s where it shines: note-taking, document editing, collaborative design tools, project management, field apps with unreliable connectivity, basically anything where data privacy is a selling point, as well as anything with real-time collaboration.

One more thing I wish someone had told me earlier: you don’t have to go all-in. I’ve had the best results using local-first for specific features within otherwise traditional apps. Offline drafts in a blog editor. Real-time collaborative notes inside a project management tool that’s otherwise standard REST.

To do so: SQLite in the browser via WebAssembly; persisted to the Origin Private File System (OPFS). The author describes the method used.

To avoid conflicts: CRDT. Yjs exists. There is also Automerge and the newer Loro.

To grasp the data: replicate rows via database replication.
PowerSync does this well from Postgres to SQLite.
Triplit is a full-stack database with sync built-in.
LiveStore use an event-based approach.
TinyBase for prototyping or small apps.
PGLite (Postgres compiled to WASM) but it has a significant bundle size and memory footprint for mobile browsers.

Often the last-write-wins (LWW) is the best strategy at the field level.
For a document body, CRDT should be used.
To book a meeting, one must verify there is no other meeting booked by someone else. " The approach I’ve landed on (after getting it wrong twice) is: validate on the server during the write-back phase, but flag violations rather than silently rejecting them. When the client pushes mutations to the server during sync, the server runs them through a constraint validation layer before applying them to Postgres". See the example.
The conflict should then be resolved by the user.

For something like inventory management where two people “buy” the last item, that window is unacceptable, and that’s exactly why I said earlier that local-first is wrong for systems requiring strong transactional consistency.

Conflict resolution works well for texts with CRDT.

See such app architecture: https://www.smashingmagazine.com/2026/05/architecture-local-first-web-development/#building-a-real-app-architecture-auth-and-migrations

Example of E2E (local, on device) encryption for https://anytype.io/

One thing to consider is migrations: Design your migrations to be additive. New columns with defaults. New tables. Don’t rename or drop columns unless you absolutely must, because users running old app versions will still be syncing data, and your server needs to handle the mismatch. I learned this the hard way when I dropped a column that an older client was still writing to, which caused silent sync failures for about 200 users over a weekend.

Performance are awesome (< 10ms for read or writes). The initial sync is where the cost occurs.

The architecture can be tested with Playwright and context.setOffline(true).

I’m excited about where this is going. PGlite (full Postgres in the browser) feels like a glimpse of a future where the client/server data layer distinction just dissolves. You write SQL, it runs everywhere, sync is a runtime concern rather than an architectural decision. We’re not there yet, but you can see it from here.

There is also no standard for a sync engine. Migrating away a sync engine is not trivial. I’m also worried about the complexity budget. Local-first adds real architectural complexity: sync engines, conflict resolution, client-side migrations, partial replication, and auth at the sync boundary.