DEV Community: Mohammed Rashad

Adding a Markdown Editor to Laravel Forms (No Sync Code Required)

Mohammed Rashad — Mon, 12 Oct 2026 13:00:00 +0000

Add a markdown editor to a Blade form the usual way and it looks fine, until the form silently refuses to submit:

<textarea id="content" name="content" required>{{ old('content') }}</textarea>

// The editor everyone reaches for first
const easyMDE = new EasyMDE({ element: document.getElementById('content') });

Click Save and nothing happens. No validation error, no request, no clue on the page. The console says:

An invalid form control with name='content' is not focusable.

EasyMDE hides your <textarea> with display: none and edits a copy. The hidden field is still required, so the browser refuses to submit a form it can't focus the invalid field in, and because the submit event never fires, the editor never copies its content back.

To be fair to EasyMDE: without required it does sync on submit by itself, so a plain form works. The trouble is that the value only exists in the textarea during submit:

// Any code that reads the field before submit gets an empty string
new FormData(document.querySelector('form')).get('content');   // ""

That breaks anything that serialises the form itself: Livewire, Alpine, htmx, autosave, an "unsaved changes" guard, a character counter.

A better approach

markdown-text-editor styles the textarea you already have and leaves it as the field you type into. It's never hidden and never copied, so its value is correct at every moment, not just during submit.

required works because the field is visible. FormData works because the value is live. And $request->input(), form request validation, old() repopulation, CSRF and mass assignment all behave exactly as they do with a plain textarea.

Setup

Install via npm (if you use Vite):

npm install markdown-text-editor

Or use the CDN directly in your Blade template, no build step needed:

<script src="https://cdn.jsdelivr.net/npm/markdown-text-editor"></script>

Blade template

<form method="POST" action="{{ route('posts.store') }}">
    @csrf

    <div>
        <label for="content">Content</label>
        <textarea id="content" name="content" class="markdown-editor">{{ old('content') }}</textarea>
        @error('content') <span>{{ $message }}</span> @enderror
    </div>

    <button type="submit">Save</button>
</form>

<script src="https://cdn.jsdelivr.net/npm/markdown-text-editor"></script>
<script>
    new MarkdownEditor('.markdown-editor');
</script>

That's it. Submit the form: $request->input('content') contains the markdown exactly as typed. No hooks, no sync, no custom extraction.

Controller

Your controller doesn't change at all:

// PostController.php
public function store(Request $request)
{
    $validated = $request->validate([
        'title'   => 'required|string|max:255',
        'content' => 'required|string',
    ]);

    Post::create($validated); // content is already there, untouched

    return redirect()->route('posts.index');
}

Editing existing content

When editing a post, pre-fill the textarea with the saved value, the editor inherits it automatically:

<form method="POST" action="{{ route('posts.update', $post) }}">
    @csrf
    @method('PUT')

    <textarea id="content" name="content" class="markdown-editor">{{ old('content', $post->content) }}</textarea>

    <button type="submit">Update</button>
</form>

<script src="https://cdn.jsdelivr.net/npm/markdown-text-editor"></script>
<script>
    new MarkdownEditor('.markdown-editor');
</script>

Validation failures keep the markdown

This is where replacing the textarea hurts most, and it is the reason old() is in every example above.

When validation fails, Laravel redirects back with the input flashed to the session. old('content') prints it straight into the textarea, and the editor picks it up from there:

public function store(Request $request)
{
    $validated = $request->validate([
        'title'   => 'required|string|max:255',
        'content' => 'required|string|min:50',
    ]);

    // On failure Laravel redirects back automatically — old('content')
    // refills the textarea with everything the user wrote.
    Post::create($validated);

    return redirect()->route('posts.index');
}

Someone writes 800 words, forgets the title, and gets the title error back with every word still in place. An editor that replaced the textarea would need its own code to restore that, and if it restores late, it overwrites what the user has already started retyping.

Vite or the CDN

Both work. Use Vite when the rest of your front end is bundled:

// resources/js/app.js
import MarkdownEditor from 'markdown-text-editor';

document.querySelectorAll('.markdown-editor').forEach(el => new MarkdownEditor(el));

@vite(['resources/js/app.js'])

Use the CDN for an admin panel or a single page, where a build step buys you nothing.

Optional: auto-save draft

const textarea = document.querySelector('.markdown-editor');
const saved = localStorage.getItem('post-draft');
if (saved && !textarea.value) textarea.value = saved;

new MarkdownEditor('.markdown-editor', {
    onChange(value) {
        localStorage.setItem('post-draft', value);
    }
});

Features you get out of the box

WYSIWYG hybrid mode: renders bold, italic and headings live while keeping raw Markdown underneath
Live preview: side-by-side preview panel
Find & Replace: Ctrl+F / Ctrl+H
Keyboard shortcuts: Ctrl+B, Ctrl+I, Ctrl+K, headings via Ctrl+1–Ctrl+3, lists via Ctrl+L
RTL support, Arabic, Urdu and Farsi work out of the box
Dark mode, add data-theme="dark" to any ancestor element
XSS safe: preview sanitized with DOMPurify
CSP compatible, no inline event handlers
53 KB gzipped (252 KB minified, CSS included): EasyMDE is 107 KB gzipped across its JS and CSS

Rendering markdown in Blade

To display saved markdown in your views, use the league/commonmark package:

composer require league/commonmark

// App\Models\Post.php
use League\CommonMark\CommonMarkConverter;

class Post extends Model
{
    public function getRenderedContentAttribute(): string
    {
        $converter = new CommonMarkConverter([
            'html_input' => 'strip',
            'allow_unsafe_links' => false,
        ]);

        return $converter->convert($this->content)->getContent();
    }
}

{{-- show.blade.php --}}
<article>
    {!! $post->rendered_content !!}
</article>

Or keep it out of the model and convert where you render:

use League\CommonMark\CommonMarkConverter;

$converter = new CommonMarkConverter(['html_input' => 'strip']);
$html = $converter->convert($post->content)->getContent();

<article>{!! $html !!}</article>

Note the html_input => 'strip' setting. Markdown allows raw HTML, so anything a user writes would otherwise be rendered as-is, and {!! !!} prints it unescaped. Store the raw markdown, strip the HTML at render time, and you can change how it renders later without touching the data.

Why the textarea matters

An editor that hides the textarea and edits a copy has to guess when to put the content back. CodeMirror guesses "on submit", which is right most of the time, until the browser refuses to submit or Livewire reads the form before that moment. Every one of those failures is silent, because from the outside the field looks fine.

An editor that leaves the textarea in place has nothing to guess about. The browser owns the value, Laravel reads what the browser sent, and nothing in between has an opinion.

That's the whole design, and it's why the Laravel integration in this post is two lines long.

Full docs, theming guide, and image upload configuration: markdown-text-editor on Frutjam.

Source on GitHub, package on npm.

Zero JavaScript UI: Build Faster, More Accessible Web Apps With CSS-Only Components

Mohammed Rashad — Wed, 07 Oct 2026 13:00:00 +0000

The idea that you need JavaScript to build a polished, interactive web application has been quietly falling apart for years. The native web platform: HTML and CSS: now handles more UI patterns than most developers realize. Accordions, drawers, tabs, animated transitions, and accessible form controls, all achievable without a single line of JavaScript.

Frutjam is a Tailwind CSS component library built on this principle. The vast majority of components require zero JavaScript. Here is what that looks like in practice, and why it matters for your performance, accessibility, and development velocity.

The Browser Has Caught Up

A few years ago, the case for JavaScript-driven UI was legitimate. The browser had no native way to create accessible modals with focus trapping, toggle accordions with smooth animations, or build floating popovers with correct positioning.

Today, every one of those has a native solution:

Old JavaScript pattern	Native CSS/HTML replacement
Modal library (Bootstrap, MUI)	`<dialog>` element + `showModal()` (one line of native JS)
Accordion component	`<details>` / `<summary>`
Toggle / swap	Checkbox + CSS `:checked`
Floating popover	Native Popover API
Drawer / side panel	Checkbox + CSS `:has()`
Animated transitions	CSS `@starting-style` + `transition`
Tab switching	Radio inputs + CSS `:checked`
Tooltip	CSS `:hover` + `popover`

