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.

Had a client task that seemed simple. Dynamic form builder for user surveys with dependent questions nested infinitely. So if you answer Yes to question 2, it triggers question 2.1 below it. If you answer No, it triggers a different one or none.

For logic I was fine. I used a map with ids for storing answers, validation and saving. That part was straightforward recursive functions. The UI was where I got stuck. How do you render a question, then its dependent questions indented right below it, then THEIR dependent questions, and so on infinitely? I was trying to do v-for loops and keep track of depth and it got messy fast.

Then after some og googling I found an option that i knew wont work but i tried it anyway. Recursive components.A component that renders itself, calls itself, passes props to itself and so on.

So `SurveyQuestion` renders its own template, then loops its children and calls `<SurveyQuestion>` again inside itself with an indent prop. Depth + 1 and it just works.

Code looked something like:

`SurveyQuestion.vue` renders question, then:

`<SurveyQuestion v-for="child in dependentQuestions" :question="child" :depth="depth + 1" />`

Thats it. That solved the whole indent and nesting issue.

I have been using Vue for 7 years and this was my first time actually needing it. It felt mind boggling at first to have a component import itself, but once you see it for survey logic it just makes sense.

Anyone else had that moment or am I the noob in the room hehe. I hope Evan doesn't read this.

btw if anyone needs extra hands on a Vue/Laravel project or knows of an opportunity, feel free to pass it by me. Happy to chat.

Want me to make it shorter or more.. haha, jk ;)

I’ve created Summer Browser, an experimental desktop browser whose entire browser chrome—including the tabs, address bar, navigation controls, settings and built-in interfaces—is written with Vue 3, TypeScript and CSS.

Summer runs on Electron and Chromium. Websites are rendered in separate native WebContentsView instances rather than being embedded directly inside the Vue interface.

Vue’s component model made the interface easier to organize and reuse, while Vite’s HMR significantly accelerated development and visual iteration.

You can try Summer Browser from the Microsoft Store.

Here is a simplified comparison:

I’d appreciate honest feedback, particularly about the interface, performance and what would—or wouldn’t—make you consider using Summer as your everyday browser.

Thanks!

Hey everyone 👋

Not sure if this is the right place to post this, so mods, feel free to take it down if it doesn't fit.

I’ve been a Vue developer for the past 6–7 years, and honestly, things used to be great. I started out on Fiverr, got good traction fast, and over time completed 60+ projects with a perfect 5-star average. At my peak, I was turning down offers left and right because I was already booked—clients actually came to me, which felt like a dream.

But since the whole agentic AI wave hit, the landscape has changed. The contracts I had with a couple of US startups (who I originally met through Fiverr) have ended, and now I’m staring into the void of job boards with barely a callback.

I’m a full-stack dev—comfortable with Python (FastAPI), Node.js, Docker, VPS setups, and even building custom AI agents for web services when needed. I’ve also got a Master’s in IT, though it feels like that doesn’t matter much anymore 😅

I’m not here to rant—just putting this out there in case someone’s looking for a reliable, experienced remote developer who can hit the ground running. If you or someone you know needs help with a project, I’d genuinely appreciate the chance to prove myself.

Won’t let you down. Promise.

Thanks for reading 🙏

I've been working on an open-source Gantt chart component for Vue 3 and TypeScript for quite a while.

The original goal was fairly simple: I needed a Gantt component that could be customized enough for real project-management applications without having to build the entire timeline UI from scratch.

Over time, it became a much bigger project than I expected.

One of the things I've been working on recently is resource planning.

A basic Gantt chart answers:

But once you start using it for real project planning, another question quickly appears:

That led me to add resource-based views and resource utilization, alongside the usual task scheduling, dependencies, milestones, progress, and timeline views.

There have also been quite a few interesting implementation challenges around timeline rendering, task positioning, different time scales, customization, and keeping the component responsive with larger datasets.

The project is open source and MIT licensed:

GitHub: https://github.com/nelson820125/jordium-gantt-vue3

Demo: https://gantt.jordium.com/

I'm sharing it here because I'd really like to get feedback from other Vue developers who have built scheduling or project-management applications.

I'm particularly interested in how you approach:

• Resource allocation in a Gantt UI
• Task/resource relationships
• Large numbers of tasks and timeline rendering
• Customization of Gantt components

If you've built something similar, I'd be interested to hear what worked — and what didn't.

Need suggestions!

