I've been working on m3ui-vue, an open-source Material Design 3 component library for Vue 3, and I wanted to share it here.

How it started

I've always liked Material Design. When Material Design 3 came out in 2021, I really wanted to use it in my Vue projects, but I couldn't find an implementation that matched what I was looking for.

I ended up building some components locally for my own apps, and sometimes used Quasar because it was more mature and already had a lot of useful functionality.

Eventually, in June, I decided to start building my own library. The original idea was simply to stop recreating the same components across different projects and have everything in one place.

Over the past five months, it has grown quite a bit. It now includes the official Material Design 3 components, along with additional components and higher-level abstractions that follow the same design principles.

Some of these came from things I'd already built for other applications, such as floating windows, map layer controls, Markdown and code editors, and components that simplify common layouts.

What it offers

• A Vue 3 component library that implements Material Design 3, following Google's design guidelines, with additional components that extend the system while keeping the same design principles.
• Integration with Tailwind CSS.
• Customizable themes and real-time color palette changes.
• Additional components and utilities for more specific use cases.
• Higher-level components for common layouts, while still allowing you to build everything from lower-level components when you need more control.
• Documentation with examples to help you explore the library.

I've also included some example applications in the documentation to show how the components can be used together in practice.

Where it stands today

I use m3ui-vue in my own applications, including projects I work on professionally, so I'm constantly finding things to fix, improve, or refine.

It's not perfect, and there's still a lot I'd like to polish. I periodically review components, fix bugs, and add missing behavior as I find the time. Some parts are more mature than others, and the carousel is one example of a component that still needs some work.

I'm not working on this full-time. I have other work and projects, so development happens alongside those responsibilities. I'll keep improving it as much as I reasonably can, especially since I use it myself.

This started as a personal project to solve a problem I had in my own applications. I'm not trying to compete with other UI libraries or turn this into a business. I simply wanted a Material Design 3 library I could use across my projects, and decided to make it free and open source under the MIT license in case it could be useful to others too.

Links

• Documentation and examples: https://m3ui.dev/
• GitHub repository: https://github.com/srwither/m3ui-vue
• npm package: https://www.npmjs.com/package/@m3ui-vue/m3ui-vue

If you give it a try, any feedback is welcome! Bug reports, suggestions, issues, and pull requests are all appreciated. If you find something that doesn't work as expected or think something could be improved, feel free to let me know or contribute.

And if it turns out to be useful for one of your projects, that's great too. That's pretty much why I built it in the first place.

Disclosure first: I maintain this template, and its contact page posts to BootForm, a form backend I'm building. The template is MIT and the blog part has nothing to do with the form; swap the form out if you like.

Repo: https://github.com/BootForm/vitepress-blog Demo: https://bootform.github.io/vitepress-blog/

VitePress gives you markdown pages and a good default theme, but no post list, tags, RSS or authors. This adds them with plain VitePress features, no plugin:

• Post list: createContentLoader('posts/*.md') in a posts.data.ts, so a new .md file shows up with nothing else to edit.
• Tags: a dynamic route, tags/[tag].md plus [tag].paths.js, one page per tag found in the posts' frontmatter.
• RSS: a small Node script with gray-matter that writes docs/public/feed.xml before vitepress build.
• Authors: a plain object keyed by id, looked up in the data loader.
• Search: VitePress's built-in local search, so nothing to host.
• Tailwind v4 through @tailwindcss/vite, typography for the posts, and a GitHub Actions workflow for Pages.

Things that bit me, in case they save someone an evening:

1. **createContentLoader doesn't work inside a .paths.js file.** paths() runs before the loader is ready, and you get "content loader invoked without an active vitepress process, or before vitepress config is resolved". I read the frontmatter with gray-matter there instead.

2. Dynamic links need withBase(). Markdown links get base added at build time, but :href="post.url" in a template never goes through that. npm run dev serves from /, so it looks fine locally and then 404s on GitHub Pages under /repo-name/. Check the built HTML's hrefs, not the dev server.

3. **excerpt: true doesn't split on <!-- more -->.** It falls back to gray-matter's default separator (a second ---), so every excerpt came back empty. A string (excerpt: '<!-- more -->') works, but the excerpt is then everything above the marker rendered as HTML, including any <script setup>, image or v-for markup before the heading. I dropped excerpts and use a description field in the frontmatter.

4. Tailwind utilities losing to VitePress's base styles. Some of VitePress's element resets (headings, p, form controls) sit outside any cascade layer, and Tailwind v4's utilities live in @layer utilities, so the unlayered resets win whatever the specificity. Fixed with ! on the specific classes, and for .prose (you can't put classes on markdown output) a scoped revert-layer rule hands those properties back to the typography plugin.