Frutjam wraps all of these patterns into clean, semantic component classes built on Tailwind CSS. The result is a fully interactive UI with zero JavaScript.

Why Zero JavaScript UI Matters

Core Web Vitals and PageSpeed

JavaScript is the single largest contributor to poor Core Web Vitals scores. Parsing and executing JS blocks the main thread, causing:

High Total Blocking Time (TBT), the metric that most directly predicts user-perceived slowness
Delayed Time to Interactive (TTI), when the page becomes usable
Layout shifts from late-rendering JS components: Cumulative Layout Shift (CLS)

Removing UI JavaScript eliminates these problems at the root. There's nothing to parse, nothing to initialize, nothing to cause a layout shift. Your server renders HTML; the browser displays it immediately. That's a PageSpeed 100 by default, not by optimization.

Google uses Core Web Vitals as a ranking signal. Pages with lower TBT and CLS rank better, all else being equal. Zero JavaScript components give you a structural advantage here, not a performance trick you apply after the fact.

Accessibility Without Configuration

Native HTML elements carry built-in accessibility semantics. A <dialog> traps focus automatically. A <details> announces its open/closed state to screen readers without any aria-* attributes. A radio-based tab interface is keyboard-navigable out of the box.

Frutjam adds WCAG AA color contrast on top, every component's color tokens pass contrast requirements. You get accessible UI without writing aria-expanded, aria-controls, or role attributes for the core components.

Works Everywhere, Re-Initializes Nowhere

When your UI layer has no JavaScript, it works in any rendering context without additional setup:

Django templates: server-rendered HTML, no client-side framework needed
HTMX: partial HTML swaps work without re-initialization callbacks
Laravel Blade: same HTML, same components, same behavior
React / Next.js: CSS-only components work alongside React with less client-side overhead
Static site generators: HTML output renders correctly on first paint

This matters most for HTMX and server-rendered stacks, where JavaScript-initialized components silently break when the DOM is replaced.

Browser Support

All Frutjam components rely on features that are fully supported in modern browsers:

Feature	Chrome	Firefox	Safari	Edge
`<dialog>` + Popover API	✓ 114+	✓ 122+	✓ 17+	✓ 114+
`<details>` / `<summary>`	✓ All	✓ All	✓ All	✓ All
CSS `:has()`	✓ 105+	✓ 121+	✓ 15.4+	✓ 105+
CSS `@starting-style`	✓ 117+	✓ 129+	✓ 17.5+	✓ 117+

Coverage is effectively 95%+ of global users as of 2025. The <details> element has had universal browser support since 2016.

Real Components, Zero JavaScript

Modal

The Frutjam modal uses the native <dialog> element. Opening requires one line of native browser JS: showModal(): via an inline onclick attribute. No library, no initialization, no bundle to load:

<button class="btn" onclick="confirmModal.showModal()">Delete item</button>

<dialog class="modal modal-center modal-middle modal-slide-up" id="confirmModal">
  <div class="modal-content">
    <h2 class="heading-lg">Are you sure?</h2>
    <p class="para">This action cannot be undone.</p>
    <div class="flex gap-2 justify-end mt-4">
      <button class="btn" onclick="confirmModal.close()">Cancel</button>
      <button class="btn btn-error" onclick="confirmModal.close()">Delete</button>
    </div>
  </div>
  <button class="modal-backdrop" onclick="confirmModal.close()">Close</button>
</dialog>

showModal() is a native HTMLDialogElement method, it is part of the browser, not a library. The <dialog> element handles focus trapping, ESC key dismissal, and top-layer rendering automatically. The slide-up animation (modal-slide-up) is pure CSS.

Animated Accordion

<details class="accordion">
  <summary class="accordion-header">
    What is CSS-only UI?
  </summary>
  <div class="accordion-body">
    <p>UI components that require no JavaScript to function. State is managed
    by the browser via native HTML elements and CSS selectors.</p>
  </div>
</details>

The @starting-style CSS rule in Frutjam animates the expand/collapse. No JavaScript event listeners, no animation libraries.

CSS-Only Tab Panels

<div class="tabs tabs-boxed">
  <input type="radio" name="code-tabs" class="tab" aria-label="HTML" checked>
  <div class="tab-content">HTML version here</div>

  <input type="radio" name="code-tabs" class="tab" aria-label="React">
  <div class="tab-content">React version here</div>

  <input type="radio" name="code-tabs" class="tab" aria-label="Django">
  <div class="tab-content">Django template version here</div>
</div>

The CSS :checked selector drives which panel is visible. Keyboard navigation between tabs is browser-native via arrow keys.

Drawer

<input type="checkbox" id="drawer-toggle" class="drawer-toggle">
<div class="drawer-content">
  <label for="drawer-toggle" class="btn">Open Sidebar</label>
</div>
<div class="drawer-side">
  <label for="drawer-toggle" aria-label="Close" class="drawer-overlay"></label>
  <nav class="menu bg-base-100 min-h-full w-64 p-4">
    <li><a href="/">Home</a></li>
    <li><a href="/components">Components</a></li>
  </nav>
</div>

Open/close state lives in the checkbox. CSS :has(:checked) drives the layout. No JavaScript involved.

Toast Notifications

<div class="toast toast-top toast-end">
  <div class="alert alert-success">
    <span>Changes saved successfully.</span>
  </div>
</div>

Frutjam's toast is positioned via CSS. For timed auto-dismiss, a single CSS animation handles the fade-out, no JavaScript timer required for the basic pattern.

Searchable Combobox

A combobox is one UI pattern where pure CSS hits a real limit, filtering a list as the user types requires JavaScript. But you don't have to write it yourself.

Frutjam ships createCombobox from frutjam/js, a built-in helper that adds filtering, keyboard navigation (↑ ↓ Enter Escape), and aria-* wiring in a single call. The open/close behavior is still CSS-only (focus-within:combobox-open):

<div class="relative w-64 focus-within:combobox-open">
  <input type="text" class="input w-full" placeholder="Search...">
  <ul class="combobox-list">
    <li class="combobox-item">React</li>
    <li class="combobox-item">Vue</li>
    <li class="combobox-item">Angular</li>
    <li class="combobox-item">Svelte</li>
  </ul>
</div>

import { createCombobox } from 'frutjam/js'
createCombobox(document.querySelector('.my-combobox'))

The browser has no native combobox element. When a UI pattern genuinely requires JavaScript, Frutjam provides it, so you are not writing filtering logic, keyboard handling, and ARIA attributes from scratch every time.

What You Do Not Give Up

The common concern with zero JavaScript UI is capability. For standard UI components, there is no meaningful sacrifice:

Smooth animations: CSS @starting-style and transition handle enter/exit animations natively
Focus management: <dialog> traps focus natively; focus returns to the trigger on close
Keyboard navigation: native inputs are keyboard-navigable without writing event listeners; combobox keyboard nav is handled by the built-in createCombobox() helper
Dark mode: data-theme attribute switching with zero JavaScript

Where JavaScript is genuinely necessary: form validation with real-time feedback, async data fetching, complex application state: tools like HTMX handle it at the request/response level, not the component level. Your UI components stay clean and framework-agnostic.

Installation

Install Frutjam alongside Tailwind CSS:

npm install -D frutjam

Add two lines to your CSS:

@import "tailwindcss";
@plugin "frutjam";

Apply a theme to your HTML root:

<html data-theme="darkberry">

Every component is immediately available. No JavaScript configuration, no plugin initialization, no build step beyond Tailwind itself.

Frequently Asked Questions

Do Frutjam components work with React or Next.js?
Yes. React renders HTML; Frutjam styles HTML. You apply Frutjam class names to JSX elements the same way you apply any CSS class. For modals, call document.getElementById("myModal").showModal() from React state, the <dialog> handles everything else. Accordions, drawers, and tabs need zero React state at all.

What about form validation without JavaScript?
CSS-only validation works for required fields, pattern matching, and email format checking using the :invalid and :valid pseudo-classes. For complex validation logic or async server-side checks, a minimal amount of JavaScript (or HTMX) is appropriate. The point isn't to eliminate JavaScript entirely, it's to stop using JavaScript for UI state that native HTML handles better.