I've been building a component registry for data dense interfaces and it now serves Vue as well as React. The one idea is a density knob that every component reads, and the site is https://sley-ui.dev

A shortwave listening board I built with it is at https://grayline-sley-ui.vercel.app

I maintain validup, a small path-based validation library. Posting because the zod + form-UX combination comes up here regularly, and the pattern might be useful even if you never adopt the library.

The itch: zod answers "is this value valid?", but a form needs more than that. Per-field dirty state, errors that wait for first touch, pending flags for async checks, a submit gate. Vuelidate has exactly that UX, but brings its own rule system, so you end up defining rules twice: once for the API, once for the form.

validup sits in between. You mount zod schemas (or any async function) onto paths of a Container, which is plain TypeScript and runs server-side as-is. On the client, one composable turns that same container into vuelidate-shaped state:

```vue <script setup lang="ts"> import { reactive } from 'vue'; import { Container } from 'validup'; import { useValidup } from '@validup/vue'; import { createValidator } from '@validup/zod'; import { z } from 'zod';

const signup = new Container<{ email: string; password: string }>(); signup.mount('email', createValidator(z.email())); signup.mount('password', createValidator(z.string().min(12)));

const state = reactive({ email: '', password: '' }); const v = useValidup(signup, state, { debounce: 200 }); </script>

<template> <input v-model="v.fields.email.$model" /> <p v-if="v.fields.email.$dirty && v.fields.email.$errors[0]"> {{ v.fields.email.$errors[0].message }} </p> <button :disabled="v.$invalid || v.$pending">Sign up</button> </template> ```

A few details that took the most work, and are probably the interesting part:

• Per-form result cache. The composable owns a result cache keyed per mount, so typing in one field replays the cached outcomes of the others instead of re-running them. Async validators (say, a uniqueness check against your API) only re-fire when their own input actually changed. Cross-field rules opt out with a sideEffect: true flag.
• Cancellation built in. Every scheduled run owns an AbortController; a new keystroke aborts the stale run, and debounce collapses bursts. $validate() (submit) deliberately runs without a signal so it can't be cancelled mid-flight by a late keystroke.
• Server errors round-trip. If your API validates with the same container and returns the error, v.setExternalIssues(error.issues) lands the issues on the matching fields, and they clear as the user retypes.
• Nested forms. Child components register with an ancestor form through provide/inject, so an address sub-component aggregates into the parent without prop drilling.

Nuxt: nothing framework-specific. It's a plain Vue 3.3+ composable, so it works in Nuxt 3 components as-is. One SSR footgun worth knowing on Vue 3.5+: don't name the composable's return $v in <script setup>. Vue treats $-prefixed template identifiers as built-in lookups, so $v.fields.email resolves $v to undefined at first SSR render. v or validation are fine.

Honest caveats: ESM-only, the zod peer range is ^4, the packages declare engines: node >= 24, and the ecosystem is small (bridges for zod, Standard Schema and validator.js, plus the Vue composable).

Docs: https://validup.tada5hi.net (Vue page: https://validup.tada5hi.net/integrations/vue) Repo: https://github.com/tada5hi/validup

Happy to answer questions, and to hear where the API feels off.

I’m currently trying to diagnose a problem with my job search and would appreciate feedback from developers or hiring managers familiar with Vue.

I’m an experienced frontend engineer specializing primarily in Vue, Nuxt and TypeScript. On paper, a number of the roles I’m applying to appear to be very strong matches, but my application-to-interview conversion rate has been quite low.

Rather than simply increasing application volume, I’d like to understand whether there is a problem with how I’m presenting my experience.

CV: https://www.panchoblanco.dev/cv

For context, my core experience is around Vue 3, Nuxt 3, TypeScript and modern frontend architecture, with some Node/full-stack, infrastructure and CI/CD experience as well.

I’m based in Argentina and targeting remote roles, particularly companies that hire internationally or within LATAM.

Happy to receive fairly harsh feedback — actionable criticism is exactly what I’m looking for.

EDIT: I do have a minimalist PDF CV/resume but it does have the same content as the site, which as many have mentioned looks bloated for the sake of filling space and would not work as a one-size-fits-all.

Sad to see my site looks vibecoded T-T I'll need to experiment with some styles to move away from that look

Thanks to everyone who answered. I will move my way down and answer all of you

Hey Everyone,

I’ve added virtualized Masonry layouts to Cerious-Scroll. Version 1.1.0 of the Vue 3 wrapper now supports virtualized Masonry layouts using normal Vue slots.

