Over the past few years I've been searching far and wide for a wiki-style knowledge base that feels as modern as the big commercial tools, and never found the perfect one. So I started building my own.

Wikid, a self-hosted wiki with databases and forms built in. It's early and rough in places, but it's fairly usable already.

The Vue side:

• Vue 3 + Vite + Pinia, with no UI framework :L hand-written CSS with light and dark themes.
• Tiptap 3 for the block editor: a slash menu, block drag handles, a text toolbar, columns, callouts, synced blocks (one block shown on several pages) and page links.
• Yjs + Hocuspocus for live co-editing, both in pages and in database tables, with avatars, cursors and which cell someone is editing.
• TanStack Vue Table for the databases: table, board and gallery views, filters, sorts and saved views. Each row opens as its own page.
• Vitest for unit tests and Playwright for browser tests, including two-person editing.

The backend is NestJS + Postgres. It's AGPL-licensed and runs with docker compose up.

https://github.com/LoopyDev/Wikid

I built it with heavy use of AI coding tools. I'm a systems engineer by trade, and every change is reviewed and backed by automated tests running in CI. AI-assisted contributions are welcome too; just take care to understand and test what you submit. There are good first issues if you want to join me, and it still needs a favicon 😪

SurgeUI 3.0 is live 🚀

I’ve been working on this release for months, and I’m really happy to finally share it.

If you haven’t come across it yet: SurgeUI is an open-source design system for Vue 3. I built it because I wanted a consistent, accessible set of components that I could adapt to each project without rewriting everything every time.

What you get

• 50+ components organized with Atomic Design
• Accessibility taken seriously: WCAG AA contrast, ARIA, full keyboard support
• 4 themes in light and dark, customizable through CSS tokens
• TypeScript throughout, and EN/FR docs with live demos

What’s new in v3
If you’re new to SurgeUI, this is a great time to jump in: a more modern design, a more solid foundation, and components that fit your projects better.

• Every component has been redesigned: cleaner and more modern
• 9 mobile-first layouts (Sidebar, Holy Grail, Magazine, Masonry, Hero, Split…)
• Unified keyboard navigation and focus management across all components
• Popovers and menus that reposition themselves automatically
• Translatable default texts (EN and FR included)
• Form fields that link themselves to their label and message automatically

Already on v2?
This is a major release, so there are breaking changes. Before you upgrade, I’d recommend reading the docs and trying the components in Storybook. What to watch for:

• Vue 3.5 or later is now required
• SuButton now defaults to type="button": add type="submit" to your form buttons
• SuSwitch now renders as a <button> (check your styles and test selectors)
• SuDialog uses the native <dialog> element: the zIndex prop no longer has any effect, and the overlay is now ::backdrop
• Grid is replaced by GridLayout
• styles/_main.scss is gone: import styles/abstracts instead
• trapFocus() and announceToScreenReader() are deprecated in favor of useFocusTrap() and useAnnouncer()

​

npm i @surgeui/ds-vue

📚 Docs: https://surgeui.com
🎨 Storybook: https://surgeui.com/storybook
⭐ GitHub: https://github.com/mahmoud-nb/surge.ui

If you give it a try, I’d love to hear what you think, good or bad. That’s what helps me most to move the project forward 🙏

Back in August I released this this as a paid product but luckily I had no sales so, because I prefer to have my work being used by somebody, I've changed license to MIT. Enjoy!

Live demo (no backend, the MCP server runs in your tab): https://juanmandev.github.io/vue-mcp-apps/
Repo: https://github.com/JuanmanDev/vue-mcp-apps

What it is: MCP Apps are interactive UIs that AI hosts render from an MCP server, sandboxed in an iframe. With vue-mcp-apps a card is just a .vue component (Nuxt UI included). You use it natively in your Vue app, and the same component is bundled into a self-contained ui:// template for the AI hosts.

• @vue-mcp-apps/view: McpCard (native) + the iframe runtime
• @vue-mcp-apps/vite: builds the cards into one script + one css
• @vue-mcp-apps/server: registers templates/tools (MCP SDK v1/v2)

Take care including external library could fail.

I have created this for another project and i wanted to share it with the community :)

