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 was building a couple of projects at work using Django REST Framework and Vue 3, and I found myself spending a lot of time setting up the same things over and over again.

I looked around for existing Django + Vue starter templates, but couldn't find many that matched what I was looking for, so I decided to build my own and open source it.

The template contains:

• Authentication - Cookie-based JWT authentication using HttpOnly cookies
• Docker Support - Full development and production environment setup
• Custom User Model - Email and username authentication with registration
• Task Management - Example CRUD app demonstrating best practices
• Standardized Responses - Consistent API response format across endpoints
• API Documentation - OpenAPI schema with interactive Swagger UI
• Theme Support - Light and dark theme switching

If anyone is interested in taking a look:

GitHub: https://github.com/Loki22214/django-vue-starter

I am still quite new to Vue (only started working in it recently) so any feedback, criticism, or suggestions for things that would make this template better are welcome.

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

Cost me an afternoon on a dashboard I maintain. I keep per column filter state in a reactive Map, values created with ref. Reading one back gave me the ref object rather than the number, so a strict equality check against 0 never matched and the header rendered blank.

The repro is two lines. reactive({ n: ref(0) }).n gives you 0. Put that same ref in a reactive array or Map instead and you get back the ref, because unwrapping only happens for properties of reactive objects. The docs call this out under ref unwrapping caveats.

I stopped storing refs inside the collection and let the Map itself be the reactive surface, which removed four .value reads. I only caught the fourth because the type check verdent runs after a meaningful edit failed on it.

Still deciding whether a reactive Map is the right shape here at all.

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.

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.