Is <dialog> supported on mobile?
Yes. The <dialog> element has been supported in Safari on iOS since version 15.4 (released March 2022), Chrome Android since version 37, and Firefox Android since version 98. Global mobile coverage is above 95%.

How do I animate component open/close without JavaScript?
Frutjam uses CSS @starting-style combined with transition to animate components in and out. This is a native CSS feature supported in all modern browsers since 2023–2024. The animation is defined in the library, you get smooth transitions on <dialog>, <details>, and popover elements without any JavaScript or animation library.

Can I use Frutjam alongside a JavaScript framework like Alpine.js?
Yes. Frutjam doesn't own any DOM state, so it coexists cleanly with Alpine.js, Stimulus, or any small JS library. Accordions and drawers are entirely CSS, Alpine never touches them. For modals, you can use either Frutjam's native showModal() or wire it to an Alpine variable, both work.

What Zero JavaScript UI Looks Like in Production

A production page using Frutjam typically has three assets:

Asset	Size (min+gzip)	Notes
Tailwind CSS (JIT)	~5–8 KB	Base utilities, only used classes
Frutjam CSS (JIT)	~12–18 KB	Component styles, only used classes
HTMX (optional)	~14 KB	Only if you need dynamic content

Total page weight for a UI-heavy page: ~20–40 KB with zero JavaScript UI components. Compare this to a typical React + UI library setup at 150–400 KB before application code. The difference is measurable in Lighthouse scores, Core Web Vitals, and user-perceived load time: especially on mobile networks.

Dropdowns That Position Themselves: CSS Anchor Positioning Is Baseline Now

Mohammed Rashad — Mon, 05 Oct 2026 16:41:06 +0000

Every dropdown you have ever built had the same problem underneath it: the panel has to appear next to the button, stay there while the page scrolls, and flip to the other side when it runs out of room.

For a decade the only answer was JavaScript. Popper.js, and then Floating UI, existed almost entirely to measure two rectangles, do the arithmetic, and rewrite top and left on every scroll and resize.

That's now a CSS feature, and as of this month it works in every major browser.

What changed

CSS anchor positioning reached Baseline in September 2026. Chromium shipped it first and the others have now followed; MDN has the version table. It's marked newly available, which means the current release of every major browser supports it, while older installs do not.

The idea is simple. One element gives itself a name; another says it wants to be positioned relative to that name.

.trigger {
  anchor-name: --my-menu;
}

.panel {
  position: absolute;
  position-anchor: --my-menu;
  position-area: block-end span-inline-end;   /* below, aligned to the end */
  position-try-fallbacks: flip-block;          /* flip above if it won't fit */
}

The browser keeps them tethered from then on. Scroll the page, resize the window, move the trigger, the panel follows, because the relationship is declared rather than calculated.

position-try-fallbacks is the part that used to be most of the library code. Give it a list, and when the preferred placement would put the panel off screen, the browser tries the next one: flip vertically, flip horizontally, or both.

What it replaces

A typical Floating UI setup for a single dropdown:

import { computePosition, flip, shift, offset, autoUpdate } from '@floating-ui/dom';

const cleanup = autoUpdate(button, panel, () => {
  computePosition(button, panel, {
    placement: 'bottom-end',
    middleware: [offset(8), flip(), shift({ padding: 8 })],
  }).then(({ x, y }) => {
    Object.assign(panel.style, { left: `${x}px`, top: `${y}px` });
  });
});

// and remember to call cleanup() when the panel closes

That's a dependency, a listener on every scrollable ancestor, a layout read and a style write on every frame, and a teardown function you have to remember. The CSS above does the same job with no bytes shipped and nothing to clean up.

How Frutjam's popover uses it

We built the popover on anchor positioning before it was Baseline, so the implementation is already in the library. It's three declarations.

The trigger names itself:

@utility popover-toggle {
  anchor-name: var(--popover--anchor-name);
}

The panel anchors to that name and picks an area:

@utility popover-content {
  position-anchor: var(--popover--anchor-name);
  position-area: var(--popover--position-area, block-end span-inline-end);
  position-try-fallbacks: var(--popover--position-try, none);
}

And each placement class sets the variables:

@utility popover-top-start {
  --popover--position-area: block-start span-inline-start;
}

Twelve placement classes, one line of CSS each. In markup you pick one:

<div class="popover popover-top-start">
  <button popovertarget="menu" type="button" class="popover-toggle btn">Options</button>
  <div class="popover-content" popover id="menu">
    <ul class="menu">
      <li><a class="menu-item">Edit</a></li>
      <li><a class="menu-item">Delete</a></li>
    </ul>
  </div>
</div>

That's the whole dropdown. The popover attribute gives you click-outside to close, Escape to close, and rendering above everything without a z-index. Anchor positioning decides where it goes. @starting-style animates it in. There's no JavaScript on the page.

Logical properties, so RTL comes free

Note what the placement values say: block-start, span-inline-end. Not top and right.

Those are logical directions, resolved against the writing direction of the document. In an Arabic or Hebrew layout, a popover aligned to inline-start moves to the right-hand side by itself, because "start" means the side the text starts from.

A dropdown positioned in pixels needs a second set of rules under [dir="rtl"], and someone has to remember to write them. This is the kind of thing that made RTL support a project of its own, and the reason so many libraries treat it as an afterthought.

What to do about older browsers

Newly available means the current version of each major browser has it, not every browser in use. Plan for both.

Frutjam's popover degrades quietly. Where anchor positioning is unavailable the panel still opens, still closes on Escape and on outside clicks, and still renders above the page; it simply falls back to the static position it would have had in the flow, near its trigger, instead of being tethered to it. Nothing breaks, the placement is just less precise.

If you want to branch explicitly, feature-query it:

.panel {
  /* placement that works anywhere */
  position: absolute;
  inset-block-start: 100%;
}

@supports (anchor-name: --x) {
  .panel {
    position-anchor: --my-menu;
    position-area: block-end span-inline-end;
    position-try-fallbacks: flip-block;
  }
}

Worth deciding deliberately rather than by accident: a dropdown that is slightly misplaced on an old browser is usually acceptable, while one that opens off screen is not.

The pattern this belongs to

Anchor positioning is the fourth in a run of features that each deleted a category of UI JavaScript:

Feature	What it replaced
`<dialog>` and `showModal()`	Focus trapping, the inert background, Escape handling
The popover API	Click-outside handlers, `z-index` stacking wars
`@starting-style`	Animation libraries for enter and exit transitions
Anchor positioning	Popper.js, Floating UI, scroll listeners

None of these are exotic. They are the boring, load-bearing parts of a UI library, and the platform has absorbed them one at a time over about three years.

What changes is the cost of a component library. A dropdown used to mean a dependency, a runtime and a bundle. Now it's a handful of CSS custom properties, and the browser does it faster than any library could, because it already knows where everything is.

The popover component ships all twelve placements with edge flipping, and every Frutjam component is CSS-only by default.

Why JS component libraries break with htmx (and what I use instead)

Mohammed Rashad — Wed, 30 Sep 2026 13:00:00 +0000

You swap a fragment with htmx and the dropdowns inside it stop working. The markup is right, the classes are right, but the component library's JavaScript ran once on page load and never saw the new HTML.

So you wire up htmx:afterSwap to re-initialise everything, and then you do it again for every component, on every endpoint that returns a partial.

Frutjam is a CSS-only Tailwind CSS component library built to complement HTMX naturally. No JS library or plugin means no re-initialization problems when HTMX swaps HTML fragments.

Why JavaScript-Driven UI Libraries Conflict With HTMX

HTMX's core idea is simple: use HTML attributes to add dynamic behavior to elements, letting the server return HTML fragments. It intentionally avoids a JavaScript component model.

That design breaks the moment you add a JavaScript-driven UI library:

Initialization timing. JavaScript UI components register on DOMContentLoaded or similar hooks. When HTMX swaps in new HTML, those hooks do not re-run. You end up writing htmx:afterSwap event listeners just to re-initialize dropdowns or modals — code that fights HTMX rather than working with it.