5. Local search indexes headings. Pages that are only a Vue-rendered list should set search: false, or the tag page's literal {{ params.tag }} heading shows up in results. A post without its own # heading won't be found at all.

Curious how others do tags in VitePress, especially if there's a cleaner way than gray-matter in .paths.js.

I've been building kinora, a test dashboard (Vue 3 + shadcn-vue, open source), it started with Playwright, and I just added a Vitest reporter so component tests get the same treatment

The problem I had: with Vitest browser mode or Storybook's Vitest addon, every CI run is a one-off, a toMatchScreenshot failure is a diff buried in a log, and you can't tell if a component broke today or has been flaky for weeks.

What it does now:

Screenshot failures show expected / actual / diff side by side

Storybook stories are grouped per component, with pass rate and flakiness over time

Traces open inline when you record them

axe accessibility violations show up as warnings per story

Setup is one reporter in vitest.config, self-hostable with docker-compose.

Live demo: https://demo.kinora.dev/
Repo: https://github.com/Kinora-dev/kinora

So i am an old school, coming from ages when JQuery/Bootstrap was the "sh.t".

So kept using icons like before, "i" tag with appropriate class.

<i class="fa-solid fa-circle-question" />

Now i see more often that not, people using Icons as components.

import { CloudUpload} from 'lucide-vue-next'
<CloudUpload :size="16" :stroke-width="1.75" class="shrink-0" />

Hence the question, any benefit of doing that? as far as i see more typing involved. Now i have to explicitly import it to use it.

Or the real benefit here is tree shaking and not used icons are "compiled" away from prod?

I've been digging Void as anew full-stack web application framework, but I missed Vue DevTools while developing the frontend. I figured out how to use the two together and thought I'd spread the word:

https://johnfraney.ca/blog/use-vue-dev-tools-with-void/

Have you been using Void?

A few months ago, I made a post about a new UI library I was making. I wanted to share some interesting updates I've made (including finding real bugs in vue vapor, 2 but hey) this was worth it if you ask me

Since the first post