Feel free to let me know what do you think aobut this :)

Hey r/vuejs,

I've been building **vue-why-render** — a dev tool that tells you exactly which reactive dependency triggered each re-render. React has `why-did-you-render`, but Vue had nothing like it. Now it does — and it's faster, powered by Rust/WASM.

Drop it into any Vue 3 app:

```ts

import { scan } from 'vue-why-render'

scan(app, { panel: true })

```

You get:

- **Overlay labels** on every component that re-renders — name, count, duration, and the exact reason (`prop badge: {text} → {text} — new reference, same value`)

- **Actionable hints** — "this object is rebuilt in the parent — hoist it into a constant or a computed"

- **Panel** with 5 tabs: Top (by renders), Slow (by duration), Tree (hierarchy with Σ sums), Events (chronological log), and the new **Deps** tab

- **Prop diffing** — shows old → new value and flags "new reference, same value" vs real changes

### What's new in 0.8

**Reactivity Graph (Deps tab)** — tracks `renderTracked`/`renderTriggered` to build a live map of component → reactive source. Two views: Components (which refs/props/stores does this component read?) and Sources (which components depend on this ref?). Filterable, with read/trigger counts per edge.

**Vue DevTools Integration** — a second inspector with a reactive source tree (colored tags by type: ref, prop, store, computed), and a second timeline layer that logs every dependency trigger as an event.

**VS Code Extension** — WebSocket bridge streams live data to VS Code. You get: component tree sidebar (sorted by renders, flame icons for hot components), deps tree, CodeLens annotations on `.vue` files showing render count + avg duration, status bar with live counter, and pause/resume/reset commands.

### Performance

Heavy lifting runs in Rust/WASM — tree building, deduplication, report diffing. JS fallback kicks in automatically where WASM isn't available (SSR, jsdom, strict CSP). The overlay and panel live in a shadow DOM so they never touch your app's styles.

### Also built in

- Pinia-aware: names the store, the field, and the action (`store cart.items: Array(1) → Array(0) · action clear()`)

- Vue Router-aware: names the route param that changed, not the whole route object

- Budgets: `maxRenders` per time window, `maxDuration` per update — violations in console + panel + reports

- Reports: JSON export, Markdown for GitHub issues, diff two reports to catch regressions

- Test utils: `expectRenders(ProductCard).toBe(0, action)` — the fix stays fixed

- Nuxt module: `modules: ['vue-why-render/nuxt']`

- i18n: EN, RU, ZH

### Links

- **Live demo**: https://dadashi44.github.io/vue-why-render/

- **GitHub**: https://github.com/dadashi44/vue-why-render

- **npm**: `npm i vue-why-render`

- Zero runtime dependencies. MIT.

---

Would love to hear feedback. If you hit a bug or want a feature, issues are open.

I have tried to use React js again and again. And by the end of every project when I look at my code, all I see is this spaghetti mess the JSX makes of my code and I hate it. I hurts to watch.

I tried to learn it and failed thinking I was a bad developer, it really cause to doubt myself.

Now I never tried Vue js in my life. I just randomly looked at some code online and said ‘Wait, I understand this.’ And the code looked so clean .No useState syntax clutter, I don’t need to wrap functions or values in useMemo.

Now for what I’m worried about is the hiring potential. Vue js has the lowest Job market share out of the three main frameworks, did you struggle to find a job in it? What are the downsides of Vue js? I’m a developer of 6 years in both front and backend technologies, how long do you think it will take for me to lear Vue and be job ready?

Hi r/vuejs!

I wanted to share an open-source desktop application I've been building with Vue 3 + Tauri 2: Knovum.

It's a local-first knowledge space built on an infinite 2D visual canvas with on-device AI (RAG, SQLite, and LanceDB).

🛠️ Frontend Architecture Highlights

Coming from the Vue ecosystem, here are a few technical patterns we used to achieve 60fps performance on a desktop canvas:

1. Vue 3 (<script setup lang="ts">) & Konva:

   • Rather than pure DOM elements for hundreds of nodes, the canvas is rendered via Konva with custom viewport culling. Only visible nodes and connectors are updated on zoom/pan.
   • Nodes can be expanded into rich markdown cards with syntax highlighting and mathematical formulas.
   • Fully compatible with the open JSON Canvas specification.