State conflicts. JavaScript UI libraries maintain internal state. When HTMX replaces a DOM node that a JavaScript library has claimed, you get ghost listeners, duplicated event handlers, or broken components.

Bundle bloat. HTMX itself is around 14 KB (min+gzip). Loading a full JavaScript UI framework on top defeats the performance argument for choosing HTMX in the first place.

The solution is a UI library with no JavaScript to re-initialize — one where every component is pure HTML and CSS.

Why Not Just Use Alpine.js?

Alpine.js is often recommended alongside HTMX for UI behavior. It works well for small amounts of client-side state. But it introduces the same class of problem as a JavaScript UI library:

Alpine components need to initialize — x-data blocks set up on page load
HTMX-swapped HTML containing Alpine components needs Alpine.initTree() called manually
You are now managing two JavaScript libraries (HTMX + Alpine) plus a CSS library

With Frutjam, there is no Alpine.js needed for standard UI components. Accordions, drawers, and tabs are pure CSS. Modals use a single inline onclick="id.showModal()" — native browser JS, not a library, so HTMX swaps never break them. HTMX handles data; Frutjam handles the UI.

Frutjam: Built for HTMX-Powered Apps

Every Frutjam component relies on native browser behavior and CSS. HTMX can swap any fragment containing Frutjam components and they will work correctly — no callbacks, no re-initialization scripts, no edge cases.

Modals via Native `<dialog>`

Frutjam modals use the native <dialog> element with inline onclick="id.showModal()". Because the trigger is inline HTML — not a JavaScript library initialization — HTMX can swap a fragment containing this button and it works immediately with no callback:

<!-- Server returns this fragment; HTMX swaps it into #modal-container -->
<button class="btn btn-error" onclick="confirmModal.showModal()">Delete</button>

<dialog class="modal modal-center modal-middle" id="confirmModal">
  <div class="modal-content">
    <h2 class="heading-lg">Confirm delete</h2>
    <p class="para">This action cannot be undone.</p>
    <div class="flex gap-2 justify-end mt-4">
      <button class="btn" onclick="confirmModal.close()">Cancel</button>
      <button class="btn btn-error"
        hx-delete="/items/42"
        hx-target="#item-list"
        hx-swap="outerHTML"
        onclick="confirmModal.close()">Delete</button>
    </div>
  </div>
  <button class="modal-backdrop" onclick="confirmModal.close()">Close</button>
</dialog>

No htmx:afterSwap listener. No JavaScript library to reinitialize. The onclick attribute is re-evaluated by the browser on every render, so HTMX swaps just work.

Accordions With Lazy-Loaded Content

<details class="accordion">
  <summary class="accordion-header">Order details</summary>
  <div class="accordion-body"
    hx-get="/orders/42/details"
    hx-trigger="toggle once">
    Loading...
  </div>
</details>

The <details> element holds its open/closed state natively. HTMX lazy-loads content on the first open toggle without any component re-initialization.

Drawers via Checkbox

Frutjam's drawer uses a native checkbox for open/closed state. HTMX can freely swap content inside the drawer without touching the toggle:

<input type="checkbox" id="menu-toggle" class="drawer-toggle">

<div class="drawer-content">
  <label for="menu-toggle" class="btn">Open Menu</label>
</div>

<div class="drawer-side">
  <label for="menu-toggle" aria-label="Close menu" class="drawer-overlay"></label>
  <nav class="menu bg-base-100 min-h-full w-64 p-4">
    <ul hx-get="/nav/items" hx-trigger="load">
      <li>Loading...</li>
    </ul>
  </nav>
</div>

HTMX updates the nav list; the checkbox controls drawer open/close. They never interfere.

Server-Driven Pagination

<div id="results">
  <!-- Content updated by HTMX -->
</div>

<div class="join" hx-target="#results" hx-swap="innerHTML">
  <button class="join-item btn" hx-get="/items?page=1">1</button>
  <button class="join-item btn btn-active" hx-get="/items?page=2">2</button>
  <button class="join-item btn" hx-get="/items?page=3">3</button>
</div>

No JavaScript pagination library. No state management. The server controls the active page; Frutjam handles the visual system.

HTMX-Powered Search with Combobox

Frutjam's combobox pairs naturally with HTMX for server-side filtering. The open/close behavior is CSS-only (focus-within:combobox-open). For live search, hx-get sends the query to the server and HTMX swaps the results — no client-side filtering needed at all:

<div class="relative w-full focus-within:combobox-open" id="user-search">
  <input type="text"
    class="input w-full"
    placeholder="Search users..."
    hx-get="/users/search"
    hx-target="#user-results"
    hx-trigger="input changed delay:200ms"
    name="q">
  <ul class="combobox-list" id="user-results">
    <!-- Server returns <li class="combobox-item"> fragments here -->
  </ul>
</div>

The server returns a list of <li class="combobox-item"> elements. HTMX swaps them in. No client-side filtering script, no component re-initialization. If you want client-side filtering instead — for small static lists — add the built-in helper:

import { createCombobox } from 'frutjam/js'
createCombobox(document.querySelector('#user-search'))

createCombobox adds keyboard navigation (↑ ↓ Enter Escape) and aria-* attributes. The browser has no native combobox element, so unlike the accordion or drawer, filtering logic has to come from somewhere — Frutjam ships it so you do not write it.

Django Tailwind Components

Two CSS imports. That is the entire setup:

/* In your base CSS file */
@import "tailwindcss";
@plugin "frutjam";

Install the npm package alongside Tailwind:

npm install -D frutjam

Every Django template, Jinja2 partial, and DRF HTML response can use Frutjam components immediately. HTMX attributes work on any Frutjam element without additional configuration.

A typical Django + HTMX + Frutjam template looks like this:

<!-- base.html -->
<!DOCTYPE html>
<html data-theme="darkberry">
<head>
  <link rel="stylesheet" href="{% static 'css/app.css' %}">
  <script src="https://unpkg.com/htmx.org@2" defer></script>
</head>
<body>
  {% block content %}{% endblock %}
</body>
</html>

No JavaScript UI framework. No component initialization. HTMX handles behavior; Frutjam handles UI.

Laravel Tailwind Components

The setup in Laravel is identical — Frutjam is framework-agnostic:

/* resources/css/app.css */
@import "tailwindcss";
@plugin "frutjam";

npm install -D frutjam
npm run build

<!-- resources/views/layouts/app.blade.php -->
<html data-theme="darkberry">
<head>
  @vite(['resources/css/app.css'])
  <script src="https://unpkg.com/htmx.org@2" defer></script>
</head>
<body>
  @yield('content')
</body>
</html>

Blade partials returned by HTMX-targeted routes contain Frutjam components that work immediately on insertion — no JavaScript initialization step.

Performance: The Frutjam + HTMX Stack

Asset	Size (min+gzip)
HTMX	~14 KB
Frutjam CSS (JIT, used classes only)	~12–18 KB
UI component JavaScript	0 KB (core) / ~2 KB optional (combobox helper)
Total	~26–32 KB

Compare to a React SPA with a JavaScript UI library: typically 150–400 KB before your application code runs. The difference shows directly in Core Web Vitals — First Contentful Paint, Time to Interactive, and Total Blocking Time all improve when there is no script parsing blocking the render path.

The Stack That Does Not Fight You

Tailwind CSS handles the visual system. HTMX handles dynamic behavior without JavaScript components. Frutjam handles the component library. Nothing in the stack conflicts with anything else.

If you are building a Django, Laravel, FastAPI, or any server-rendered application and want UI components that work on first swap without re-initialization, explore Frutjam — the Tailwind CSS component library designed for this stack.

FastAPI + Jinja2 Setup

Frutjam works equally well with FastAPI and Jinja2 templates:

# main.py
from fastapi import FastAPI, Request
from fastapi.templating import Jinja2Templates
from fastapi.staticfiles import StaticFiles

app = FastAPI()
app.mount("/static", StaticFiles(directory="static"), name="static")
templates = Jinja2Templates(directory="templates")

@app.get("/")
async def home(request: Request):
    return templates.TemplateResponse("index.html", {"request": request})

<!-- templates/base.html -->
<!DOCTYPE html>
<html data-theme="darkberry">
<head>
  <link rel="stylesheet" href="/static/css/app.css">
  <script src="https://unpkg.com/htmx.org@2" defer></script>
