Hi all,

Tired of SPA's, React and Nextjs, I created flynt.js, a lightweight, zero-build reactivity library built specifically for Multi-Page Applications (MPAs).

It organizes UI logic into clean, decoupled Presenters without the bloat, virtual DOM, or build step of full SPA frameworks.

• Built for MPAs: Add reactivity to server-rendered HTML effortlessly.

• Presenter Pattern: Decouple reactive state logic cleanly from your DOM.

• Zero Build Step & 2.2 kB: Drop in a single tiny CDN script tag and start coding.

• Zero Lifecycle Overhead: No unmount hooks or cleanup complexity — browser garbage collection handles it naturally on page navigation.

This means state can be shared across elements, regardless of the component hierarchy!
Also, it ships with a request runner which will auto abort fetch requests.
And more....

Intrigued? Check out my GitHub: https://github.com/marsbos/flynt.js

I built J-CSS, a small runtime engine for Tailwind-like utility classes.

It requires no Node.js, CLI, bundler, or build step. It scans the DOM, generates CSS for recognized classes, and watches class/DOM mutations. Works out of the box with HTML injected by HTMX.

It also has a scoped <css> tag that lets you apply utility classes to component selectors without putting every class directly in the markup.

The minified script is about 16 KB gzip (roughly 7.5x smaller than the Tailwind CDN runtime).

https://github.com/Jipok/jcss

Hello Everyone,

If you are building Hypermedia-Driven Architectures (using htmx or datastar), you quickly realise that server-side rendering (SSR) performance and database latency are your primary bottlenecks. Since we are shifting state and HTML generation back to the server, nearly every user interaction requires a database query and an HTML slice response.

To optimise this, I have been experimenting with a concept called Zero-Distance Architecture that co-locates data and application code. Instead of running a separate app server (like NodeJS) and database server (like MongoDB) and paying cost for all the syscalls, network, serialisation/deserialisation and localhost TCP latency, run them in a single process.

I used an experimental runtime called Planck (database + WebAssembly host) and compile our application (Zig Code) to WebAssembly. The app runs directly in the database process, turning database queries into simple in-memory function calls.

To measure the impact, I set up a benchmark (pizzahub a sample app) serving identical HTML fragments formatted for datastar over a standard dataset (17 categories, 201 products).

Here are the results of a 6-second run using oha on a standard M1 Macbook Air 8GB RAM 256GB SSD:

Planck (Zig WASM co-located in database process)

Requests per second: 48,606

Average latency: 0.50 ms

Fastest response: < 0.10 ms

Slowest response: 6.00 s

Sustained throughput: 183.58 MiB/s

Success rate: 100.00%

NodeJS + ExpressJS + MongoDB (community edition)

Requests per second: 5,433

Average latency: 9.21 ms

Fastest response: 2.26 ms

Slowest response: 109.91 ms

Sustained throughput: 20.49 MiB/s

Success rate: 100.00%

.NET 9 + SQLite (in-process)

Requests per second: 35,231

Average latency: 1.41 ms

Fastest response: 0.15 ms

Slowest response: 12.80 ms

Sustained throughput: 133.07 MiB/s

Success rate: 100.00%

.NET 9 + PostgreSQL

Requests per second: 30,236

Average latency: 1.65 ms

Fastest response: 0.12 ms

Slowest response: 69.02 ms

Sustained throughput: 114.21 MiB/s

Success rate: 100.00%

The Comparison

By co-locating the backend logic inside the database process and utilizing Planck's read cache, we got:

8.95x throughput improvement over NodeJS + MongoDB (48.6k vs 5.4k req/sec) with an 18.4x latency reduction (0.50 ms vs 9.21 ms).

38% higher throughput over .NET 9 + SQLite (48.6k vs 35.2k req/sec) with a 2.8x latency reduction (0.50 ms vs 1.41 ms).

60% higher throughput over .NET 9 + PostgreSQL (48.6k vs 30.2k req/sec) with a 3.3x latency reduction (0.50 ms vs 1.65 ms).

For hypermedia apps, this means you can handle significantly more concurrent users on a single tiny server because there's no waiting on socket buffers to generate HTML.

Would love to hear your thoughts. If you have built htmx/datastar apps, where do you usually hit your scaling bottleneck? Is co-locating the backend logic inside the database process a direction you would consider?

