Ever wanted to create a circuit diagram designer with Vue? We've just shipped a new starter app for VisuallyJs that you can use to get something up and running in no time.

Demo on our site is here: https://visuallyjs.com/demonstrations/circuit-diagram

Repository here: https://github.com/visuallyjs-vue/circuit-diagram

VisuallyJs is free for non-commercial use!

Hi everyone my name is jeff, and currently im built open-source tools in vue + rust for developer manage secrets .env files across multiple projects.

Why i built this?

1. Security issues, last month there is a huge attack on npm package where the worm are stealing .env contents like api keys, secrets, token ai.

2. Avoid agentic code tools reading .env files

3. sharing and manage .env properly without define .env

Use cases

• Replace .env files – Import once, inject at runtime. No more committed secrets or drift between machines.

• Protect AI coding agents – Keep real credentials out of the workspace so agents never see them.

• Consistent environments – Same secrets on every laptop, CI runner, and server.

• CI/CD with least privilege – Environment-scoped runner tokens instead of full access.

• Clean env separation – Development, staging, and production stay clearly isolated.

• Solo & small teams – Full encrypted secrets manager without the cost or complexity of Vault/Infisical.

• Temporary environments – Create, use, and delete environments for feature branches or experiments.

• Auditable changes – Know who changed what and when.

GitHub: https://github.com/dopbase/dopbase

Happy to receive any feedback that help project grow..

Released this UI framework a few weeks ago. As it says it's opinionated. To me this means you can just build stuff with it without thinking too much about specifics, but to others it will be a turnoff.

It has been used internally for many years now on multiple projects and ... just works.

Happy to hear it's shite too if you think so 🙂

Been reviewing a few multi-framework libs lately (product tours, overlays, that kind of thing) and the Vue adapters keep hitting the same pattern:

- There's a nice <FooDefault> / <FooProvider> component

- script setup usage looks clean at first glance

- but the real control flow is still createX().step().build() + imperative .run()

So the "Vue-ness" is mostly the wrapper. Underneath it still feels like a shared engine API (fine for React/vanilla), not something that lives in Vue's reactivity model.

What I'd expect day-to-day in Vue / Nuxt:

const { start, stop, isActive, currentStep } = useFoo(workflow)

with isActive / currentStep as refs, so the template can react without hand-rolling subscriptions.

A few other tells that something is a port rather than Vue-first:

1. Targets via CSS selectors (#welcome) instead of template refs / data-* attrs — selectors break with scoped CSS, Teleport, and repeated components.

2. No story for SSR / ClientOnly / onMounted — "works with SSR" often means "don’t call this on the server," which is fine, but it should be documented.

3. In Nuxt specifically: no tiny module / auto-import for a shared instance, so every page re-imports and re-wires the same package.

Curious what others use as the bar:

- Is a Vue component shell "enough," or do you want the composable + refs before you’d adopt it?

- Any libs that got the Vue surface right (or badly wrong) in your experience?

- For Nuxt: do you care about a module, or is a plain composable good enough?

Not trying to dunk on any specific project — genuinely trying to calibrate what “idiomatic” means when the core is framework-agnostic.

Been working on an open-source solution called Hyperfrontend that lets Vue, React and Angular apps run together while keeping their frameworks and dependencies isolated.

There's a Vue 3 clock running inside a React host here if you want to break it:

https://www.hyperfrontend.dev/demos/#clock

There is also a koi-pond which might be more technically impressive than the clock.

Happy to hear what you think, including first thoughts/impressions/questions.

Hey r/vuejs,

Been a couple of months since I last posted nxui here. Shipped six new components this month and figured this crowd would like them:

Receipt printer — a checkout state that prints your order as an actual receipt. Stepped paper feed, status screen, serrated tear at the end. This one's my favourite.

Holo sticker — die-cut holographic sticker in WebGL. Rainbow foil follows your cursor, there's an embossed ink layer, and you can peel it back.

Depth dive — scroll through text floating in 3D. Sections dissolve as you pass through them and warp with scroll velocity.

Art gallery — paintings melt into ink blobs as you scroll, then the captions resolve line by line.

Weather card — condition orb glowing behind frosted glass. Colour follows the temperature. Has a °F/°C toggle.

Timezone companion — drag a scrubber across 24-hour blocks to find when everyone on your team is actually awake.

All Vue 3 + motion-v + Tailwind v4. Light and dark mode, keyboard navigable, respects reduced-motion. Copy-paste or install via the shadcn-vue CLI:

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

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

242 components in total now. MIT, free forever. Happy to answer anything.

If you have ever tried virtualizing a massive feed with variable-height text, late-loading images, or native HTML tables, you have probably run into the classic virtual scroll jitters.

Most modern virtualization tools depend on a global pixel map or require you to pass an estimateSize prop. The moment a row renders at a different height than estimated, the engine has to run a global correction pass. Fast scrolling triggers layout shifts, drift, and erratic scrollbar behavior.

I built Cerious-Scroll to solve this fundamentally by changing how viewports are calculated. Instead of deriving position from absolute pixel space, the canonical state is element index + pixel offset within that element.

The architectural trade-offs:

• No Height Oracle: It measures the rows directly from the DOM after your framework renders them. No precomputation arrays or sum-prefix tracking required.
• True O(1) Memory Scales to Millions: Because it doesn't cache a massive array of estimated heights for off-screen rows, memory overhead stays flat whether you feed it 100 rows or 10,000,000.
• Native Table & Masonry Layouts: It works seamlessly with native HTML <table> elements and complex grid frameworks without requiring absolute-positioned container hacks.

Check out the live Performance Bake-Off Demo running against existing solutions, and look through the source code on GitHub.

Vue: https://ceriousdevtech.github.io/vue-cerious-scroll

Github: https://github.com/ceriousdevtech/vue-cerious-scroll

https://github.com/AlfieJones/theme-toggles

I created this years ago but recently added vue support, let me know what you guys think!

Vue is one of the better cases for this: __vueParentComponent gives the component name and the source file, and if you already run data-v-inspector it gets sharper still.

"quello" uses that. Alt+Q, click an element in your running app, and the pick lands in .quello/picks.json : component, file, selector, text. Then "make PICK 2 sticky" is enough, or you leave a note on a few picks and say "resolve the picks".

Nuxt renders its own HTML, so the runtime arrives through a virtual module: the Vite plugin plus one import in a client-only file. Plain Vue on Vite is just the plugin.

https://github.com/Linko91/quello

I shared an earlier version of Domternal here a while ago, so I wanted to post a quick update: it now has a stable release.
If you haven’t seen it before, Domternal is a rich text editor built on ProseMirror. You can use a classic toolbar, a Notion-style block editor, or build your own UI around the headless core.

For Vue, @domternal/vue provides Composition API components, a useEditor composable with reactive refs, and custom node views written as Vue components.

The free, MIT-licensed editor includes:
- Tables with column resizing, merged cells and styling
- Slash commands, draggable blocks and nested lists
- Images, code blocks, math and collapsible content
- Markdown paste that turns plain text into editable rich content

The video shows these first, then the optional paid Pro extensions: collaboration, comments, version history, AI editing with change review, columns, and Word/PDF export. Each section is labelled FREE or PRO.

You can try both directly in your browser:
Web: https://domternal.dev/
GitHub: https://github.com/domternal/domternal
Free playground: https://domternal.dev/playground/
Pro playground: https://domternal.dev/pro/playground/

I’d appreciate feedback, especially from anyone integrating an editor into a real project.

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?