</head>
<body>
  {% block content %}{% endblock %}
</body>
</html>

The same Frutjam components that work in Django templates work identically here. The library is server-framework agnostic — it only cares about the HTML that reaches the browser.

HTMX Attribute Quick Reference With Frutjam

These HTMX attributes work on any Frutjam element without configuration:

HTMX attribute	Use case with Frutjam
`hx-get` / `hx-post`	Load content into cards, lists, accordion bodies
`hx-target`	Replace a specific element while leaving the surrounding Frutjam layout intact
`hx-swap="outerHTML"`	Replace an entire Frutjam card or list item from the server
`hx-trigger="toggle once"`	Lazy-load accordion content on first open
`hx-indicator`	Show a Frutjam `loading` spinner while a request is in flight
`hx-boost`	Progressive enhancement on links inside Frutjam menus and navbars

Frequently Asked Questions

Does Frutjam require any JavaScript setup with HTMX?
No external JavaScript setup. Install via npm, add two lines to your CSS. Accordions, drawers, and tabs need no JS at all. Modals use inline onclick="id.showModal()" — plain HTML, so they work on first render and after every HTMX swap without any htmx:afterSwap listener.

What if I need a component that genuinely requires JavaScript?
The combobox is the clearest example: filtering a list as the user types requires JavaScript. Frutjam ships createCombobox from frutjam/js — a built-in helper that handles filtering, keyboard navigation, and aria-* attributes. You do not write it yourself. With HTMX, you can skip client-side filtering entirely and let the server return filtered results. Accordions, drawers, and tabs are pure CSS. Modals use one line of native browser JS (showModal()) with no library or initialization lifecycle.

Can I use Frutjam with htmx.org's hx-boost?
Yes. hx-boost replaces page navigation with HTMX partial swaps. Frutjam components in the swapped content work correctly because there is nothing to re-initialize — the CSS is already loaded globally.

Does Frutjam work with Django REST Framework (DRF)?
Yes. DRF's TemplateHTMLRenderer returns full HTML responses. Frutjam components in those templates work identically to any other Django template.

EasyMDE silently breaks Django forms (and what I use instead)

Mohammed Rashad — Mon, 28 Sep 2026 13:00:00 +0000

Add a markdown editor to a Django form the usual way and it looks fine — until the form silently refuses to submit:

# forms.py — Django adds required=True to every non-blank field
class PostForm(forms.ModelForm):
    class Meta:
        model = Post
        fields = ['title', 'content']

// The editor everyone reaches for first
const easyMDE = new EasyMDE({ element: document.getElementById('id_content') });

Click Save and nothing happens. No validation error, no request, no clue on the
page. The console says:

An invalid form control with name='content' is not focusable.

EasyMDE hides your <textarea> with display: none and edits a copy. The
hidden field is still required, so the browser refuses to submit a form it
cannot focus the invalid field in — and because the submit event never fires,
the editor never copies its content back. The user's writing goes nowhere.

To be fair to EasyMDE: on a form without required, it does sync on submit by
itself, so plain forms work. The trouble is that Django marks fields required by
default, and that the value only exists in the textarea during submit:

// Any code that reads the field before submit gets an empty string
new FormData(document.querySelector('form')).get('content');   // ""

That breaks anything that serialises the form itself — htmx, Turbo, Alpine,
autosave, an "unsaved changes" guard, a character counter.

A better approach

markdown-text-editor styles the
textarea you already have and leaves it as the field you type into. It is never
hidden and never copied, so its value is correct at every moment — not just
during submit.

required works because the field is visible. FormData works because the
value is live. And request.POST, form validation, ModelForm.save(), CSRF and
pre-filling on edit all behave exactly as they do with a plain textarea.

Setup

Install via npm (if you use a JS bundler):

npm install markdown-text-editor

Or use the CDN directly in your template — no build step needed:

<script src="https://cdn.jsdelivr.net/npm/markdown-text-editor"></script>

Django form

Nothing changes in your form class:

# forms.py
from django import forms

class PostForm(forms.ModelForm):
    class Meta:
        model = Post
        fields = ['title', 'content']
        widgets = {
            'content': forms.Textarea(attrs={'class': 'markdown-editor'}),
        }

Template

{% extends "base.html" %}

{% block content %}
<form method="post">
    {% csrf_token %}
    {{ form.as_p }}
    <button type="submit">Save</button>
</form>

<script src="https://cdn.jsdelivr.net/npm/markdown-text-editor"></script>
<script>
    new MarkdownEditor('.markdown-editor');
</script>
{% endblock %}

That's it. Submit the form — request.POST['content'] contains the markdown exactly as typed. No hooks, no sync, no custom extraction.

View

Your view doesn't change at all:

# views.py
def create_post(request):
    if request.method == 'POST':
        form = PostForm(request.POST)
        if form.is_valid():
            form.save()  # content is already there, untouched
            return redirect('post-list')
    else:
        form = PostForm()
    return render(request, 'create_post.html', {'form': form})

Editing existing content

When editing an existing post, Django pre-fills the textarea via the form — and the editor picks up whatever value is already there:

def edit_post(request, pk):
    post = get_object_or_404(Post, pk=pk)
    if request.method == 'POST':
        form = PostForm(request.POST, instance=post)
        if form.is_valid():
            form.save()
            return redirect('post-detail', pk=pk)
    else:
        form = PostForm(instance=post)  # textarea pre-filled, editor inherits it
    return render(request, 'edit_post.html', {'form': form})

Validation errors keep the user's text

Server-side validation is the other half of the story. When a form fails
validation, Django re-renders the page with the submitted data bound to the
form. Because the markdown lives in the textarea, it comes back with it:

def create_post(request):
    form = PostForm(request.POST or None)
    if request.method == 'POST' and form.is_valid():
        form.save()
        return redirect('post-list')
    # Invalid: the same template re-renders with the user's markdown intact
    return render(request, 'create_post.html', {'form': form})

The reader types 800 words, forgets the title, and gets the title error back with every word still in place.

Optional: auto-save draft

const textarea = document.querySelector('.markdown-editor');
const saved = localStorage.getItem('post-draft');
if (saved && !textarea.value) textarea.value = saved;

new MarkdownEditor('.markdown-editor', {
    onChange(value) {
        localStorage.setItem('post-draft', value);
    }
});

Features you get out of the box

WYSIWYG hybrid mode — renders bold, italic and headings live while keeping raw Markdown underneath
Live preview — side-by-side preview panel
Find & Replace — Ctrl+F / Ctrl+H
Keyboard shortcuts — Ctrl+B, Ctrl+I, Ctrl+K, headings via Ctrl+1–Ctrl+3, lists via Ctrl+L
RTL support — Arabic, Urdu and Farsi work out of the box
Dark mode — add data-theme="dark" to any ancestor element
XSS safe — preview sanitized with DOMPurify
CSP compatible — no inline event handlers
51 KB gzipped (245 KB minified, CSS included) — EasyMDE is 107 KB gzipped across its JS and CSS

Rendering markdown in templates

To display saved markdown in your templates, use the markdown library:

pip install markdown bleach

# models.py
import markdown
import bleach
from django.db import models
from django.utils.safestring import mark_safe

class Post(models.Model):
    content = models.TextField()

    def rendered_content(self):
        html = markdown.markdown(self.content, extensions=['fenced_code', 'tables'])
        return mark_safe(bleach.clean(
            html,
            tags=bleach.sanitizer.ALLOWED_TAGS + ['p', 'h1', 'h2', 'h3', 'pre', 'code', 'table', 'thead', 'tbody', 'tr', 'th', 'td'],
            strip=True
        ))

<!-- detail template -->
<article>
    {{ post.rendered_content }}
</article>

Sanitize on render, not on save. Storing the raw markdown means you can change how it is rendered later — switch extensions, allow a new tag, fix an escaping bug — without a data migration.

Why the textarea matters

An editor that hides the textarea and edits a copy has to guess when to put the
content back. CodeMirror guesses "on submit", which is a good guess and right
most of the time — until the browser refuses to submit, or something reads the
form before that moment. Every one of those failures is silent, because from the
outside the field looks fine.

