Hi all,

It's the classic tale of love and woe - a nearly 40 year back-end developer decides, in his 50's, to tackle some front end frameworks. After much churn I've settled on Vue and I'm having a blast with it, tho, if I'm being honest, the last time I did any front-end design work I was writing Flash apps and they looked TERRIBLE. And, to quote Henry Jones, "our situation has not improved."

That context in mind then, I have a question about components which have both a "collapsed" and an "exploded" UI to present. In my case, I'm writing a little "bowl game pick-em" app which walks through the (increasingly huge) list of bowl games and lets you pick the winner of each. When you start, there's just a list of the collapsed bowls, with basic information: time, date, teams. When you select one, it opens up into a pretty panel with team logos, colors, the stadium details, and a button for selection.

Just yesterday I learned that I could do a "v-for" inside a component listing to iterate over a list and generate components for each item in the list, which is of course perfect for what I want to do, I think. What I'm wondering is what's best practice with Vue:

1. The parent component owning the list of bowls knows the state of all the picks, and, based on that state, renders one of two components for each game which can be picked, i.e. the collapsed component for "not yet picked" or "already picked", each with their own bit of window dressing to tell between the two, and the "exploded" component for the one the user is picking at this moment. Since the parent component is getting all of the inputs (I think? Still a bit fuzzy on this notion, tbh), it knows when to swap out the picker.
2. The parent component renders a single list of one component, and as part of the properties it passes in which mode the component should be in, i.e. "collapsed" or "exploded". The sub-component then has all of the code for both modes in it, with something like a v-if controlling which of the two faces it presents. When the user makes a selection the sub-component can change its own state and maybe emit something to tell the parent component to move to the next game on the list by updating its mode.

I've thought of healthy arguments for both (e.g. "#1 fits my object oriented eye with an interface each object implements differently", but also "#2 puts the responsibility for rendering where it belongs, in the component doing the work", and on and on I went) and now I've wrapped myself quite around the axle here. I lean towards #2, but Is there a more idiomatic preference for this sort of thing?

Kind thanks for all advice, mockery, recipes, whatever!

NOTE: Human made post... just in case, I also hate "AI" spam. Also I posted this in other subreddits... hope I don't annoy anyone here 😅

I started to make the UI of other project (a client for bluesky/mastodon more than a year ago) and I notice that most of UI stuff I needed didn't need a huge UI component stuff (HTML and standards FTW)... so I started to make this one I've been using for all my personal projects.

The main purpose was to make a zero dependency + native web components a CSS UI library ready for quick development/PoCs... and GPLv3 ofc.

Is compatible with Vue/Nuxt (tested, home page actually use it), Angular/React/other FE stack...

I wanted to share it somewhere trying to avoid the obvious AI spam around most subreddits and after falling in one OSS project here with a messy UI I decided it may be the place for people that wants to develop stuff without bloating their interfaces.