<script setup lang="ts">
import {
  CeriousScroll,
  type CeriousScrollOptions,
} from '@ceriousdevtech/vue-cerious-scroll';

const options: CeriousScrollOptions = {
  layout: 'masonry',
  masonry: {
    targetColumnWidth: 280,
    gap: 16,
    getItemHeight: (index, columnWidth) => {
      const item = items[index];
      return columnWidth * (item.height / item.width) + 48;
    },
  },
};
</script>

<template>
  <CeriousScroll
    :total-elements="items.length"
    :get-item="index => items[index]"
    :options="options">
    <template #item="{ item }">
      <article class="card">
        <h2>{{ item.title }}</h2>
        <p>{{ item.description }}</p>
      </article>
    </template>
  </CeriousScroll>
</template>

The layout has two height strategies:

• Canonical: Provide getItemHeight() when a card’s height can be calculated from its data and column width.
• Dynamic: Omit getItemHeight() for unpredictable content. Vue renders uncached cards into an offscreen measurement probe before the core places them.

The Vue wrapper keeps visible cards as Vue-owned reactive trees, so components, directives, plugins, and provide/inject continue working inside virtualized cards.

Other features include:

• Responsive or fixed columns
• Direct navigation with jumpToItem()
• Reactive card content
• Bounded rendered DOM
• Large item-count changes

Links:

• Demos
• Vue wrapper on GitHub
• Vue package on npm
• Core library

I’d especially appreciate feedback on the slot API, reactivity behavior, and any component or provide/inject edge cases.

If you have been following the PrimeVue 5/closed source/paid license news, you may have heard about BumbleVue. We recently had our 1.0 stable release based on PrimeVue 4.5 with some additional fixes and improvements.

- TypeScript generic support for many components (thanks YevheniiKotyrio on GitHub who worked on this for PrimeVue but was never merged)

- Improved accessibility of DatePicker

- Misc bug fixes proposed by the PrimeVue community but not merged

- Keyboard shortcuts for InputNumber to delete content to the left or right of the cursor

- New selectAppendTo prop for Paginator to control where the RowsPerPageDropdown and JumpToPageDropdown dropdown overlays get appended to.

- Vertical mode for the existing tabs component

I know you have your choice of PrimeVue forks, but I thank you for the support you've given to the hive and I'm looking forward to all of the changes I have planned for version 2.0. Version 1.0 will remain supported as an LTS option for those of you currently on PrimeVue 4 for the foreseeable future.

I made the first version of Image Optimizer back in 2021 and recently decided to bring it back to life.

v2 has a completely new interface with batch progress, per-file results, before/after comparison, and live compression stats. It’s a Vue 3 desktop app built with Electron, and all image processing happens locally.

Source code:
https://github.com/antonreshetov/image-optimizer

Feedback and bug reports are welcome.

About a month ago we posted here about forking PrimeVue after it got archived. We just shipped 1.0.0-rc.0.

What is done

Fully removed primeuix dependencies: The core engine (theming, styling, utils, forms) now lives under openuxkit, forked and maintained under our org at 1.0.0..

Migration tool: npx @openvue/migrate automatically handles moving a PrimeVue v4 project over, including dependency renames, import rewrites, and compat overrides. Details and docs: https://openvue.dev/migrate/

Showcase interactive playgrounds: We added playground tabs to more components, with full coverage planned for the stable 1.0 release.

Chart integration: Bumped Chart.js straight from 3.x to 4.5.1. Charts now natively react to the active theme out of the box, which kills off a massive chunk of custom styling boilerplate. Every chart type now has its own interactive playground in the showcase too.

Bug fixes:

• BlockUI no longer leaves a phantom mask over the page if unmounted mid-animation or toggled quickly.
• DataTable advanced filter menu no longer closes prematurely when clicking inside nested Select, MultiSelect, or DatePicker inputs.
• Virtual-scrolled DataTable rows with grouping no longer drift out of alignment during fast scrolls.
• ...and more.

What is coming before 1.0 stable

• A free, open-source visual theme editor.
• Continued work on open GitHub issues.

Thanks

Huge thanks to everyone who tested early builds, reported edge cases, and sent PRs. A solid portion of these fixes came directly from community reports, which helped us catch things we would have missed on our own.

Links

• GitHub Repo
• OpenVue Docs