An editor that leaves the textarea in place has nothing to guess about. The
browser owns the value, Django reads what the browser sent, and nothing in
between has an opinion.

That is the whole design, and it is why the Django integration in this post is
three lines long.

Starting from scratch?

django-frutjam-starter is a
working Django 6 project with all of this already wired up — accounts, a
dashboard, and this exact markdown editor on a notes form. Clone it, run two
commands, and you have somewhere to start.

Full docs, theming guide, and image upload configuration: markdown-text-editor on Frutjam.

Source on GitHub, package on npm.

DaisyUI vs Frutjam: an honest comparison (I wrote one of them)

Mohammed Rashad — Wed, 23 Sep 2026 13:00:00 +0000

Your components look right. Then the accessibility audit runs, and half the buttons fail contrast on the dark theme.

That is where I ended up after shipping a few multilingual projects on Tailwind CSS: patching theme variables one hex at a time, writing RTL overrides by hand, and fighting modal positioning that only offered three placements. Eventually I stopped patching and built the library I wanted instead.

This is the honest comparison I wish I'd had before starting: what DaisyUI does well, the four places it left me stuck, and what Frutjam — 65+ CSS-only components, WCAG AA/AAA on every theme, PageSpeed 100 — does differently.

DaisyUI v5: What Changed, What Didn't

DaisyUI v5 is a meaningful upgrade that corrects many of the criticisms aimed at earlier versions. Interactive components no longer require a separate JavaScript plugin:

Modal: native <dialog> + showModal() or the Popover API — no JS bundle
Drawer: checkbox toggle + CSS — zero JavaScript
Dropdown: native Popover API, <details>, or focus-based CSS — zero JavaScript
Accordion: radio inputs or <details> / <summary> — zero JavaScript

If you have read comparisons claiming DaisyUI v5 requires a JavaScript plugin for interactive components, those comparisons describe DaisyUI v4. Version 5 is largely CSS-based.

What DaisyUI v5 still does not address: WCAG contrast guarantees across its 25+ themes, depth of the modal positioning system, and the absence of a combobox component.

Where Frutjam Is a Better Fit

1. WCAG AA/AAA Contrast on Every Theme

Frutjam ships a Berry theming system — six named themes built on OKLCH color values, each hand-tuned to pass WCAG AA and AAA contrast requirements:

Theme	Mode
Snowberry	Light (default)
Darkberry	Dark
Blueberry	Light (blue accent)
Strawberry	Light (red accent)
Grapeberry	Light (purple accent)
Peachberry	Light (warm accent)

Apply a theme with one HTML attribute:

<html data-theme="darkberry">

Themes cascade via CSS variables and can be nested — a sidebar can run a dark theme while the rest of the page stays light:

<html data-theme="snowberry">
  <aside data-theme="darkberry">
    <!-- dark sidebar -->
  </aside>
</html>

DaisyUI ships 25+ themes. Frutjam ships fewer, but every color pair in every theme — text on background, label on input, badge on card — passes WCAG contrast checks without configuration. No contrast surprises at audit time.

2. Modal System: 9 Positions, 4 Animations, LTR/RTL Aware

Both Frutjam and DaisyUI use the native <dialog> element with showModal(). Where they diverge is what the library provides around it.

DaisyUI offers three vertical positions (modal-top, modal-middle, modal-bottom) and no entrance animations.

Frutjam provides a full placement and animation system:

Axis	Classes
Vertical	`modal-top`, `modal-middle`, `modal-bottom`
Horizontal	`modal-start`, `modal-center`, `modal-end`
Animations	`modal-slide-up`, `modal-slide-down`, `modal-slide-start`, `modal-slide-end`
LTR / RTL	`ltr:modal-end`, `rtl:modal-start`
Responsive	`modal-top lg:modal-middle`

Nine placement combinations. Four slide animations. Fully responsive via Tailwind breakpoint prefixes. LTR/RTL aware for multilingual apps.

A notification toast snapping to the top-right:

<dialog class="modal modal-end modal-top modal-slide-end" id="notificationModal">
  <div class="modal-content">
    <p class="para">Your changes were saved.</p>
    <button type="button" class="btn btn-xs" onclick="notificationModal.close()">Dismiss</button>
  </div>
</dialog>
<button type="button" class="btn" onclick="notificationModal.showModal()">Show</button>

A sheet that slides up from the bottom on mobile, centered on desktop:

<dialog class="modal modal-center modal-bottom modal-slide-up lg:modal-center lg:modal-middle" id="sheetModal">
  <div class="modal-content">
    <p class="para">Responsive sheet</p>
  </div>
  <button type="button" class="modal-backdrop" onclick="sheetModal.close()">Close</button>
</dialog>

3. Popover: 12 Positions, Click and Hover

Frutjam's popover uses the native Popover API — zero JavaScript for click-triggered dropdowns. Twelve position classes cover every anchor alignment:

popover-top-start    popover-top-center    popover-top-end
popover-bottom-start popover-bottom-center popover-bottom-end
popover-start-top    popover-start-center  popover-start-bottom
popover-end-top      popover-end-center    popover-end-bottom

Click trigger (native Popover API, zero JS):

<div class="popover popover-bottom-start">
  <button popovertarget="userMenu" type="button" class="popover-toggle btn">Account</button>
  <div tabindex="0" class="popover-content" popover id="userMenu">
    <ul class="menu">
      <li><a class="menu-item">Profile</a></li>
      <li><a class="menu-item">Settings</a></li>
      <li><a class="menu-item">Sign out</a></li>
    </ul>
  </div>
</div>

Hover trigger (add popover-hover, remove popovertarget and popover attributes):

<div class="popover popover-hover popover-bottom-start">
  <button type="button" class="popover-toggle btn">Hover me</button>
  <div class="popover-content">
    <ul class="menu">
      <li><a class="menu-item">About Us</a></li>
      <li><a class="menu-item">Contact</a></li>
    </ul>
  </div>
</div>

4. Drawer: 4 Positions Built on `<dialog>`

Frutjam's drawer is built on the native <dialog> element using the non-modal .show() method — so the rest of the page stays interactive while the drawer is open. Four positions ship out of the box:

<!-- Slide from left -->
<dialog class="drawer drawer-start" id="sideNav">
  <div class="drawer-content w-64 p-4">
    <ul class="menu">
      <li><a class="menu-item">Dashboard</a></li>
      <li><a class="menu-item">Settings</a></li>
    </ul>
  </div>
  <button type="button" class="drawer-backdrop" onclick="sideNav.close()">Close</button>
</dialog>
<button type="button" class="btn" onclick="sideNav.show()">Open Menu</button>

Open with onclick="id.show()", close with onclick="id.close()" — one line of inline JS per trigger, no library, no initialization lifecycle. For programmatic control from anywhere in your code, createDrawer from frutjam/js handles it.

5. Combobox: Built-In Where DaisyUI Has Nothing

The browser has no native combobox element. DaisyUI has no combobox component — if you need searchable select with keyboard navigation, you write it from scratch.

Frutjam ships a complete combobox. CSS-only for open/close, built-in JS helper for filtering and keyboard navigation:

<!-- Opens on focus — zero JavaScript -->
<div class="relative w-64 focus-within:combobox-open">
  <input type="text" class="input w-full" placeholder="Search...">
  <ul class="combobox-list">
    <li class="combobox-item">React</li>
    <li class="combobox-item">Vue</li>
    <li class="combobox-item">Django</li>
    <li class="combobox-item">Laravel</li>
  </ul>
</div>

Add live filtering and keyboard navigation (↑ ↓ Enter Escape) with the built-in helper:

import { createCombobox } from 'frutjam/js'
createCombobox(document.querySelector('.my-combobox'))

createCombobox also wires up all required aria-* attributes automatically. You do not write filtering logic, keyboard handlers, or ARIA patterns — the library ships them.

6. Tailwind v4 Native

Frutjam is designed around Tailwind v4 — the v4 import system, CSS-first configuration, and OKLCH color tokens. Install it and add two lines:

npm install frutjam

@import "tailwindcss";
@import "frutjam";

<html data-theme="snowberry">

Every component is available immediately. No script tags, no initialization, no build step beyond Tailwind itself.