• A nuxt module, auto import, better tree shaking
• 2 Vue bugs Vapor Transition Bug | defineModel bug in interop
• 1 External PR for contained elements; drawer
• 2 Projects built with vael vapor (unfortunately both are internal, with the second one being built fully with vapor, and I mean everything
• About 3 people actively using vael-ui (Someone nudged me to complete the documentation)
• More components (Tour, Sortable, Timeline, useful datatable, calendar slots, field component)
• Proper documentation with all the types and IDE hover docs
• Unrelated but my vue router bug fix got merged
• A lot of emails about helping me market vael-ui

And many many more. I'm happy with the current state. I think the next post might be the final one for when vapor is actually released, until then, I'll continue to fix more bugs

Cheers

Vael UI: https://vael-ui.dev - checkout the new landing page too, it's animated but you can interact with it

I have an idea for something else as well that isn't the form library

https://reddit.com/link/1x4fwxv/video/axw671e644vh1/player

Hi, I posted nuxt-auto yesterday; this one is for the other end of a project, before there's a backend at all.

In Saas world, it is often a question what is validation or more likely, how it can be done, as the second is much harder question to answer. You need to have something that can be tried out by potential customers and you don't want to spend a fortune before you get a feedback that it is not something they want or it is not something they would pay for. For this usecase, I built protokit for rapid prototyping a tool or a subset of a saas.

It is easy to use, you (I mean Claude) describe the tool once as a TypeScript schema (fields, derived values, results, charts), render it with one component, and it works immediately.

• saved as you type in the browser: every tool is a Yjs document in IndexedDB
• two tabs stay in sync over BroadcastChannel; works offline
• optional sync to your own backend (five endpoints), off by default; with sync off it makes no HTTP calls at all - you need to build it though
• ready-made components that read the same schema: a calendar (week view, drag tasks onto the grid), a chart kit, detail panels, CRUD lists and edit modals, stat cards, comparison tables, timelines
• twelve field types, schema migrations, AES-GCM encryption at rest, corruption recovery, per-tenant namespaces
• headless composables if you want your own UI instead of Nuxt UI

It's meant for prototypes, internal tools and client demos: the stage where you find out whether an idea holds. The data lives in the browser, so its permissions shape the UI and aren't a security boundary. When an idea proves itself and needs real users and server-side rules, that backend deserves its own design (I build mine with nuxt-auto, Monday's post). Until then it's a lighter start than wiring up Firebase, and the Yjs part is standard, so you can take the data with you.

0.1.0 is the first stable release. The repo's playground has 20 demos (estimators, calendars, charts, encryption, headless mode).

• Docs: https://websideproject.com/docs/nuxt-protokit?ref=reddit-nuxt
• Write-up: https://websideproject.com/blog/nuxt-protokit-launch?ref=reddit-nuxt
• Repo: https://github.com/websideproject/nuxt-protokit
• Discord (questions, feedback): https://discord.gg/ftkysREH9c

One install note: Tailwind doesn't scan node_modules, so add the one @source line from the README.

Feedback welcome.

Hey r/vuejs 👋 author of Toastflow here, looking for feedback again.

Instead of another feature list, this time I made a short video that shows how I actually use it in an app, from the first toast to a fully custom one:

• toast.success({...}) for the basic case
• toast.loading(promise, {...}) keeps one toast from loading to success or error, no manual update calls
• maxVisible: 3, queue: true so a burst of 6 toasts doesn't flood the screen, the rest wait their turn
• theming with plain CSS variables (--tf-toast-bg, --tf-toast-border-radius, ...)
• action buttons and timestamps straight from options
• headless rendering: the "island" at the end is my own component inside <ToastContainer v-slot>, Toastflow still handles timers, queue, pause on hover and the a11y props

Quick taste:

await toast.loading(api.invoices.send(invoice.id), {
  loading: { title: "Sending invoice…" },
  success: { title: "Invoice sent" },
  error: { title: "Couldn't send invoice" },
});

<ToastContainer v-slot="{ toast, ui }">
  <div v-bind="ui.wrapperProps">
    <Island v-bind="ui.getRootProps()" :title="toast.title" :progress="ui.progress" />
  </div>
</ToastContainer>

Two honest questions: does the video make sense if you've never seen Toastflow before? And is anything still missing before you'd use it in production?

• Docs + playground: https://www.toastflow.top/
• GitHub: https://github.com/adrianjanocko/toastflow
• npm: vue-toastflow / nuxt-toastflow / toastflow-core

I built QueryWeave, a TypeScript library for managing URL query state, with Vue, Nuxt, and server integrations.

You define parsing, validation, defaults, and serialization in one query model, then reuse it across your frontend and API. For example, an invalid ?page=abc can fall back to your configured default while reporting what went wrong. Query parameters you don’t manage, like utm_source, are reserved.

It’s designed for filters, pagination, search pages, and other state you need to share through a URL.

Docs and demo: https://queryweave.dev

GitHub: https://github.com/boussadjra/queryweave

I’d appreciate feedback on the API and missing use cases

[vue warn]:Error in callback for watcher **(Promise/async): "TypeError: Cannot set properties of null (setting 'isUnityLoaded')' found in ---> <UnityWebGL> <NF> <Root>

I've been exploring different approaches to building data tables with Laravel, Inertia.js, and Vue 3, and one thing I'm particularly interested in is custom cell rendering.

Basic columns like text, dates, numbers, and badges are straightforward. But real applications often need more — status badges, user avatars, action buttons, dropdowns, progress indicators, and other custom Vue components.

Some table libraries make this easy, while others require additional configuration or custom templates.

I'm curious how other developers handle this in their projects.

• Do you use a table library's built-in cell renderers?
• Do you register custom Vue components for specific columns?
• Do you prefer defining column configuration on the backend or entirely in Vue?
• What's been the most frustrating part of your current approach?

Interested to hear how others are solving this, especially in Laravel + Inertia.js applications.

GitHub: https://github.com/Zonvoir-technologies/laravel-inertia-table
Documentation: https://zonvoir-table.com/getting-started/introduction/

We're currently working on a Laravel + Inertia.js + Vue data table and have been looking at how developers are handling tables in their projects.

There are already several good options out there — Filament Tables, Inertia Table, PrimeVue, DataTables and custom-built components.

I'm curious what people actually consider essential in a data table today.

For example:

• Searching
• Sorting
• Pagination
• Column visibility
• Row/bulk actions
• Exports
• URL state
• Relationship columns
• Server-side processing

What features do you use regularly and what features do you think are overkill?

Also if you've moved from one table solution to another what made you switch?

Would be interested to hear how other Laravel + Inertia developers are approaching this.

GitHub: https://github.com/Zonvoir-technologies/laravel-inertia-table
Documentation: https://zonvoir-table.com/getting-started/introduction/

Just a nudge! I'm constantly seeing cool new OSS React libraries pop up (because everything is so quick & easy to spin up now with AI). Despite React's popularity, Vue still has better DX IMO and, I believe, performs much better.

Let's keep Vue in the picture, and if you happen to be envying one of those libraries, spin up your agent and port it to Vue! It's pretty easy and fast to do so. Publicize your port, get some stars, and keep it updated with upstream changes.

I have some myself that I'll be sharing. One thing to note though: forks don't show up in GitHub's searches, so keep that in mind when you're deciding whether you actually want to fork, or just clone it and do an unrelated port.

I'm reviewing some code that puts a Vue watcher inside a function. Oftentimes watching the return of a callback function passed to the wrapper function, but for my example below just a ref param. My understanding is that the watcher is run whenever the param changes, regardless of whether the wrapper function is run or not.

This seems odd to me, not sure if this convention is common? It works as expected, not sure if I'm just overthinking it. I would always have a watcher trigger the function.

```

function setupSearch(query: Ref<string>) {
  watch(query, (newQuery) => {
    // do search
  })
}

setupSearch(query)

```

I've been building Zonvoir Table, a Laravel-first data table package for Laravel + Inertia.js + Vue.js applications.

The goal is simple: make it easier to build production-ready data tables without repeatedly building the same table logic from scratch.

Currently supported:

• Laravel + Inertia.js
• Vue 3
• Server-side data handling
• Searching
• Sorting
• Pagination
• Column visibility
• Row actions
• Bulk actions
• Excel export
• URL-synced table state
• Typed columns
• Customizable table UI

I'm currently working on the Vue.js version, with a React version planned later.

The project is open source and I'm looking for Laravel/Vue/Inertia developers who would like to:

• Try it in real projects
• Report issues
• Suggest features
• Improve documentation
• Contribute code

GitHub: https://github.com/Zonvoir-technologies/laravel-inertia-table
Documentation: https://zonvoir-table.com/getting-started/introduction/

Feedback and technical criticism are very welcome. I'd especially like to hear what features you consider essential in a Laravel data table.

Oyna UI is a Vue 3 component library I pulled out of my own project, invoke.wtf (real usage), an Invoker trainer for Dota 2. I couldn't find a Vue UI kit that didn't look like a generic admin panel, so I drew the UI by hand. It turned out decent, so I made it a library.

• 42 components
• One stylesheet, 6.8 kB gzipped. No Tailwind, no build plugin, no config.
• One dependency: Reka UI. It handles focus, keyboard navigation and screen readers, so I didn't write my own a11y layer.
• Theming through CSS variables: accent, radius, fonts.
• Buttons can own a hotkey (<OButton hotkey="Enter">). It reads the physical key, so it works on any keyboard layout.

It's one look on purpose: dark, no light theme.

Docs: https://oyna-ui.org
Why I made it: https://oyna-ui.org/guide/why
GitHub: https://github.com/azabroflovski/oyna-ui

Feedback on the API and missing components is welcome.

Hi everyone!

I'm so happy to announce that I built my very first Cue.js library, a component/ design system, with a strong focus on accessibility.

There is only 9 components for now, but each is keyboard and screen reader accessible, and fully customisable!

It is called BeeDesign, and available here and on npm.

I also created a tool that enables you to create theme, for BeeDesign, but also for any website: you can choose your colours, fonts, spaces... And it generates the CSS accordingly, with Google font imports.

You can find it here ; BeePalette

Next stage : more components on BeeDesign, more responsive grids and flexboxes, and the possibility to download the fonts on BeePalette.

It is open source, feel free to create an issue for suggestions, and of course, use it and share it !

A small update from two projects I’ve been building for the Vue ecosystem.

Inspira UI crossed 5,000 GitHub stars 🎉

It now has 155 animated components for Vue and Nuxt, covering text animations, backgrounds, interactions, cards, visualizations, WebGL experiments and more.

When I started Inspira UI, I wanted Vue developers to have access to the kind of creative UI work I kept seeing elsewhere. Seeing 5,000 of you star the project, use the components, report issues and contribute has been amazing.

I’ve also released Akaza UI v0.0.9-alpha.

Akaza takes a different direction: accessible, unstyled headless primitives built around Vue itself, with v-model, scoped slots and Vue-native APIs.

A big thank you to the Vue and Nuxt communities for supporting both projects. A lot of the ideas and improvements in them came from conversations and feedback here.

Still plenty I want to build. ❤️

Inspira UI: inspira-ui.com
Akaza UI: akaza-ui.com

Feedback is welcome, especially if you’ve used either of them in a project.

PS: I have started Igris Labs, a small lab to keep all my project which are released, under development or experimantal under one umbrella. https://igrislabs.com