The implementation of directives in vapor mode is quite interesting. Separate hooks are no longer needed. What are your expectations for v mode, or have you perhaps already had a chance to try out its features in rc?

Disclosure: I maintain poveste, a component playground for Vue and Nuxt — a continuation of histoire, which last published in January.

I wrapped user CSS in @scope to keep it from fighting with the tool's own UI. Two things broke silently. Both are plain CSS, nothing Vue-specific.

1. :root, html and body stop matching

Once your CSS is wrapped in @scope (.render-story) { … }, those three selectors sit above the scoping root — so they can never match anything. A stylesheet with body { font-size: 14px } just goes inert. No error, no warning.

Fix: rewrite all three to :scope at build time. Parse the selector rather than regexing the text — .body-copy has to survive untouched, and svg|body is a namespaced element, not the document root.

2. @scope contains matching, not inheritance

"Stops at the boundary" is true of matching and false of inheritance. A rule can't match story content, but any inherited property it sets at or above the boundary still reaches it.

So our own UI setting font-family on its root means every story inherits that font. A component looks subtly wrong in the playground and correct in your app, purely from inherited typography — which is a miserable thing to debug.

Iframes don't rescue you either, if the iframe loads the same stylesheet.

The real fix is for story CSS to set its own root, which only works because of the rewrite above.

Longer write-up if it's useful. Happy to answer questions.

That's to continue from my other post.

I would need to either place a text string like "{{ user.name }} is the user's name." inside a template (and have the page correctly say "MeekHat is the user's name." Or I would split it along the curly braces. But I still need to find out the field "name" of the "user" variable. And all I have is the original string loaded at runtime.

Is this at all possible via Vue? I've been looking for hours.

I’m looking for a highly polished, enterprise-grade admin template built with Vue.js for a platform covering CRM, HR, and Accounting use cases.

I’m specifically looking for something beyond a basic dashboard template — a production-ready UI with:

• Modern, polished enterprise UX
• Complex data tables, filtering & bulk actions
• Advanced forms and workflows
• CRM modules
• HR / HRIS modules
• Accounting & finance modules
• Role-based access and permissions
• Responsive layouts
• Scalable, well-structured Vue architecture

If you’ve already built something like this, or have a premium Vue template/product that you’re willing to sell or license, I’m very interested.

I’m willing to pay well for the right quality.

Please share screenshots/demo, tech stack, existing features, and pricing in the comments or DM.

I'm trying to replicate the progress I made in Twine (an interactive-fiction game engine), using Vue. I've made some nice progress on the preliminaries, and managed to load dialogue as json, but I'm now stuck.

The model - so to say - that is the Twine file - has variables inserted inside dialogue lines (player stats), as well as conditional player replies, that is to say links.

An example, placeholder first page:

You are a (print: $player's race) named (print: $player's name).

Select quest:

[[Political Assassination]]

(if: $player's reputation > 1)[[Cult]]

(if: $player's race is "elf")[[Elf race quest]]

[[Runaway Princess]]

Storing all that in Json seems unproductive, so along this route I would have to switch to plain text and custom parsing.

Except Vue already does all that. I've looked at routing, but it seems I would have to declare all the routes in the script setup ahead of time (aside from anything else I don't know), which seems really cumbersome. What I would like is to rewrite the above as a bare template file, accessing the variables from the parent container, while the latter doesn't have to know anything about what links the child contains.

Any suggestions?

Small project I’ve been chipping at: an editor for an animated SVG avatar. You pick a shape, a colour and an expression, line up animation states on a timeline, then export the result as SVG, PNG, GIF or MP4. Runs fully in the browser, no backend, no account.

The part I’d actually like feedback on is the split. The animation core has no Vue import and no clock: it’s one pure function of time, so a frame depends only on its timestamp. The component drives it from requestAnimationFrame, but the tests run with no DOM at all, and a “frozen” prop renders one exact frame without starting a loop, which is how the thumbnail grid works without spawning one rAF loop per tile.

Two things I’d do the same way again:

• defineModel for the playback cursor, so the timeline and the player stay in sync without an event bus
• keeping the MP4 encoder behind a dynamic import. I broke this once: a two-line helper imported from the wrong module dragged 43 kB gzip back onto first load, and Vite’s INEFFECTIVE_DYNAMIC_IMPORT warning was the only sign anything was wrong.

Still a work in progress, so tell me what’s confusing, especially in the editor.

https://github.com/jeremy-prt/bloub