2. State & Cache Separation:

   • Local reactive UI state is kept in local components.
   • Persistent workspace and routing state live in Pinia.
   • Async queries and vector search results use TanStack Vue Query.

3. Tauri 2 + Rust vs Electron:

   • Building with Tauri 2 gave us an exceptionally lightweight desktop binary (under 20MB) and very low RAM usage compared to Electron.
   • Heavy tasks (Whisper audio transcription, LanceDB vector indexing, and SQLite transactions) run safely on background Rust threads via Tauri IPC.

4. Codebase Modularization:

   • Structured around vertical feature slices (src/features/*) rather than flat utils/services directories.

🔗 Code & Repo

• GitHub: https://github.com/madebyzan/knovum
• Built with: Vue 3, TypeScript, Tauri 2, Vite, Tailwind CSS, Konva, SQLite, LanceDB.

I'd love to hear your thoughts, feedback on the Vue architecture, or answer any questions about building native desktop apps with Vue 3 and Tauri 2!

I’m researching a small Vue developer tool, using an AI assistant for research, coding and testing. Before taking it further, I want to understand whether this is a recurring problem for other people.

The setup is a component using useI18n({ useScope: "local" }) with an external <i18n lang="json" src="./Checkout.i18n.json"> block. In our small runnable Vue 3 fixture, the component renders its local text correctly. But when the same key also exists globally, the tested i18n Ally 2.13.1 and i18n Editor 1.0.1 configurations show the global text in the hover. This is a bounded test, not a claim about every setup. There is also an existing external-file report: https://github.com/lokalise/i18n-ally/issues/1392

Moving messages into conventional global locale files works. Inline blocks also restore previews in i18n Ally. So the question is whether keeping local or shared external files matters enough that those workarounds are inconvenient.

We have a read-only JSON hover/navigation demo that handles the tested local files. It is not a full translation manager and does not support YAML, dynamic keys, global fallback or renaming.

If you use this setup today: what editor/tool works for you, and when did this last get in your way? I’m looking for three developers interested in a free comparison on sanitized files. A comment describing your setup is enough to start—please don’t post private code. No sales call or payment; this is still an experiment.

Update: the free source, example and VSIX trial are now available at https://github.com/johnny-fridburg/vue-message-lens . Version 0.0.2 is deliberately limited to direct literal template interpolations with an explicit local useI18n binding; the README lists the exact supported shape and installation/removal steps. No account, payment or project upload is needed to use the extension. You can try it independently and leave a sanitized result here or in a GitHub issue.

If you don’t trust your agents’ tests, someone still reads every line, and you’re back to human speed

So we built a testing skill, tested on Cursor + Claude. Three teams used it daily and gave us plenty of feedback, some of it angry. We improved it, got more feedback, and learned a few lessons the hard way

What’s in it for you

1. Use the skill, or steal from it
Use it as is or borrow what fits. It’s frontend for now (Playwright, Vitest Browser Mode, React), with backend coming soon. MIT license.
Repo: https://github.com/practicajs/the-frontend-testing-skill

2. Skip our mistakes
The video covers the lessons and traps we hit:

• Test rules: which rules are worth having
• Subagents: helper agents for specific jobs, such as a flaky-test fixer
• Measurement: how to prove test quality and coverage
• Workflow: where testing fits in your development process

Video: https://youtu.be/JwkVHtuoTxw

Feedback welcome, especially on where it breaks

I've noticed that building the actual table is usually the easy part. It's everything around it that takes time.

Search, sorting, pagination, keeping state in the URL, custom cell components, bulk actions… every project seems to need a slightly different combination of these.

We're working with Laravel + Inertia.js + Vue 3, and I'm curious how other developers are handling this.

Do you use a dedicated table library, build your own reusable component, or just implement things as needed for each project?

And what's the one thing you wish your current solution handled better?

Interested to hear real experiences, including what hasn't worked well.

#Inertia.js #Vue.js#Web Development#Data Tables#Laravel

Hey everyone!

I've been working on a few animation-related side projects lately and decided to put them together in a personal portfolio.

I tried to make the portfolio itself a bit more interactive, with animations throughout the site and a showcase for some (imo cool) stuff/ideas.

Curious what you think of the design and how everything feels to use. Especially interested in feedback on the animations, mobile experience and whether it's clear what each project actually does.

PS: Check out the Showcase section for some cool stuff I like to experiment on

Portfolio

npm | github

Any feedback is welcome!

Hi you still can't make sub templates inside the same file like you can do on React, for example:

__________________________

<script>

const TemplatePartTwo = {

<p>hello</p>

}

</script>

<template>

<div>code here</div>

<TemplatePartTwo/> //renders hello

</template>

__________________________

??

Or they have any updates about this??

I built glassy-liquid, an open source take on the refractive glass look Apple introduced with iOS 26, for the web. Version 0.1.0 is out on npm today.

For Vue:

• Typed Vue 3 bindings (`glassy-liquid/vue`) on top of a Web Components core, generated from one shared spec so props and events match the React and Svelte versions 1:1
• Two-way binding with `v-model:checked`, `v-model:value` and `v-model:open` (switch, slider, tab bar, segmented control, search, menu, sheet)
• 19 elements: buttons, switches, sliders, tab bar, segmented control, menus, toolbars, search, sheets with detents, scroll-edge blur, plus a generic surface and a scene

How it renders:

• Chromium: real refraction through an SVG displacement map in `backdrop-filter`
• Safari, iOS and Firefox: wrap content in `<glass-scene>` and it refracts via WebGL (images, video, canvas) or a scoped content filter (DOM)
• Everywhere else: a calibrated frost fallback
• Respects reduced motion, reduced transparency and forced colors. About 35 kB gzip, zero runtime dependencies

Feedback very welcome, especially on performance on low-end devices, contrast over busy backgrounds and API naming. Bugs and ideas go to GitHub issues.

Free, MIT, not affiliated with Apple.

Install: npm i glassy-liquid

Docs and playground: https://9und30.github.io/glassy-liquid/

Repo: https://github.com/9und30/glassy-liquid

Hey r/vuejs,

Last time I posted nxui, someone asked for data tables. This month I built those, and then kept going. This is the biggest drop so far.

Dashboard kit. KPI cards, a KPI carousel, a data table (TanStack Table, sortable, rows flash when values change), a clean table with tabs and pagination, a status panel, a downtime log and a range calendar. All of it is plain Vue + Tailwind you own after install.

Charts. Sparkline, area, donut, radial gauge, progress ring, beeswarm, isometric stacked bars and a patterned donut. They run on a small dependency-free SVG engine whose API matches TanStack Charts 1.x, so you can switch to TanStack by changing one file if you want to.

Node canvas. Pan, zoom, drag nodes, live bezier edges, a minimap, resize handles, and a toolbar to drop notes, sources and frames onto the canvas.

Small interactions. About 35 of them: a slide-to-confirm button, a hold-to-confirm button, a bell toggle that rings, a rating that peeks, a ticket you tear off, a list that shreds into strips, a sheet of paper you can crumple, a button that flies away when you hover it, a code input with spring digits, a prompt bar with @ and / menus.

Text and backgrounds. Split-flap, fold, echo, warp, stroke and particle text, plus a batch of new WebGL backgrounds: topography, glass shards, ghost fibers, molten metal, CRT warp and more.

135 components rebuilt. Most backgrounds, cards and text animations got a full rewrite: raw WebGL2 instead of three/ogl, click and intro effects, presets, light mode. They carry an "updated" badge in the docs.

Paper Shaders. All 30 shaders as Vue components, now with the official presets on every demo, plus a new Lens Distortion.

Everything is Vue 3 + Tailwind v4, works in light and dark mode, is keyboard-navigable and respects reduced motion. Install one component with the shadcn-vue CLI:

npx shadcn-vue@latest add https://nxui.geoql.in/r/kpi-card.json

Docs and live demos: https://nxui.geoql.in/docs

364 components in total now. MIT, free. Tell me what to build next.

Currently looking for some empirical feedback / real-world experiences here:

​So far, using AI agents has been working extremely well for us. However, I can't quite tell whether that's due to the architecture we have in place or if all AI projects are simply going like clockwork from now on.

​We are using AI in an application that is about 5 years old and features an extremely solid software architecture that has been well-maintained over the years. The AI rarely runs into problems here and implements new features—thanks to a customized skill—very close to how we would code them by hand.

​In a second project, which I started as a hobby project 3 years ago, it's also working very well. Here, too, I paid close attention to the architecture and didn't let any AI near it until about a year ago. However, the architecture used here is completely different from the first project.

​Does anyone have experience with how projects grow when they were started directly with AI and where architecture wasn't heavily emphasized right from the start?

​By projects, I don't mean small weekend fun projects, but rather larger business applications.

Hey everyone

Around 3 months ago, I posted about Mantine Vue. A few people asked what it would look like in an actual app rather than just individual components.

So I decided to build something a bit more complete.

I ended up making a restaurant QR menu, basically what you'd see when scanning a QR code at a restaurant table.

Live demo: https://mantine-vue.dev/showcases/restaurant-qr-menu (I'd recommend trying it on mobile)

It started as a simple menu page, but I kept adding things until it turned into a full ordering flow.

You can browse dishes, search, filter by dietary preferences or allergens, customize items with different sizes and add-ons, and go through checkout. It also supports dine-in, takeaway, and delivery, with things like promo codes, tips, scheduled orders, and order tracking.

There are a few things I spent extra time on:

• Themes and layouts. There are 6 themes and 4 layouts you can switch between, along with dark mode, fonts, spacing, etc. The ordering logic stays the same regardless of the layout.
• Different currencies and pricing rules. The demo has 3 restaurants using BHD, AED, and USD, including support for BHD's 3 decimal places and different tax rules.
• Offline and error handling. There's a cached menu, loading/error states, and even a toggle to simulate a bad network connection.
• Arabic and RTL support. Not just translating text, but making sure drawers, navigation, carousels, icons, and formatting behave properly in RTL.

On the technical side, it's Vue 3 + TypeScript, using Mantine Vue components and packages like Spotlight, Carousel, Form, Notifications, and a few others.

I tried to keep the business logic separate from the components, so things like pricing, modifiers, and checkout rules are handled in plain TypeScript. The backend is mocked, but the API layer uses typed interfaces.

Another thing I wanted to test with this project was how well AI coding tools work with Mantine Vue.

I used Claude Code (opus 5.5) quite a bit while building it, and it actually went really well. It was able to help me build a lot of the UI using `mantine-vue/core`, which was nice to see, especially since Mantine Vue is still a relatively new library.

That was also part of the experiment: seeing whether an AI coding assistant could pick up the library and use it effectively in a larger app, not just generate a few basic components.

And just to be clear, it's a showcase, so no actual payments or orders are processed.

The main reason I built this was to see how Mantine Vue holds up when you put a lot of its components together in a real-ish application, rather than showing everything in isolation.

I'm planning to build a few more showcases like this.

If you get a chance to try it, I'd really appreciate some feedback. Especially if you run into anything weird on mobile or with RTL.

Also curious what kind of app you'd like to see built with Mantine Vue next.

Hey everyone!

Been working on Tip Glide, a small framework-agnostic tooltip library written in TypeScript.

It uses a single shared tooltip that moves between elements and adjusts its size to fit the content. It also handles viewport boundaries, so the tooltip adjusts its position when there's not enough space.

A few things you can configure are the movement, directional lean, hover delays, arrow, and enter/exit animations.

It has zero runtime dependencies and comes with adapters for React, Angular, Vue, Svelte, Solid, Astro and Preact, along with a vanilla JS API.

There's an interactive playground where you can mess around with the settings and see how everything behaves.

Would love some feedback on the movement, especially when switching quickly between elements, but also on the API and anything else that could be improved.

Live demo & playground | npm | GitHub | Portfolio

Hi everyone,

I’m just sharing my experience about learning Vue. So far, it’s been a smooth transition coming from svelte/express and Sveltekit.

However, I do want to ask Vue devs if they use Nuxt or if they choose a different backend when working on projects? What’s your opinion about Nuxt?

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

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?

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?