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!

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.

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??

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!

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

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.

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

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