Component Coverage Comparison

Component	Frutjam	DaisyUI v5
Total components	53	80
Built-in themes	6 named Berry themes	25+
WCAG AA/AAA guaranteed	Yes — all themes	Not guaranteed
Button, Badge, Alert	CSS-only	CSS-only
Accordion	CSS-only (`<details>` / `<summary>`)	CSS-only (radio / `<details>`)
Modal	`<dialog>` + `showModal()` — 9 positions, 4 animations, LTR/RTL	`<dialog>` + `showModal()` or Popover API — 3 positions
Drawer	`<dialog>` + `show()` — 4 positions	Checkbox toggle — CSS-only
Popover / Dropdown	Native Popover API — 12 positions, click or hover	Native Popover API / `<details>` / focus-based CSS
Combobox	CSS-only open/close + `createCombobox()` helper	No combobox component
RTL support	Yes — `ltr:` / `rtl:` prefixes on modal, drawer	Partial
PageSpeed 100/100	Yes — zero JS overhead, zero layout shift	—
Framework-agnostic	Django, HTMX, Laravel, React, Vue, any stack	Django, HTMX, Laravel, React, Vue, any stack

Side-by-Side: Modal

The same trigger pattern, different positioning depth.

DaisyUI — three positions, no animations, closes via form:

<button class="btn" onclick="my_modal.showModal()">Open Modal</button>

<dialog id="my_modal" class="modal">
  <div class="modal-box">
    <h3 class="font-bold text-lg">Confirm action</h3>
    <p>This action cannot be undone.</p>
    <div class="modal-action">
      <form method="dialog">
        <button class="btn">Close</button>
      </form>
    </div>
  </div>
  <form method="dialog" class="modal-backdrop"><button>close</button></form>
</dialog>

Frutjam — 9 positions, 4 animations, LTR/RTL, closes via onclick:

<button class="btn" onclick="myModal.showModal()">Open Modal</button>

<dialog class="modal modal-center modal-middle modal-slide-up" id="myModal">
  <div class="modal-content">
    <h3 class="heading-lg">Confirm action</h3>
    <p class="para">This action cannot be undone.</p>
    <div class="flex gap-2 justify-end mt-4">
      <button class="btn" onclick="myModal.close()">Cancel</button>
      <button class="btn btn-error" onclick="myModal.close()">Delete</button>
    </div>
  </div>
  <button class="modal-backdrop" onclick="myModal.close()">Close</button>
</dialog>

Both use showModal() — the difference is the placement and animation system. Frutjam's modal-slide-up entrance animation is pure CSS. Changing to a top-right notification panel is one class change: modal-end modal-top modal-slide-end.

Migration from DaisyUI

Swap the import in your CSS entry point:

/* Before */
@plugin "daisyui";

/* After */
@import "frutjam";

Most component class names carry over directly:

DaisyUI	Frutjam
`btn`	`btn`
`badge`	`badge`
`card`	`card`
`alert`	`alert`
`modal`	`modal`
`drawer`	`drawer`
`navbar`	`navbar`
`menu`	`menu`
`accordion`	`accordion`
`tabs`	`tabs`

Modals use the same showModal() / close() pattern. Drawers switch from checkbox toggle to dialog.show() / dialog.close() — add an id attribute and update the trigger onclick. The Frutjam component docs show the exact HTML pattern for each component.

Frutjam Cherry: AI-Assisted Development Without Hallucinations

One practical challenge with AI coding assistants and component libraries is accuracy. When you ask Claude, Cursor, or Copilot to build a UI with Frutjam components, the model may hallucinate class names or generate outdated syntax learned during training.

Frutjam Cherry is a free MCP (Model Context Protocol) server that connects your AI assistant directly to Frutjam's live component documentation. Instead of guessing, the AI fetches exact class names, component structures, and working examples — on demand, always in sync with the latest Frutjam version.

Supported editors: Claude Code, Cursor, VS Code, Windsurf, Zed, Cline, and any MCP-compatible environment. Setup takes under a minute.

Cherry ships five built-in AI slash commands:

Command	What it does
`/figma_to_frutjam`	Converts a Figma design description to Frutjam components
`/image_to_frutjam`	Converts a UI screenshot to Frutjam markup
`/tailwind_to_frutjam`	Migrates raw Tailwind markup to Frutjam components
`/bootstrap_to_frutjam`	Migrates Bootstrap markup to Frutjam components
`/generate_theme`	Generates a custom Berry theme from your design tokens

Cherry is token-efficient — it fetches specs only when needed rather than dumping the full documentation into context. A free tier is available with no account required. Pro and Team tiers unlock unlimited requests, premium blocks, and all slash commands.

DaisyUI has no equivalent MCP integration. If AI-assisted development is part of your workflow, Cherry is a meaningful differentiator.

Get Frutjam Cherry

Frequently Asked Questions

Does Frutjam require any JavaScript?
No JavaScript required for core components. Accordion, tabs, popover, swap, and carousel are pure CSS. Modal and drawer use one line of inline onclick — native browser JS, no library. Combobox ships a createCombobox() helper for filtering and keyboard navigation.

Does DaisyUI v5 require a JavaScript plugin for interactive components?
No — DaisyUI v5 moved to CSS-based approaches. Drawer uses checkbox toggle, dropdown uses the Popover API, accordion uses <details>. Comparisons describing a required JS bundle apply to DaisyUI v4, not v5.

Will HTMX break Frutjam components?
No. CSS-only components (accordion, tabs, swap) need no re-initialization. Modal and drawer use inline onclick="id.showModal()" and onclick="id.show()" — plain HTML attributes that the browser evaluates on every render, including after HTMX swaps.

Can I use a custom theme?
Yes. Define CSS variables in a [data-theme="yourtheme"] block using OKLCH color values. Apply it with data-theme="yourtheme" on any element. Themes can be scoped — a single page can have multiple themes nested in different sections.

How does Frutjam handle RTL languages?
RTL is built into the layout system. Use ltr:modal-end rtl:modal-start on the modal to position it correctly in both directions. Drawer, popover, and other directional components follow the same ltr: / rtl: prefix pattern.

The Bottom Line

DaisyUI v5 is a capable, well-maintained library. If you need 80 components and 25+ themes and the community ecosystem matters, it is a strong choice.

Frutjam is the better fit if you need WCAG-compliant themes out of the box, a modal system with 9 placement positions and 4 animations, a popover with 12 positions, a built-in combobox, and a codebase designed for Tailwind v4 from the ground up.

Both are free, MIT licensed, and framework-agnostic. The question is how far the library goes on the details that matter for your project.

Browse all 65+ Frutjam components and see what the difference looks like in code.

Components mentioned in this post

What finally made you switch component libraries — accessibility, bundle size,
or just fighting the same override every project?

Why I Stopped Using JavaScript-Heavy UI Libraries (And Built a CSS-First Tailwind Component Library)

Mohammed Rashad — Tue, 22 Sep 2026 12:36:34 +0000

I build websites to solve problems, but after delivering several major multilingual platforms, I realized I was spending more time auditing performance than actually writing code. I'm a developer, not a professional performance janitor, yet I found myself stuck in a constant loop of chasing PageSpeed scores and fixing layout shifts caused by the very tools I was using. Instead of building new functionality, I spent more time fighting Cumulative Layout Shift (CLS) and writing tedious RTL (Right-to-Left) CSS overrides than actually shipping features.

I realized my 'shortcut' of using popular, JS-heavy component libraries was actually my biggest bottleneck. I was constantly battling render-blocking scripts just to open a simple dropdown and manually retrofitting WAI-ARIA tags to pass basic accessibility audits.

I didn't want another bloated library. I wanted a CSS-first Tailwind component library that made 100% PageSpeed Insights scores the default, not a struggle. That's why I spent the last few months building Frutjam.

Here is why shifting to native-first with CSS-first components completely changed my workflow, and why it will fix your Core Web Vitals, too.

1. The Power of a CSS-First Tailwind Component Library

Modern web technologies are increasingly approaching a "native-first" standard. Years ago, we had to rely on heavy JavaScript bundles just to create a functioning modal, a popover, or a toggleable accordion because the browser lacked built-in solutions. Today, the web platform has caught up. The browser's native rendering engine is now incredibly powerful, equipped with standardized elements designed specifically for these interactions.