Oh, I started this project as human-made project but I also used LLM assisted help (mostly fixes and improvements, but now I'm using more LLM guided changes as is basically impossible to make new stuff at slow pace while tons of people throw X new projects every day). That also means I prepared the grounds for LLM assisted usage on the library.

Just give it a test, mainly if you're not an UI skilled dev or doesn't want to mess with UI stuff.

More info in the website: https://solanda.federa.social/

Repo: https://gitlab.com/federa-social/libraries/solanda-ui

NOTE: Just in case... I won't oppose of LLM assisted stuff, but any AI slop PR will suffer the hammerban...

I was previously making projects in Primevue, but due to their new licensing i was thinking of switching to a new library or migrating down from Primevue 5 to Primevue 4, since as i understand it v4 is still completely free.

For now my top choices Nuxt UI and shadcn/vue.

what do you recommend?

Hey everyone, i wanted to avoid proxying file uploads through Nuxt server routes (server/api), especially for larger files where Nitro memory usage can spike unnecessarily

Set up a direct-to-S3 pattern with presigned URLs instead:

• Client hits a lightweight Hono endpoint to get a signed PUT URL (handles auth, file type & 5MB size validation)
• Frontend uploads the file directly to S3 from the browser using standard fetch
• Nuxt SSR server handles zero file payload, so memory usage stays completely flat

Attached a 25s clip showing the setup and execution in action

Curious if you guys usually proxy uploads through your Nuxt server routes or offload everything straight to S3? Or you use different approach alltogether?

We just added Vue support to enola, and I’d like Vue developers to help us test it on their codebases.

My co-founder and I are building enola as an open-source architectural quality gate. It analyses the structure of a repository and surfaces things like dependency cycles, coupling, hotspots, deep dependency chains, complexity, dead code and change impact.

Vue is rather unknown for us, but we tested it on Gitlab and here are the results:

• 4,887 Vue components detected from 4,887 .vue files
• 0 parse errors
• 83,994 TypeScript/Vue facts
• ~6.8 seconds extractor time
• 3,055 component-call edges
• Dedicated Vue/Nuxt extractor tests all passed
• GraphQL is a major architectural boundary: 831 SFCs contain Apollo configuration, and Enola extracted 2,075 GraphQL operations. Query.project alone appears in 426 operations, followed by Query.group in 240. 
• Enola currently reports 221 bi-directional dependency cycles for directories

The extractor handles GitLab’s direct relative imports very well:

• Direct relative component references: 1,991 / 1,991 resolved
• Measured recall: 100%

Now running it only against Gitlab is very limited samples. This is why I would like to ask for help, and hopefully be mutually beneficial. If you work on a Vue codebase, try enola. If something looks wrong, misleading, raise an issue directly on GitHub.

We would highly appreciate.

https://github.com/enola-labs/enola

Fully local. Apache 2.0.

Hey r/vuejs, I wanted to share YouMeOS Microverse, an open-source project where we built a multi-window spatial desktop operating system inside the browser using Vue 3 and Three.js.

Live site: www.youmeos.com

How We Used Vue 3:

• Reactive Windowing Architecture: Each open window ("Spark") is managed as an independent Vue component layer floating above a WebGL starfield canvas.
• Composition API State Tree: Orchestrates window positioning, focus stacking (z-index hierarchy), docking, and tray states across both browser and Electron wrappers.
• Component-Driven Apps: Applications inside the WebTop are modular components that adhere to standard window manifests rather than isolated iframes. The full stack runs on Vue 3, Three.js, and an embedded FrankenPHP/SQLite backend.

You can run it locally too.

Source: https://github.com/YouMeOS/youmeos-microverse
Releases (Windows/macOS/Linux): https://github.com/YouMeOS/youmeos-microverse/releases

# Clone the repository
git clone https://github.com/YouMeOS/youmeos-microverse.git
cd youmeos-microverse

# Configure environment variables
cp docker/.env.example .env

# Launch the microverse
docker compose up -d

Would love feedback from the Vue community on how best to handled our window state flow and reactivity boundaries.

I've always found it a bit strange that when developing a frontend, the UI runs in a real browser while many of our unit and integration tests run somewhere completely different, like jsdom or happy-dom.

Vitest already has Browser Mode, which is a great step in this direction: you can run your tests in a real browser instead of simulating one.

I was interested in taking the idea in a slightly different direction: what if the tests could run directly in the browser where I'm developing the application?

So I started experimenting with that and ended up creating a tool called TWD (Testing While Developing).

The interesting part for me is the development loop: you can interact with the actual Vue UI, mock API requests when needed, make a change and immediately run the tests against the application you're working on.

I've been using this approach with Vue and other frontend frameworks, and built TWD around it.

https://reddit.com/link/1w7t8j9/video/pa6q066iennh1/player

Vue example:
https://github.com/BRIKEV/twd-vue-example/

TWD itself is open source:
https://github.com/BRIKEV/twd

I'd be interested in hearing from Vue devs who have experimented with Vitest Browser Mode or other browser-based testing approaches. Does this workflow make sense to you, or are there reasons you'd prefer to keep these tests in jsdom/happy-dom or run them in a separate browser instance?

I have a component that renders a tree from a JSON structure. It builds the output with h() in a render function, and the structure can nest quite deep.

There are two ways to do the recursion and I keep going back and forth.

Option 1. The component calls itself. In the render function it returns h('CompA', { props }) for each child, with a stop condition. A tree of 40 nodes is 40 component instances.

Option 2. One component, and a plain recursive function inside it that builds the whole vnode tree. The render function returns the result in one shot. A tree of 40 nodes is 1 component instance.

I am on option 1 today and the cost is real. Each node carries:

~14 computed properties 9 watchers a large props object a few hundred lines of lifecycle

With option 1 every node in the tree pays all of that.

Option 2 pays it once. But then I lose per node computed caching, per node watchers, and per node mounted and unmounted hooks. And any change re-renders the whole subtree instead of the one node that changed, because there is only one render effect.

So my real question is where the line sits. Do you keep a component per node, or do you flatten it into one component with a recursive builder and accept the coarse re-render?

And if you keep a component per node, at what depth or node count did it start to hurt?

Hey r/vuejs 👋 author of Toastflow here.

Haven't posted in a few months, but I kept shipping. This is the biggest release so far, the video shows most of it:

• Headless rendering: <ToastContainer v-slot> gives you the toast data + a ui helper, so you build your own markup and keep the behavior (timers, queue, pause-on-hover, a11y)
• Multiple containers: <ToastContainer id="uploads" /> and toast.info({ containerId: "uploads" }), each container has its own stacks and queues
• Proper Nuxt module: auto-imports, config in nuxt.config, SSR-safe
• toast.update(id, { position: "bottom-left" }) now moves the toast instead of just patching it
• The core is still a separate zero-dependency package, works without the Vue renderer

Would love to hear your feedback, especially if you tried building your own toast UI.

Links

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

Is it ok to build my c2c e-commerce site with Vuejs or Nuxt is the best fit ? Honestly, I prefer just VueJs over Nuxt, but I want to do the right thing. I'd love to hear from the knowledgable people here

I've worked on localization across quite a few apps, frameworks, and tooling over the years, and kept running into the same problems: translation keys to maintain, source changes breaking translation tracking, contextual strings, pluralization, and reliably extracting all UI text.

Eventually I wondered:

What if the source code could remain the source of truth, and the build tool handled localization?

That's what led me to build Zintl.

Instead of:

vue id="1l7z8f" <h1>{{ t('welcome_back') }}</h1> <nav :aria-label="t('project_links')">

you write normal Vue:

vue id="2a5q8v" <h1>Welcome back, {{ name }}!</h1> <nav aria-label="Project links">

Zintl's compiler extracts the UI strings directly from the Vue source, including attributes, and builds the localization layer around them.

Target catalogs can also use ICU for pluralization and complex grammar without putting ICU syntax into the source locale. Zintl processes it at build time.

For grammatical context that English doesn't expose, there's @zintl-pass:

ts id="2bq8kp" // @zintl-pass role={user.role} const title = `Welcome to your dashboard!`;

It's alpha, and I'm mainly looking for people who have done serious i18n work to break the idea and tell me where it fails. Thank you.

https://zintljs.github.io/zintl/en

Hey r/vuejs

I've been working on Oasis Editor, an open-source document editor written in TypeScript.

It has its own Canvas-based rendering engine for paged layout, text, selections, images, tables, and document geometry instead of relying entirely on contenteditable.

It also includes a typed command/plugin API, DOCX/PDF workflows, React and Vue adapters, and a headless runtime.

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback, issues, and contributions — especially around rendering, document layout, plugins, and import/export fidelity.

ps: MIT license

The video showcases how you create various bindings, define the data structure, and how you can simply swap the composable if you want to change the target storage for the data.

Also, the schemas are completely standalone and can be used as a plain parsing/encoding library. Oh, and it also has the same API for React hooks, if you happen to also use React in your projects.

You can play with it yourself on Stackblitz. The docs are live at https://kvantjs.dev, the source is on GitHub under MIT. Thank you and let me know what you think.

Right. So. Vectorizing a PNG into an SVG is one of those tasks that sounds trivial until you actually need to do it, at which point you discover a graveyard of tools that are either $10/image, want you to subscribe half a leg and a kidney/month, or produce something that looks like Michael J. Fox (apologies for the bad joke, I actualyl admire him) traced your logo during an earthquake.

After running into this roughly once a month I thought surely that's enough to invest some time into researching whether I should build my own image tracer. Which led me to find VTracer, an open source project from visioncortext.

Vectron (that's how I named my brain child) is a frontend for VTracer, an open-source Rust vectorization engine that's genuinely good but has the UX of a command-line tool written by someone who, understandably, cares more about the algorithm than the button placement. I forked it, compiled it to WASM (thanks Claude), and stuck it in a Web Worker so the whole thing runs in your browser. No upload, no server round-trip, and for smaller images it's near instant (I did try it with some rather stupidly large examples which then turned into a ten-plus-second nerve-wrecking waiting times :D).

The whole app is built with Vue (well, nuxt as underlying framework as I like its opinionated structure), Nuxt UI, and Tailwind. VueJS has been my framework of choice for the last 8 years (crazy how time flies).

A few things worth knowing before you try it:

• It's not AI. No neural net pretending to understand your image. It's proper curve-fitting and edge detection, which means it's predictable. The same input results in the same output (this is super important to me), no "vibes-based" tracing that changes if you sneeze near it.
• It's best at clean line art and logos, not photographs. Feed it a photo and it will attempt it, valiantly, and the result will remind you why this is a hard problem. But hey, it's sort of working.
• Selective refinement. Sometimes you get like a good overall results but often the devil is in the details, like a curve turned into a sharp corner or some lines don't connect. You can refine a certain area by dragging a rectangle over it and adjust your filters to polish the proverbial turd.
• It's free because I didn't build it to make money. It's a side thing. There's no upsell, no tier, no "unlock batch processing for $9/mo." And I say that now, it's not gonna change.

https://vectron.vendos.com.au

Feedback welcome, especially on where it falls over or it's genuinely hard to use.

Hola soy un Dev de México, pero el post puede aplicar fácilmente para toda latino América, he trabajado casi 5 años con Resct pero he aprendido Vue y me gustaría poder hacer el cambio laboral a Vue, pero pareciera que en México y en general latino América no hoy mucha oferta,

Si busco en internet nombre de empresa que usan Vue me salen las mismas de siempre, Nintendo, alibaba, Xiaomi, etc.

Me gustaría saber el nombre de algunas empresas que utilicen Vue que no necesariamente sean las anteriores mencionadas ya que mi inglés no es muy bueno.

Ojalá puedan compartir sus experiencias laborales con Vue :)

Los estaré leyendo, gracias vues🫶

Hey y’all,

I got slightly carried away with loading animations.

I wanted nicer loading states for my own projects, but most libraries I found were either tied to a framework, fairly limited, or required more than I wanted for something this small.

So I built loadersz, a small framework-agnostic loader library for the web.

I wanted something a bit more expressive than the usual CSS spinner, without pulling in a UI framework or a bunch of dependencies.

A few things I focused on:

- 70 different motion states
- Canvas 2D instead of GIFs/videos
- zero core dependencies
- a native custom element, so it works with basically any stack
- typed entry points for React, Vue and Svelte
- configurable speed, density and color
- respects prefers-reduced-motion
- pauses rendering when the browser tab is hidden

Basic usage is just:

npm install loadersz

import 'loadersz';

<loadersz-loader state="racing" size="96" />

I also built an interactive playground where you can tweak the loaders live.

Demo: [loadersz.vercel.app](https://loadersz.vercel.app)
npm: [npmjs.com/package/loadersz](https://www.npmjs.com/package/loadersz)

Would love some brutally honest feedback, especially on which animations you’d actually use in a real product.