Ark UI vs Melt UI: A Svelte 5 Component Library Comparison

A Comparison project evaluating Ark UI and Melt UI for building UI components with Svelte 5, focusing on how well each library integrates with Svelte 5's new runes.

🎯 Project Purpose

This project was created to evaluate whether Ark UI is a better fit than Melt UI when working with Svelte 5's modern features (runes like $state, $derived, $effect).

Why This Comparison Matters

During development with Melt UI, something started to feel off: Melt UI relies heavily on Svelte stores (the old state management pattern), which doesn't align well with Svelte 5's event-driven, runes-based approach. This means:

• ❌ No clean event handlers like onSelectChange
• ❌ Forced to use $effect everywhere to react to state changes
• ❌ Code feels more verbose and less idiomatic for Svelte 5

Ark UI, on the other hand, uses a framework-agnostic, event-based approach that feels more natural with Svelte 5.

🧪 Components Tested

This demo project includes implementations of common UI patterns:

• Select Dropdown - Standard dropdown selection
• Checkbox - Single and grouped checkboxes
• Pagination - Page navigation controls
• Combobox - Searchable dropdown with filtering
• File Upload - File input with preview

Each component demonstrates how Ark UI integrates with Svelte 5's reactive system.

🔑 Key Differences

Melt UI Approach (Store-Based)

<script>
  import { createSelect } from '@melt-ui/svelte';

  const { elements, states } = createSelect();

  // Have to use $effect to react to changes
  $effect(() => {
    console.log('Selected:', $states.selected);
  });
</script>

Ark UI Approach (Event-Based)

<script>
  import { Select } from '@ark-ui/svelte';

  let selectedValue = $state('');

  // Clean event handler - no $effect needed!
  function handleValueChange(details) {
    selectedValue = details.value[0];
  }
</script>

<Select.Root onValueChange={handleValueChange}>
  <!-- Component structure -->
</Select.Root>

✨ Why Ark UI Wins for Svelte 5

1. Event-driven API - Works naturally with Svelte 5's reactive model
2. Framework-agnostic design - Clean, predictable API
3. Better TypeScript support - Strong typing for event handlers and props
4. More mature - Better documentation (Understandable)
5. No $effect overuse - Write cleaner, more maintainable code

🚀 Getting Started

# Install dependencies
pnpm install

# Run the dev server
pnpm dev

# Build for production
pnpm build

📁 Project Structure

ark-ui-test/
├── src/
│   ├── lib/
│   │   ├── data.ts          # Sample data (units with contracts)
│   │   └── types.ts         # TypeScript type definitions
│   └── routes/
│       ├── +page.svelte                    # Select demo
│       ├── checkbox-demo/+page.svelte      # Checkbox demo
│       ├── pagination-demo/+page.svelte    # Pagination demo
│       ├── combobox-demo/+page.svelte      # Combobox demo
│       └── file-upload-demo/+page.svelte   # File upload demo

🛠️ Tech Stack

• SvelteKit - Full-stack Svelte framework
• Svelte 5 - Using runes ($state, $derived, $effect)
• Ark UI - Component library being evaluated
• TypeScript - Type safety throughout
• Vite - Build tool and dev server

💡 Key Learnings

1. Svelte 5 runes work best with event-based APIs - Libraries that emit events feel more natural than those relying on stores
2. $effect should be the exception, not the rule - If you're using it everywhere, the library might not align with Svelte 5's philosophy
3. Framework-agnostic libraries can be a good thing - Ark UI's consistent API across frameworks doesn't compromise the developer experience

🔗 Resources

• Ark UI Documentation
• Svelte 5 Documentation
• Melt UI Documentation

📝 Conclusion

For Svelte 5 projects, Ark UI provides a more idiomatic, cleaner development experience compared to Melt UI. The event-based API aligns perfectly with Svelte 5's reactive paradigm, resulting in less boilerplate and more maintainable code.

Note: This is an evaluation project. Both libraries have their strengths, but for Svelte 5 specifically, Ark UI feels like the better fit.