By ignoring these native features and continuing to ship megabytes of state-management JS just for basic UI, we are actively working against the browser.

Frutjam takes a native-first with a CSS-first approach. This means we trust the browser to handle the core logic (Native-First) while using modern CSS for the behavioral styling and visual identity (CSS-First).

Take a standard accordion. Instead of writing complex state-management logic in React or Svelte, you can achieve a perfectly accessible, highly performant accordion using the native <details> and <summary> tags, styled cleanly with CSS:

<div class="accordion">
    <details name="default-accordion">
        <summary>Is this accessible?</summary>
        <div class="accordion-body">
            <p>Yes, because the browser handles the state natively.</p>
        </div>
    </details>
</div>

By combining this native structure with advanced CSS features like @starting-style, you get the exact same premium feel and smooth animations with zero JavaScript overhead. And once your markup is this clean, maintaining it becomes a completely different experience.

2. No More Ugly HTML: Fewer Classes, Faster Development

We all love Tailwind CSS, but we've all seen the "ugly HTML" problem: a single button wrapped in 20 different utility classes. It creates a cluster of code that is hard to read, terrible to maintain, and prone to copy-paste errors.

With Frutjam, you don't need to rewrite the whole Tailwind class string every time you need a button. I've grouped those utility clusters into clean, prebuilt component classes.

Fewer class names: Keep your markup clean and readable.
Easily maintainable: Update a component's style in one place without hunting down 50 different <div> tags.
Faster development: Drop in the component and move on to building your actual application logic.

Cleaner markup also means your theming system has less to fight against, which brings me to one of my favorite parts of Frutjam.

3. Unlimited Themes With Zero Effort

Most UI libraries restrict you to a handful of predefined themes. Frutjam adds a set of highly customizable color names directly to your Tailwind CSS configuration. This allows you to generate unlimited themes with almost zero effort.

Whether your client needs a dark, neon cyberpunk aesthetic or a clean, corporate minimalist look, the design system adapts to your brand colors instantly without requiring you to write custom CSS overrides from scratch. But themes are only useful if the colors actually pass accessibility standards — and that's where most libraries quietly let you down.

4. Accessibility and Color Contrast by Default

I was shocked to find that even "industry standard" libraries were failing basic WCAG contrast checks in their default themes. If you look at libraries like DaisyUI, their color contrast often fails across various themes. In modern web development, poor contrast isn't just bad UX — it tanks your SEO.

I built Frutjam so that color logic is handled automatically. Every theme you create within the library is designed to pass accessibility and color contrast checks out of the box. You get a production-ready, SEO-friendly UI without needing to be an accessibility expert. That kind of guarantee matters even more when you're building for global audiences — including right-to-left ones.

5. The "Big Three" Comparison

When I was architecting Frutjam, I looked at what was slowing me down with other tools. Here is how taking a native-first approach compares:

Feature	Frutjam	Preline	Shadcn
Logic	Native-First (CSS/HTML)	JS-Dependent	Framework-Specific (React/Svelte)
PageSpeed	Ultra Fast (Zero JS CLS)	Can cause render-blocking	Depends on your JS bundle
A11y / Contrast	Guaranteed Pass	Manual Effort	Manual Setup
Setup	Plug & Play	Requires JS Plugins	High Boilerplate
RTL Support	Native Built-in	Requires Overrides	Manual Configuration

Versus Preline: Preline relies heavily on JavaScript for components, which directly contributes to layout shifts (CLS) as the JS kicks in. Frutjam uses native HTML, meaning zero shift and pristine PageSpeed scores.
Versus Shadcn: Shadcn is beautiful but complex and highly opinionated. It requires copying massive amounts of boilerplate into your project. Frutjam is truly framework-agnostic. Whether you are spinning up a Django backend, a Node application, or a Svelte frontend, it drops in flawlessly.

That framework-agnostic design also makes RTL support something you get automatically, rather than something you bolt on afterwards.

6. First-Class Multilingual (RTL) Support

Building for the MENA region means RTL isn't an afterthought; it's a strict requirement. I got tired of writing dir="rtl" overrides for every single component. Frutjam handles multi-language layouts naturally without requiring massive CSS hacks, saving hours of development time on internationalized projects.

Stop Fighting Your Tooling

You shouldn't have to compromise between shipping fast, maintaining clean HTML, and hitting a 100% PageSpeed score. By shifting the heavy lifting back to the browser and utilizing a CSS-first Tailwind component library, high performance stops being a chore and becomes the default state of your application.

I've shipped real production projects with this approach — multilingual, RTL-ready platforms that score green across the board without a single JavaScript workaround for UI state. That's not a promise; it's just what happens when you stop fighting the browser and start working with it.

If you're building something where performance, accessibility, and clean code actually matter, this is the stack worth trying. The bloat you eliminate on day one pays dividends every time you ship.

If you are tired of JS-heavy interfaces and messy class clusters slowing down your builds, view the live documentation, check the source code on GitHub, or grab the package on npm to try the CSS-first approach for yourself.

DEV Community: Mohammed Rashad

Adding a Markdown Editor to Laravel Forms (No Sync Code Required)

A better approach

Setup

Blade template

Controller

Editing existing content

Validation failures keep the markdown

Vite or the CDN

Optional: auto-save draft

Features you get out of the box

Rendering markdown in Blade

Why the textarea matters

Zero JavaScript UI: Build Faster, More Accessible Web Apps With CSS-Only Components

The Browser Has Caught Up

Why Zero JavaScript UI Matters

Core Web Vitals and PageSpeed

Accessibility Without Configuration

Works Everywhere, Re-Initializes Nowhere

Browser Support

Real Components, Zero JavaScript

Modal

Animated Accordion

CSS-Only Tab Panels

Drawer

Toast Notifications

Searchable Combobox

What You Do Not Give Up

Where JavaScript is genuinely necessary: form validation with real-time feedback, async data fetching, complex application state: tools like HTMX handle it at the request/response level, not the component level. Your UI components stay clean and framework-agnostic.

Installation

Frequently Asked Questions

What Zero JavaScript UI Looks Like in Production

Dropdowns That Position Themselves: CSS Anchor Positioning Is Baseline Now

What changed

What it replaces

How Frutjam's popover uses it

Logical properties, so RTL comes free

What to do about older browsers

The pattern this belongs to

Why JS component libraries break with htmx (and what I use instead)

Why JavaScript-Driven UI Libraries Conflict With HTMX

Why Not Just Use Alpine.js?

Frutjam: Built for HTMX-Powered Apps

Modals via Native <dialog>

Accordions With Lazy-Loaded Content

Drawers via Checkbox

Server-Driven Pagination

HTMX-Powered Search with Combobox

Django Tailwind Components

Laravel Tailwind Components

Performance: The Frutjam + HTMX Stack

The Stack That Does Not Fight You

If you are building a Django, Laravel, FastAPI, or any server-rendered application and want UI components that work on first swap without re-initialization, explore Frutjam — the Tailwind CSS component library designed for this stack.

FastAPI + Jinja2 Setup

HTMX Attribute Quick Reference With Frutjam

Frequently Asked Questions

EasyMDE silently breaks Django forms (and what I use instead)

A better approach

Setup

Django form

Template

View

Editing existing content

Validation errors keep the user's text

Optional: auto-save draft

Features you get out of the box

Rendering markdown in templates

Why the textarea matters

Starting from scratch?

DaisyUI vs Frutjam: an honest comparison (I wrote one of them)

DaisyUI v5: What Changed, What Didn't

Where Frutjam Is a Better Fit

1. WCAG AA/AAA Contrast on Every Theme

2. Modal System: 9 Positions, 4 Animations, LTR/RTL Aware

3. Popover: 12 Positions, Click and Hover

4. Drawer: 4 Positions Built on <dialog>

5. Combobox: Built-In Where DaisyUI Has Nothing

6. Tailwind v4 Native

Component Coverage Comparison

Side-by-Side: Modal

Modals via Native `<dialog>`

4. Drawer: 4 Positions Built on `<dialog>`