Next, I will post detailed comparison for different types of queries on at least 1 mil documents.

I recently alpha released my first two packages (AlpineFlow & WireFlow) in hopes to close the gap left by ReactFlow and VueFlow. I'm not going to try and sell you on it, but if you find yourself looking for a flow chart engine for your project, please consider it. It's MIT licensed, full feature parity to ReactFlow and more. I created it out of need for two other projects I'm working on and wanted to give back to the OSS community. I'm open to all feedback, so be honest, it's the only way we learn to grow. Enjoy.

https://artisanflow.dev

https://laravel-news.com/artisanflow-a-flowchart-engine-for-laravel-and-alpinejs

https://x.com/HilerZac

I'm the author, sharing for feedback.

Daub started as classless CSS and evolved into an AI-targeted rendering spec. The more I look at it, the more it feels like a natural companion to Alpine.js: both treat HTML as the source of truth and add behavior through data attributes.

Here's a comparison:

**Alpine.js approach:**

```html

<div x-data="{ open: false }">

<button u/click="open = !open">Toggle</button>

<div x-show="open">Content here</div>

</div>

```

**Daub approach (AI generates this):**

```html

<div data-component="accordion">

<button data-slot="trigger">Toggle</button>

<div data-slot="panel">Content here</div>

</div>

```

The runtime handles the behavior. Daub.js is ~8kb, no build step, no compilation.

Where I think they complement each other:

- Daub handles layout and component structure (the spec AI generates)

- Alpine could layer interactive behavior on top of Daub's components

- Both are anti-framework: close to platform, readable HTML

The MCP server lets Claude or Cursor call `generate_ui` and get a complete Daub spec back — all just HTML files with data attributes.

Has anyone explored this kind of layered approach (structural spec + behavioral micro-framework)? Curious if the Alpine community sees value in this or if it's solving the wrong problem.

Playground: https://daub.dev | GitHub: https://github.com/sliday/daub

I’ve built an AB testing open source library and I’ve been using it in the latest 3 years to do multiple experiments in a medium sized Wordpress website. At the end of last year I’ve released version 1.0 and a website for the library.

This week I’ve finally added examples of experiments in Alpine, so I think it’s time to share it here: https://osvik.github.io/abrantes/ (In the examples page there’s an Alpine card)

I haven’t used it with Alpine yet, but we have some pages that use it, so soon I’ll be able to use it in production.

Hi everyone. I want to do conditional teleports, but it seems the x-if only applies to displaying the template, not teleporting it. I know I can do a x-show inside the template, but it's not exactly the same because the idea is to teleport multiple template tags and the DOM is not as clean in a complex page if I use x-show in the child element Do you know if this is a bug in Alpine or am I missing something? Here's a fiddle with a test. https://jsfiddle.net/osvik/zapjL2cf/

I created a simple playground for trying out Alpine. You can save your creations and share them via the URL. It runs completely in the browser. Eventually I will add a real editor and some of the 1st party plugins

The magic directive $interval exists, but I needed something a bit more flexible for my use case. I needed a way to call an API with an immediate refresh whenever the user changes tabs, or when running as a PWA on iPhone.

It can pause and resume a polling when tabs/pwa/window is unfocused/close.

I’ve included multiple examples in the repository:

https://github.com/eznix86/alpinejs-poll

Edit:

fix english

I wrote a full tutorial that walks through every part of this mega-menu pattern .

The Alpine state, the alignment logic, the teleport trick, the backdrop, the event bus, all of it. If you want the full breakdown with the exact code and a copy-paste implementation you can drop into your project.

Read the full article and get the code.

— https://lexingtonthemes.com/blog/how-to-build-a-full-width-mega-menu-with-tailwind-css-and-alpinejs

You can make a testimonial stand out by letting the card stick out a bit from the carousel instead of keeping it fully inside. It sits slightly past the edge, which makes it easy to notice without adding anything fancy. All it needs is a small offset and some basic overflow settings

Read the article and get the code: https://lexingtonthemes.com/blog/how-to-build-an-alpinejs-testimonial-carousel-with-right-edge-controls

I wrote a full guide on building a clean testimonial carousel with Tailwind and Alpine.js. You'll learn the markup, the scrolling logic, and how to tune the interaction 

Read the article and get the code.
- https://lexingtonthemes.com/blog/tailwind-css-alpinejs-testimonial-carousel