andersmurphy

It's nice to see HTMX4 is adopting the core strengths of Datastar. That sort of cross pollination of ideas is a huge boon to the wider hypermedia community in general.

A focus on morph by default means you don't have an explosion of endpoints and can write programs like the 300 redirect days. [1]

Once you want realtime/collaborative app SSE + morph lets you do that easily. Add streaming compression and this approach is suddenly crazy bandwidth efficient.

For people coming from react this gives you v = f(state) over the wire.

Lastly signals handle the edge cases where an out of bound morph would nuke your ephemeral client side state (mostly text input).

You can do this in htmx but you are fighting the design the whole way. Turbo is a bit better but doesn't have signals.

[1] https://dev.37signals.com/a-happier-happy-path-in-turbo-with...

My experience was similar. I'd wound down a startup and as a solo developer could no longer afford to do react + a backend. So I tried HTMX, then turbo (which introduced me to morph and push based re-fetch). Finally moved to datastar because I could drop alpine and it has best in class morph, signals and SSE support. Immediate mode over the network is amazing DX.

Makes multiplayer out of the box over large datasets trivial. See these demos if you don't believe me [1][2] (open them in multiple tabs and have fun)

[1] https://checkboxes.andersmurphy.com

[2] https://example.andersmurphy.com

RDS*

Sqlite with litestream has a smaller default window of data loss than RDF. 1s vs 5 minutes.

I would only recommend sqlite if you know what you are doing (and/or prepared to learn it inside out). It's more of a build your own database primitive (often you'll have multiple sqlite databases for different things). Which can be incredibly rewarding and deliver amazing performance outcomes, simple ops, etc.

I see the migration argument come up a lot. But, in practice with sqlite you'll be using projections where you have a source of truth database (event log) and project off it into disposable/expendable sqlite databases. So schema changes are often just delete and rebuild the projection.

Personally, I think the better way to tackle sqlite_busy is to have a single writer managed at the application level. That effectively eliminates sqlite_busy in the context of a single process.

> To ensure write operations don't suffer from disk synchronization bottlenecks, pair WAL mode with the following pragma

Only do this if you are prepared to sacrifice durability (i.e can afford to lose transactions).

> The bottom line

Is how Claude ends 90% of articles. So yes LLM slop.

Maybe maybe not. In large organisations for each person creating value with LLMs there are probably more destroying value. Bob used to only waste one person time with LLMs he can waste the entire organisations time.

Anyone can use an LLM make a bad ideas sound like a good idea. I imagine this will lead to insane amounts of productivity loss as the entire organisation ends up pivoting to follow the bad idea of a mediocre VP etc.

Philip Walder (one of the creators of Haskell) was our lecturer for my CS introductory course. I'd never done any programming before then.

Yes, imperative languages were initially counter intuitive to me. OO was even worse. SQL was fine as it's more declarative/functional.

Yeah compile times have always mattered. It's why games often have a scripting layer in lua despite the engines being C/C++.

Lisp/smalltalk programmers have been going on about this tradeoff for a long time. It mattered before LLMs too. Lisp/Clojure repl allowing you to compile tiny parts of your program inside your running program is incredible for your feedback/iteration loop.

Ironically, this is also what makes them shine with LLMs, the LLM has access to the running program and can modify it while it's running to get feedback instantly.

Complex type systems are cool. But, they are not free. I say this as someone who's first programming language was Haskell.

That's partly the problem ORMs. Lowest common denominator that prevents you from leveraging a lot of the power of your actual database.

Wait what? gpt5.5 is better than fable. I thought fable was the endtimes?!

Wonder if this is because fable swirches down to opus for somethings without telling you?

Neither of the companies you mentioned are listed.

Personally the main advantage of monoliths is performance.

Yeah, it's an intellectually intoxicating idea but incredibly hard to get right.

For me the problem is that in practice it only fits really well with quite a specific subset of problems, but we desperately want it to be a general solution that can apply to all the things (or at least it's often marketed that way).

> Generalization breaks down for offline-capable applications. Offline writes require conflict resolution, create authorization edge cases, and demand coordinated schema management across server and client replicas.

> ...These constraints are structural; engineering effort cannot remove them...

> The trade-off analysis shows that three sync engine vendors converged independently on this conclusion from different starting positions.

This is the big irony. That the vendors all converged on the fact that sync engines only really "work" when you remove the offline part. But, at that point they are a complicated/over engineered cache or worse introducing hard distributed computer science problems unnecessarily.

I honestly think streaming HTML is a game changer for collaborative realtime web apps.

I feel like independent thought will decrease considerably with LLMs. I wonder if they will effectively become oracles in the sense that the average output of an LLM will be what most companies do therefore you can predict what most companies will do.

I've found what works really well on 3G an MPA with streaming HTML with brotli compression rendering the whole page on every change.

Is it slow though? Like in practice? This demo [1] using Datastar (a streaming HTML framework) every action including scrolling roundtrips to the server. Even the checkboxes changing colour is a roundtrip.

https://checkboxes.andersmurphy.com

Also if anyone has a better way to do the pre-sort in Java/Clojure/JVM I'm all ears.

Tokenfalls! My dwarf fortress eyes read this deluge completely differently.

In SQLite all writes are serialisable by default and it scales really well. I think having a single writer is what makes the big difference here.

User permission can often be very dynamic. Sync engines (local first ones even more so) give them access to a much larger set if that data in a client side database.

This also makes them much more vulnerable to a data leak/breach if their device gets compromised or stolen as the data is all on their device.

The client having access to only what it needs in terms of data and making that as ephemeral as possible is a big part of defence in depth.

You don't even need your backend that close if your server is fast enough. Streaming HTML immediate mode is pretty good. See this demo (server is in Germany and runs on a potato uses no optimistic updates, eveb scroll round trips) [1]

Honestly client side animations go a long way to masking latency too.

- [1] https://checkboxes.andersmurphy.com/

Sync engines are fast to a point but if you start working with large enough datasets and/or care about security you ultimately end up with something closer to streaming immediate mode HTML. Of course that means sacrificing local first.

Although not as prominent as insert SELECT and UPDATE both benefit from page cache locality, assuming rows that are stored near each other are often selected/updated together.

An insignificant amount for the comparison (why I didn't mention it), it's a fast implementation and the JVM C2 JIT has kicked in by the time the first batch has completed.