DEV Community: Alois Sečkár

New in Vue - March 2026

Alois Sečkár — Sat, 28 Mar 2026 11:49:43 +0000

I promissed new summary once VueJS Amsterdam is over. It took me two weeks longer, but there we are. Hear, hear! I bring the latest Vue news.

Unfortunately, I must start with a sad announcement - the Weekly Vue News, the invaluable source of inspiration for Vue devs are no more. Their long-time curator Michael Hoffmann called it quits. Let his hard work be remembered.

But life goes on. And the life in the Vue ecosystem is everything but steady. So lets recap the new releases:

The most significant one would be the Vite 8.0. Why? Because Vite is nowadays fundament for modern JS development. And v8 brings important updates like using brand new and super-fast Rolldown bundler. There was a beta testing phase running since December, and now the stable version was made available.

On top of that, there is Vite+ - a unified modern toolchain built with the latest available features as "This is the way" of developing webapps in 2026. The current state of the project is Alpha with stable release expected soon.

Vitest, the testing framework, couldn't stay behind and released v4.1. Unlike the significant v4 update, this is rather a service update to natively support Vite v8. But there are also some new features to give a try. If you don't use Vitest in your project, you should think about it.

Nuxt, the #1 framework to go with Vue projects, continues its steady evolution, with v4.4 being the latest release. With each minor version something new appears, although the changes are not really revolutionary. The same applies for Nuxt UI, the official UI library - the v4.5 and v4.6 were released since my last newsletter. For smaller projects, you really don't need anything else to handle the appearance and basic UX.

Nuxt already foresees its version 5. You can even opt in into future forward compatibility through a setting. One of the prerequisites is the finalization of Nitro v3 JS server engine. This milestone is now one step closer as its beta phase has started.

Among new tools, I want to point out first stable release of Pinia Colada, the advanced Vue solution for data fetching and state management. You probably have heard of Pinia, this brings the concept further created by the same author.

I must not forget about evlog, the new logging tool by Hugo Richard, one of the Nuxt team members. I haven't touched it yet, but I really want to do it soon. I really like the idea of having my logs better organized. Logging is generally hard - it doesn't matter until it's too late. Right?

If you are trying to keep up with the times and use AI to boost your developer performance (which you absolutely should), this might be useful for you - Daniel Kelly from VueSchool wrote an article about Vue Agent skills that should gradually improve the quality of GenAI tools output.

Last but not least, we have a new TypeScript version. Microsoft released its stable version 5 days ago. However, this version is considered rather a less important bridge on the way to v7, which is expected to be the real change after its core being rewritten to Go language for better performance. So you don't necessarily need to drop everything and start migrating your codebases to v6.

That's it for today. When I approach you the next time, I hope I would be able to share details about the PragVue 2026 conference we are about to organize for the third time already. Until then.

Edit: fixed title from March 2025 to 2026. Thanks Arvind PJ for spotting out.

Upcoming events

Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!

Speed of Vibes: We can turn bathroom ideas into features within minutes now

Alois Sečkár — Sat, 14 Feb 2026 21:15:44 +0000

A month ago, I wrote I am a rational pessimist about AI. Yesterday's dispute with my co-worker about unnecessary complexity of AI-infused Korn shell script delivered by our other colleague reminded me there are also radical pessimists among us. However, every day when I dare to go further into the uncertain wilderness of imperfect prompts followed by indeterministic and not-always-right responses, I see progress, new opportunities and new ways of doing better.

Today, I have another success story to share.

It started one evening after a workday recently. I came back from my daily dev job and went running to compensate for hours sitting in front of a screen. After the jogging session I was in a shower and suddenly got a cool idea for my side project.

I thought it would be nice to provide to my future users a convenient way of reporting bugs. But also to make it convenient for me. I would be happiest to have reports appearing as GitHub issues. But teaching BFUs to login to GitHub and creating new issues in a consistent way? Good luck with that. So what if I just provide a simple form on my website and wire it to a backend service that will collect the input and create the issue automatically?

Sounded like a plan. But imagine all the work you need to do. Putting together the form, writing the backend service, figuring out how the GitHub API works exactly to be able to call it... Let's just put the idea into the inner memory deep in the back of my brain and we will surely look at it. One day. Not today... My inner demon of procrastination nearly won again.

But times have changed lately. Now I am armed and dangerous with tireless AI companions. Despite all those legit complaints about coding agents not doing their job as good as you would hope and not nearly as great as AI-driven companies keep promising you, in early 2026 your favorite excuses "I don't know how to start" or "This task is too big to start it today" are no longer valid. You can always just kick off with a simple natural language prompt and see how it goes. Even the last season's truth that the prompt needs to be well designed (and thus you "cannot" start as "I don't know how to write a correct prompt") is fading out.

Before going further, I'd like to make a statement. This doesn't mean I am encouraging you to just fire ambiguous prompt and YOLO-deploy the first iteration right into the production. The AI Manifesto is still valid and you should always verify the results, reason about code and understand everything before moving on. It is easier for me as a senior dev, but if you are a beginner, the more important it is before you get lost and become a hostage of a machine mind. On the other hand, you shouldn't hold yourself back too much. AI is there for you. Use it. Benefit from it. 💪🦾

Before I finished bathing, ate dinner and socialized with my family, it was already getting quite late. But I was feeling lucky and wanted to try.

Here is the prompt for my (paid) Copilot I quickly put together:

I want a new feature in this Nuxt 4 project. I need a new client page 
"/report" with a Nuxt UI form entitled "Report problem" that will include 
text field for "gameLink", radio switching between "report false positive" 
and "report false negative", text field for "issue" and text area 
"description" for describing the issue to be reported. All fields will be 
mandatory. The filled form will be send to backend API route where it is 
validated and then a GitHub issue in <<REPO>> repository is created from 
given contents. Issue will be named by "issue" field and contain both 
"gameLink" and "description". Selected radio value will result into 
corresponding label (that will be prepared in the repositry). The report 
form is annonymous, there will be dedicated service account with access 
token to create the issues configurable via Nuxt runtime config (server-
side, so NOT public).

Just this. No context engineering, no MCP servers, no skills or whatever. Just my codebase, internet connection and the rough task description in natural language with a few instructions and restrictions. Typos and grammar mistakes included.

Maybe one thing. If you are AI-geek, you may have noticed new model Claude Opus 4.6 was released recently. I did notice and I also decided this was a perfect opportunity to test it in action. And I wasn't disappointed.

I spent two, maybe three minutes writing the prompt (while already have it more or less ready in my mind). Copilot with Claude took about 4 minutes to deliver the result. The surprising part was - the code was nearly perfect!

I was trying, but I was unable to find any significant flaws. It created decent frontend form, it added Zod schema validation, it created backend endpoint, handled and validated the incoming data, put together the GitHub API call and wired the response back into the client. It even noticed there was no <NuxtPage /> yet and made adjustments accordingly to support new /report page along the existing (implicit) /index. Yea, I might do some refactoring and polishing later, because looking back, the code might be more compact and less verbose. But overall it was not glued together somehow until it accidentally worked. It was a decent job. I don't think I would do much better for the first iteration.

My victory wasn't so flawless, because then I spent at least 30 more minutes configuring my new GitHub service account and getting the proper access token (AI-backed again). But overall it was less than an hour from the first keystroke to test issue successfully created in my repository. Wow! 👀

There were a few success points that helped:

I knew what and how I want to do and I know Nuxt good enough to request general architecture with at least basic level of security (i.e. token must be kept on server-side and not exposed as public config).
Copilot wasn't building from scratch but inside already established repository with configured Nuxt UI and existing server routes to copy from.
People from Nuxt ecosystem are working hard to create AI-friendly solutions so it is much easier for agents to get relevant up-to-date information.

I was hoping for good outcome, but this really amazed me. It reminded me that it already me who is being the bottleneck. My hesitation, my reluctance and my incompetence to delegate tasks that should be delegated without losing control. Despite I am still not scared about my very existence as some fellow devs seem to be, I was re-assured I should know much better. And I will keep trying to do so.

What about you? What are your recent experiences with AI? Feel free to share your stories, questions, objections and concerns in the comments below 👇

New in Vue - February 2025

Alois Sečkár — Sat, 07 Feb 2026 08:14:42 +0000

As you probably didn't even notice, I skipped January issue of my wannabe monthly newsletter. I was in a hurry towards some deadlines, and I wrote 3 other articles in 2026 already. So I decided not to post some half-baked something last Saturday and to postpone the release. Today I am travelling by train from Prague to Ostrava, which is always a good opportunity for creative work. Here it comes.

Nuxt began 2026 with a new minor release 4.3. Among numerous updates and improvements, it is now possible to opt-in into forthcoming v5 features via a setting. Nuxt v5 shouldn't be a revolutionary update with large API and behavior changes, but it will bring completely re-worked Nitro v3 server engine promising faster and more effective execution with a number of new cool features.

Edit: Patch version 4.3.1 landed just a few hours after I finished my overview.

Owners of larger projects also got a pleasant announcement about the official support for Nuxt v3 being extended by 6 months - from end of January to 31 July 2026. That gives everyone more time for migration efforts. Some are complaining that the support period should be even longer as production teams need more stability but remember Nuxt is an open source-project. Despite handful of the team members are now being paid by Vercel, the solution capacity is still limited. I would rather see new features being developed than legacy code being maintained indefinitely for (often non-paying) users.

There are two new official Nuxt modules around the corner. Nuxt Accessibility will focus on dealing with accessibility issues by providing ways of testing and giving hints during development. Nuxt Hints will go even beyond that and should provide insights about your applications' performance, accessibility, and security. Both modules are now in alpha stage towards their v1 release which is expected soon.

Formerly paid premium feature Nuxt Studio was made free and fully open-sourced. The transition process started after Vercel acquired NuxtLabs last summer and was finished at the dawn of 2026. Nuxt Studio used to be a way of making money for Nuxt development. As this is not necessary anymore, you have this advanced CMS solution at your disposal now.

Adam Berecz announced his Vueform 2.0. I learned about Vueform 11 months ago from his conference talk and I immideately liked it. Now it seems there will be a paradigm shift from more opinionated form-handling solution to a headless core that will allow smooth extension by almost any UI library. Looking forward to the result. Forms are a big (and somewhat painful) topic, and I am afraid I haven't picked my dream setup yet. Another player out there might be Formisch which is being developed from last summer by Fabian Hiller, the author of Valibot validation library. But since Nuxt UI also opensourced their previously paid components, maybe their Form is all a Nuxter would need? I am planning to experiment on this theory a bit...

Let's not forget about broader Vite ecosystem. As you may have heard, one of the fundamental parts of the ongoing improvement efforts is Rolldown. The bundler written in Rust is made to be crazy fast and effective in building modern webapps. Vite version 8, which is already in beta stage since December, will be powered by Rolldown exclusively. And soon there will be standalone Rolldown release, we already have release candidates. And there is much more going on as you can see in the fresh monthly summary by Alex Lichter.

Last thing that caught my attention lately is npmx - an alternative frontend to NPM package registry. It is an open-source project, currently under active development, that promises improved experience when browsing NPM packages. Not a competing repository and ecosystem, just an alternative frontend with additional features. I was satisfied with classic https://www.npmjs.com/, but this seems as one of those updates you don't know you need until you get it. I will keep my eye on it.

I plan to release the March issue after VueJS Amsterdam conference. This year I am not travelling there in person, but I will keep my eye on the updates and I am sure there will be a lot of news to talk about. Take care until then!

Upcoming events

VueJS Amsterdam 2026 - 12-13 March 2026, Amsterdam [NED]
Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!

I cheated to maintain GitHub streak and I don't regret it

Alois Sečkár — Sat, 24 Jan 2026 14:13:23 +0000

Since September 2022, I am actively trying to have a GitHub streak - every day at least one new contribution. And yes, I totally agree with you, it is meaningless. But it has a meaning for me. I want to do it, and I want to keep it. Even if some days the contribution has little to no value - like just adding a new article I have recently read into one of my news lists.

I used this widget to display the number of days on my GitHub profile. It was great until it stopped working some time ago. Some API changes probably. Maybe it'll come back eventually. But I didn't want to wait. I found an alternative that works here and now.

Except it doesn't work the same way as the previous one and as the GitHub commit graph itself. It only counts "real" commits, it doesn't recognize code reviews.

And this pointed out a flaw in my beloved streak. One day, June 1st, 2024, I somehow forgot to actually commit something. I "only" did two reviews for my Dependabot updates. I didn't notice, because when I opened GitHub page, the day was green. But my streak suddenly dropped by more than half 🥹

I could have just let it go and accept the bitterness. But I didn't want to. The other day I did four commits! What if I just virtually travel back in time and alter one of them to fill in the gap? 💡

And so I did. And the timeline was fixed. And I can enjoy my 1236 and counting streak. End of the story.

But this wasn't meant to be just a confession. And I don't ask for redemption. The title says I don't regret it. Here I wanted to explain why not.

Because due to this "cheating", I learned to know Git better than before.

Git is one of those things you can adopt in a few minutes and then spend a lifetime trying to really understand it. Btw it took just 10 days to forge this backbone on modern development. Stories like that keep reminding me how mediocre I actually am.

To be able to change a year and half worth of my project Git history, I needed to understand how to work with git rebase command. How to find the correct commit and how to alter it via the interactive mode. The biggest Aha! moment was realizing that once you do this, you effectively erase the current history starting from the altered commit and you'll get a new one. The changes and messages remain the same (except what was changed), but all commits will become new with new hashes. I used git rebase before, but only to fix very recent issues. So I successfully overlooked this fact. Now I am smarter.

Another 🤯 thing I have learned is that when using GitHub, there are two commit dates - the original Author Date (marking the point of time when the commit was created) and Commit Date (changing when the commit gets edited - or rebased). I learned it the hard way after I force-pushed my changes to GitHub and suddenly 150 commits were "made" on 17th January 2026 😰

That unfortunate event directly leads into my third discovery of existence of git filter-branch command and (more modern) git filter-repo tool. Those can be called into action to do bulk updates over commits. And help undone lapses like mine. So no worries, after another trial-and-error session with Copilot, I managed to repair my flawed Git history, and you could never tell again.

And that concludes my story. If you already knew all the above, good for you. It took me like 8 years of working with Git to dig that deep. I guess one can go even deeper, but I will take a break for a while. If you have stories to share or questions to ask, feel free to express them in the comments below. And stay tuned for another Alois discovers trivial things article.

Disclaimer: You should be careful when tampering with your Git timeline and force-pushing something in the repository. If you have changes in other branches or even uncommitted in your local checkouts, you may get into trouble. If the team is bigger than just you, the troubles may be even bigger. I could afford to ignore those concerns as it was my private repo with no WIP. But this is not always the case.

AI the way out of doubt

Alois Sečkár — Sat, 17 Jan 2026 08:17:54 +0000

When it comes to AI, I believe to be a rational pessimist. I am using AI-powered tools here and there, but I don't see it as a second coming of Jesus that would take our dev jobs and replace us. It is a useful tool, but only a tool. This is probably why I am always a bit behind the newest features and trends that keep emerging every week.

On the other hand, I am not reluctant to AI either. I don't think it is crippling my mind not to write everything by hand and rather focus on the bigger picture than wiring all the boilerplate together. But finding the right tasks to be asked about or even delegated to AI-agent seems to be the biggest bottleneck in my workflows. I am being constrained by too much thinking.

While the other extreme - not thinking and all and just vibe code the entire app and let it to production without any sanity and security checks - might be even worse, not shipping anything, because you cannot decide how to put it together, is not the ideal outcome either. Whenever I manage to break from the circle, the positive results surprise me. I decided to write this article to share my latest small win achieved through AI. Maybe it inspires you too.

The scene

I have a custom page where I collect and keep all my running since 2013 - where I run, how many meters and what time. I am just a casual runner, but it's becoming decent set - nearly 2000 entries and closing to 12K kilometers. And it all can be tracked down to March 11th 2013, when I started with first 1825 meters in 9 minutes and 15 seconds.

The website offers both displaying and filtering the records and the simple admin form, so I can add new record just after I stop running from my phone. It was evolving over the time from custom PHP glued to HTML page to being part of a Nuxt application with using my own nuxt-neon module for database connection.

It had one big flaw - for simplicity, I placed logic to frontend and then never troubled with moving the database operations to server-side. Because noone really cared about my running data, there was no urge to change it. I was always like "yeah, I should do it", but then always like "but not today".

The process

Last Wednesday was another such day.

Productive me: _I should do it now. I need some task for daily GitHub streak anyway."

Lazy me: But I am tired from coding all day at work. And surely some issues will arise and I will have to sort them out till midnight. Nah, let's play videogames instead.

But then for some reason I got that little lightbulb above my head like in cartoons. What if I just try asking Copilot to refactor my code and see what happens?

I nearly fell in the How to write the correct prompt? trap, but this time I didn't get distracted. I decided to apply KISS principle and see.

Therefore, my first prompt was pretty straightforward:

Refactor "getTracks" and "getRuns" methods by moving them to Nuxt server side 
and expose as API routes under /server/routes/tracks.get.ts 
and /server/routes/runs.post.ts. Preserve the "filter" as POST input.

Few months ago, my newsfeed was full of articles about prompt engineering or even context engineering as an emerging must-have skill. But fast-forward to present. Your codebase is the context and even a mere Copilot (with Pro subscription) can understand simple prompts good enough to deliver expected results. I am using Claude Sonet 4.5 model recently, but I didn't really try any comparison with others.

It was thinking and working for a while and then I got my refactor. Being aware of The AI Manifesto, I didn't just accept the something it spit out. I went through all changes carefully.

This is a big advantage for us, seasoned devs - we can verify the results by understanding the code. Even if I am using AI to discover how to do XY, I can follow up to some level and get a basic idea about what is going on. And I can challenge parts I truly don't understand, asking What does this do? or Why you put it there?.

This time the code review was easier because I know how to write a Nitro route. I just took liberty not to since now I have a pocket junior dev who can do it for me. I wouldn't be bothering you with implementation details, I have a series of Nuxt tutorials if you're interested.

Anyway, the outcome exceeded the expectations. The delivered code was fine. The only issue that Copilot cannot foresee (unless I would ship an MCP server along with my nuxt-neon module) was that I recently split server- and client-side composable, so it must import useNeonServer instead of useNeonClient.

I fixed that manually. Towards Copilot, I had one additional remark:

Do we need "useAsyncData"? Shouldn't we be fine with "useFetch"?

This was merely a cosmetic thing, the simpler way of achieving the same result - getting data from backend into frontend. And honestly, it was my fault, because I was using useAsyncData in my code and gullible Copilot just copied it. But he also delivered a fix in no time.

Reading data was secured at backend. Now I needed to do the same for adding new runs. My third prompt was:

Going further. Lets also move "submitRun" method from client side Form.vue 
to new server side /server/routes/runs-add.post.ts and redirect client 
Vueform component to it.

This was fast including AI picked up change to useNeonServer and mimicked it correctly. But a technical issue arose - because the data from input form are being posted as multipart/form-data, standard Nitro readBody method cannot be used for parsing the request. The correct method handling this case is readFormData. Copilot helped me debug based on a simple console log and fixed the error itself.

The last piece was to migrate function for deleting erroneous entries:

Last refactor. Move "deleteRun" from Table.vue to backend to 
/server/run-delete.delete.ts

This would have been a walk in the park, if I didn't misclicked to "undo" instead "keep" button and didn't accidentally erase all the changes 🙈 Fortunately, AI doesn't judge and swiftly re-created the edit.

I spend some more time testing (and coming up with new refactoring ideas), but the job I was afraid to start was done.

The outcome

One evening, less than one hour, and the migration from vulnerable Nuxt frontend to more secured Nitro backend was completed. Most of the time I didn't write code, I was just reading and verifying what Copilot produced.

The task I didn't want to start was finished before it could bother me. It was fun, it was useful and it moved me forward. Just wonder how many more tasks like this wait ahead. Let's find out.

Nuxt Tutorial 8 - UI Integrations

Alois Sečkár — Sun, 11 Jan 2026 15:32:27 +0000

In the previous part we dealt with CSS; now we’ll move on to more advanced UI integrations. Just like with styling, you don’t necessarily need to reinvent the wheel. Instead of building every functional element from scratch, it’s usually easier to reach for a dedicated library.

We’ll go through four practical integration examples. The selection isn’t driven by any deep logic - these are simply technologies I’ve come across and needed them in my Nuxt projects. Still, they demonstrate some general techniques you can reuse if you ever need to integrate something similar. At the end of the article, you’ll also find links to ready-made integrations for other well-known UI libraries from the Vue ecosystem. Let’s dive in.

Bootstrap

Bootstrap used to be - and may still be - the most popular CSS framework for fast, responsive web development. It includes a set of predefined CSS classes, components, and JS plugins that make it easier to build modern design, responsive layouts, forms, navigation, and other interactive elements. It goes further than the previously covered Tailwind CSS, which focuses solely on styling.

Personally, I never really like it. If you’re starting today, I’d rather recommend combining Tailwind CSS with some library specialized in form controls (one of the next articles will cover those). But many developers are used to Bootstrap from earlier days, and of course Nuxt doesn’t prevent you from continuing to use it.

Nuxt integration

You can find some Bootstrap solutions in the Nuxt modules directory, but I had doubts about how up-to-date they are, so I chose a DIY approach via a Nuxt plugin. We haven’t covered plugins yet, but they’re an effective way to add new functionality to a base Nuxt app.

A quick explanatory aside: Nuxt plugin in this context is a file in the /app/plugins folder that can enrich the Nuxt instance - or even the underlying Vue.js app - via a dedicated function. Nuxt loads these files automatically and runs them at startup.

In your project you need dependencies on the NPM package bootstrap and on sass (similar to Open Props, you’ll need some extra CSS processing for your input stylesheet and this is the recommended way). Import Bootstrap styles in the main .scss file in /app/assets/:

/* /app/assets/main.scss */
@import 'bootstrap/scss/bootstrap';

In nuxt.config.ts we must register this file via css option:

// /nuxt.config.ts
export default defineNuxtConfig({
  css: ['~/assets/main.scss']
  // ...
})

Finally, we also need a plugin that provides interactivity to the Nuxt app via Bootstrap JS. These three lines will do:

// /app/plugins/Bootstrap.ts
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.provide('bootstrap', import('bootstrap'))
})

The defineNuxtPlugin function is the handler mentioned above. Its callback receives the Nuxt app instance and lets you interact with it in various ways via its exposed API. For example, using provide you can provide everything that the bootstrap package offers through its exports.

You can find the source code of a simple example implementation here:
nuxt-bootstrap @ GitHub and see it in action.

DevExtreme

The DevExtreme UI library was first introduced to me by an “Angular guy” colleague. It’s framework agnostic though, so you can use it in Vue as well. The main downside is obvious right away: it’s paid — and not cheap. On the other hand, we used it on a larger real-world project at work, and I have to say building complex nested forms (assembled entirely from scratch) was incredibly smooth with DevExtreme. Their layouts also made it reasonably responsive. The documentation is high quality too, although it took me a bit to learn how to navigate through it.

Another small blemish is that for some reason Dx components don’t work with Server-Side Rendering - or at least, even after several years I never figured out what needed to be done. So you need to set ssr: false and accept that the app will render via JavaScript only in the client’s browser. That makes it more suitable for SPAs (Single Page Applications), where users treat the website more like a desktop application and are willing to wait a bit for the content to load - which was our case. For projects where loading speed and SEO are critical (typically e-shops), it might not be the best fit.

Nuxt integration

In package.json you need to reference the base NPM package devextreme and its Vue port devextreme-vue. That alone is enough for local development, but the problem is that “tree-shaking” (removing unused dependencies from the production build) doesn’t recognize you’re using its components, and it happily strips all the definitions out of the final bundle.

I struggled with this for quite a while and eventually had to get help. The key is, again, a Nuxt plugin where you gradually register the DevExtreme components you want to use as Vue components. I strongly recommend registering them under the same names DevExtreme uses — otherwise you lose the ability to easily search their documentation.

In this example I only use a basic button, but the principle is the same for everything else:

// /app/plugins/DevExtreme.ts
import { DxButton } from 'devextreme-vue/button'

export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.component('DxButton', DxButton)
})

The DxButton component then becomes globally available in all your app’s component templates, and you can use it anywhere exactly as described in the DevExtreme documentation without additional constraints.

You can find the source code of the example implementation here:
nuxt-dx @ GitHub

After starting the app, you’ll notice a very prominent license warning in the header that DevExtreme injects into the unregistered version. That’s a reminder that without a purchased license, this integration won’t help you much. Still, we’ve demonstrated the general principle of using plugins to add any external Vue components into Nuxt.

FontAwesome

After general-purpose UI libraries, let’s move to FontAwesome, a popular solution for displaying icons on websites and in apps. It provides a wide selection of vector icons in SVG form (and also as font files) that you can easily use via CSS. FontAwesome allows simple manipulation of icons: changing size, color, and more.

“FA” used to be an evergreen in web design a few years ago, similar to Bootstrap. I think it’s past its peak too, but let’s still take a look. Since the time I solved the integration manually, a module has been created, so it may be easier today than what I describe below. My solution requires at least three new dependencies in package.json (more if you want to use icons from additional (paid!) sets), and overall it feels a bit clunky to me. But if you’re used to it and can list FontAwesome icon names off the top of your head, you can bring it into Nuxt with you.

The downside is that, like DevExtreme, FontAwesome doesn’t play nicely with Nuxt SSR, so you need to set ssr: false.

Nuxt integration

I integrated FA into a Nuxt project using a plugin again. This time it’s a bit less intuitive: you first extend the library object with the icon definitions you want to use, then take the FontAwesomeIcon object (from another FA package) and register it as a Vue component inside your app:

// /app/plugins/FontAwesome.ts
import {
  faEnvelope, faFaceSmile, faHouse
} from '@fortawesome/free-solid-svg-icons'
import { library } from '@fortawesome/fontawesome-svg-core'
import { FontAwesomeIcon } from '@fortawesome/vue-fontawesome'

// these icons will be available as values for the "icon" attribute
library.add(faEnvelope)
library.add(faFaceSmile)
library.add(faHouse)

// register the "fa" component
export default defineNuxtPlugin((nuxtApp) => {
  nuxtApp.vueApp.component('fa', FontAwesomeIcon)
})

In component templates you can then use the <fa> component like this:

<fa class="icon" icon="envelope" title="FA 'envelope' icon" />

You can find the source code of the example implementation here:
nuxt-fa @ GitHub

Icônes

Because I don’t consider the solution above particularly good, I’d like to immediately present an alternative. Icônes is a project focused on providing a large collection of icons for websites and apps. It offers a wide selection of SVG vector icons that are easy to use and customize. Icônes makes icon integration simpler and helps improve the visual quality of user interfaces.

If you ask me what to use for icons, I’ll recommend Icônes without hesitation. It gives you an easy way to get SVG-based definitions that are portable across environments, requires no new dependencies, and offers a huge library of icon definitions for free. In Nuxt - or rather, directly in Vue - you can introduce each icon as its own component. If you’re not using a UI library that handles icons in its own way (see e.g. the upcoming article about Nuxt UI), this is an excellent lightweight option that lets you use only what you actually need.

Nuxt integration

Unlike previous, this truly works without any external dependency. You simply find the icon you want on the Icônes website and export the source code directly as a Vue component. In my demo, three selected icons are copied this way into the /components folder.

You can find the source code of the example implementation here:
nuxt-icones @ GitHub

Universal icon component

You may have noticed (as I did) that these generated components look almost identical and differ only in their <svg> and <path> definitions.

In another project, I therefore have a component that renders one of predefined Icônes icons based on a definition from a data file. When the app needs a new icon, a new definition is added into the JSON file and linked from icon component. Feel free to use this idea as inspiration in your own projects.

Wrap up

In this article, we saw four examples of integrating external UI libraries into a Nuxt app. It’s definitely not an exhaustive list of your options, but I think it’s a solid starting point for inspiration.

In many cases, there’s already a ready-made Nuxt module for popular technologies that handles the integration for you. For example:

I don’t have personal experience with any of these, but you’ll surely find support in the active and friendly Nuxt community. And if you have a favorite CSS framework or UI library and you’re missing a Nuxt setup guide, reach me through a comment below and we can try to figure out the integration.

Next time, we’ll take a closer look at one more option that I intentionally left out so far - and also quickly adopted as my own: the Nuxt UI module directly from the Nuxt team.

New in Vue - December 2025

Alois Sečkár — Mon, 29 Dec 2025 15:14:09 +0000

Hi, everyone. This will be my 24th and last article in 2025. I wish you all a great start into the upcoming New year 2026 and before it happens, let's do this quick recap of latest development in the Vue / Nuxt / Vite world once again.

Vue will probably end 2025 in maintenance version 3.5.26. Vue v3.5 was released more than a year ago, so we can say the fundament of our ecosystem is pretty solid and stable right now. Bugs are being fixed, dependencies patched, and minor tweaks appear from time to time, but overall the code base has been settled and we can develop without worrying we will have to rebuild everything every few months.

I am not even aware of any ground-breaking changes under development, besides long anticipated Vapor mode, a new strategy for faster components' rendering. This will land in Vue 3.6 whose beta release appeared right before Christmas. If you want to know more, there is an article by Evan You himself. It was released in March though, so you can see the whole process takes its time.

I would say a solid portion of development effort was re-directed to Vite, the build tool originally designed for Vue which but overgrew into viable cornerstone of JavaScript development. And it is growing further as you can follow at the Void(0) blog page. Vite itself is now available in version 7.3 with upcoming v8 iterating towards the final release. Everything you need to know about Vite v8, is here.

Finally, Nuxt release cycle slowed down a bit in the last couple of weeks. Recent v4.2 is here with us for 2 months already with second patch release 4.2.2 being the last available version. Former v3 is still being maintained with backported version released together with v4 (3.20.2 is the most recent), but the scheduled EOL date (2026-01-31) is getting close. The relative stability is the good news, as it means other parts of the ecosystem as various modules may catch up and stabilize themselves around the latest releases too. Meanwhile, new major Nuxt version 5 is somewhere out there in the distance, probably closer than you fear, but farther then you hope. Or maybe vice versa, if you don't want to migrate again (though it is promised it should be easy and straightforward). Anyway, we'll see what happens in 2026.

Aside vanilla framework, Nuxt offers a number of wonderful modules to extend the core functionality. One of the most prominent official ones is Nuxt UI, the UI toolkit. The library keeps evolving, with latest version 4.3, that was released on 17th December. If you pick it for your next project, you may benefit from this practical guide about how to set up your IDE. Actually, you should check the article anyway, because many tips apply to Vue/Nuxt development in general. And I can confirm I was already using most of the extensions mentioned - they're valid and battle-tested.

If you want to receive ecosystem updates more often than once in a month, there are Weekly Vue News, an email newsletter being delivered each Monday. I certainly recommend you to subscribe, as I am getting a lot of inspirations from there.

Last but not least I want to spotlight a comprehensive NPM security guide composed by cybersecurity expert Liran Tal. In the woke of recent supply-chain attacks outbreak it is always good to remind and revise strategies to keep your projects safer.

Stay safe, have a great rest of 2025 and a successful start into 2026. See you again in the New year! 🫡

Upcoming events

VueJS Amsterdam 2026 - 12-13 March 2026, Amsterdam [NED]
Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!

Nuxt Tutorial 7 - Adopting CSS

Alois Sečkár — Sun, 21 Dec 2025 17:46:39 +0000

We already know how to get a Nuxt application up and running and how to use the various building blocks to assemble it. Now it's time to give our pages a reasonably decent look. In theory, we could handle that ourselves - using CSS styles defined inside the <style> sections of individual components. If you're confident with CSS, you can have a nice-looking website pretty quickly.

Most of the time, though, we don't want to rebuild everything from scratch. In this article you'll first see how easy it is to import ready-made CSS files, and then we'll go through two example integrations with projects that make styling much easier: Tailwind CSS and Open Props.

Import CSS

If you're migrating an older project, you might already have your .css style files ready. Or you may be using a service that ships its styles as a standalone .css file (i.e. when using Bootstrap from a CDN). Nuxt offers a very simple integration for these cases.

Upload your style files into the /app/assets folder (usually into /css sub-directory for better clarity). Then reference them via the css option in your nuxt.config.ts config file, i.e.:

export default defineNuxtConfig({
  css: ['~/assets/css/main.css']
  // ...
})

The imported styles are then automatically available across the whole application.

If needed, you can also load them individually per component - either in the <script setup> section:

<script setup lang="ts">
import '~/assets/css/main.css'
</script>

or inside <style>:

<style scoped>
@import url("~/assets/css/main.css");
</style>

Little sidenote: In example above I added scoped attribute to denote the style sheet should only be relevant for the component file itself. Otherwise the styles would leak globally. While this may be a bad thing, you can also do it on purpose (preferably in app.vue) and make your styles available throughout the whole application. More common is to use the css option in Nuxt config though.

Even with just this, you can achieve quite a lot. For examples of integrations with more advanced CSS libraries, keep reading.

Tailwind CSS

Tailwind CSS is a CSS framework for styling websites and applications. Unlike the traditional CSS approach, you don't write your own classes; instead, you compose the final look from a large set of predefined utility classes, which enables fast and flexible styling and layouts. Tailwind itself is also highly adaptable and configurable - for example when it comes to defining color schemes.

It deserves an article of its own (which I originally planned, and maybe I'll get to it eventually). For me it's currently the number one choice for building a website's look. It requires a slightly different philosophy, but I adjusted in a day, and I don't want to do it any other way now. I migrated couple of my personal projects to Tailwind CSS already, where the original design was done “by hand”. Converting them into the corresponding Tailwind structure usually took just one evening.

It's fair to note it's not a CSS framework “for purists” because it does impose some constraints. Others criticize it for creating too much abstraction and giving users the illusion that they understand what they're doing - until they hit a trap they can't resolve because they don't really know the underlying CSS. My experience, however, is that it will be enough in vast majority of situations, and its efficiency gives you more time to handle the remaining edge cases.

Nuxt integration

Getting started with Tailwind CSS is now very straightforward. The creators ship a plugin for Vite (the build tool Nuxt uses), which you just install together with the main library:

npm install tailwindcss @tailwindcss/vite

Then add the plugin to nuxt.config.ts along with a reference to the CSS file that imports Tailwind:

import tailwindcss from "@tailwindcss/vite";

export default defineNuxtConfig({
  // Vite integration plugin
  vite: {
    plugins: [
      tailwindcss(),
    ],
  },
  // CSS file importing Tailwind classes
  css: ['~/assets/css/tailwind.css']

  // other config...

});

The final step is creating a simple CSS file that you load via the css option. Its content can be as minimal as:

@import "tailwindcss";

Demo app

You can try the approach above in practice. The source code for the demo implementation is here: nuxt-tailwind @ GitHub

The demo focuses on both integration and usage. All the visual behavior is in /app/app.vue. It contains several examples of how Tailwind CSS can be applied. It also shows that utility classes can be freely combined with classic “plain” CSS. In /app/assets/css/tailwind.css you can see how easily you can extend Tailwind CSS' default @theme with your own colors or fonts if the base palette isn't enough.

Based on a personal bad experience, I also decided to add one cautionary example to the demo alongside the positive ones. I'm risking that it might inspire someone to use it and fall into the same trap I once did, but hopefully it will save many of you from unnecessary problems. What is it about? The Tailwind CSS authors encourage you to use utility classes directly in HTML templates as attributes on individual elements whenever possible. Not everyone (hi, former me) likes that, because:

Class lists can get really long
The same definitions repeat

At the same time, a beginner - armed with general programming truths and ready to “fix” things - will sooner or later discover the @apply directive, which seems to allow defining reusable classes in CSS files. And to be fair: it does allow it, and it works perfectly. The problem is that it severely obfuscates the implementation. After a few months, you forget you styled a <div> globally and wonder why your inline definitions don't apply. The demo app includes a clear example with the color of an HTML link at the bottom of the page. I wrote more about this in this article.

End of the diversion. Definitely take a look at Tailwind CSS - you might end up liking it like I do, along with thousands of other developers who prioritize speed and efficiency over perfect control via native CSS.

P.S.: Previously I handled the integration via a dedicated Nuxt module, which was a bit easier to set up (install + add the module). I'm not sure about its current status, though. After Tailwind v4 was released, it stopped working for me. Its new version has been stuck in beta for months, and it almost looks like its historical role is over. If the situation changes, I'll come back and update this article.

Open Props

Open Props is based on a similar idea to Tailwind CSS - it provides a set of prebuilt styles that may constrain you a bit, but in return you don't have to reinvent the wheel everywhere. Instead of shipping complete prebuilt CSS classes, Open Props encodes the styling information as CSS variables, which you can use and compose inside your own classes. To be honest: Tailwind v4 also uses CSS variables, and you may have already tasted them (even unknowingly) - see how the demo app extends the default @theme.

Open Props sits one level lower. It doesn't abstract away writing CSS entirely; it “only” provides ready-made, proven values. That gives you more freedom, but it's a bit more work. The main advantage is how lightweight and scalable it is - the library lets you use only the small subset you actually need.

Nuxt integration

Because Nuxt (Vue) can't replace CSS variables with actual values at build time by itself, you need to add a CSS processor (postcss in my demo) along with a plugin that performs the substitution after being fed the definitions from OpenProps. That's about the only catch; otherwise you just import the open-props NPM package and start building CSS definitions. There is a showcase of a few styles in the demo.

What I like most about Open Props are the ready-made gradients - smooth transitions between colors. Sure, it's not that hard to write them yourself in plain CSS (I even watched a demo of building a “gradient editor” recently), but if you're not a web designer at heart, who wants to grind through that?

The source code for the demo implementation is here:
nuxt-openprops @ GitHub

Summary

We've shown how to load internal and external CSS files into a Nuxt app, plus two examples of CSS libraries and how to integrate them. There are, of course, many other options. If you have a favorite UI/styling library, check whether it already has a Nuxt integration (most commonly in the form of a module). If not, it may be enough just to load the resulting CSS files the way we described at the start and use them directly. And if you get stuck, reach out and we can try to figure something out together.

In the upcoming tutorial article, we'll move from general styling to more advanced UI libraries, which provide not only styles but also prebuilt UI components. We'll look at a few of them along with examples of integrating them into Nuxt.

I made my Vitest suite in Nuxt run ten times faster

Alois Sečkár — Sat, 20 Dec 2025 11:21:08 +0000

Previously I had to wait about 3 minutes till my tests finish, now the same suite clocks under 20 seconds. Let's see what the bottleneck was and how I vibe coded the re-design. Spoiler: It was painful running in circles and despite AI gave me some valuable insights, I had to be the Deus ex Machina (pun intended).

I guess I don't have to explain the importance of writing automated tests to protect applications from introducing unnecessary errors. It is never 100%, but as the time flows, test suites grow larger, cover more situations and especially prevent bugs from re-appearing. I would say it is rather hard to develop a habit of writing tests regularly, especially in personal projects, but current tooling focus on making it easy. Setting up Vitest to test Nuxt applications is quick and you're good to go.

You can develop a new feature, write new tests for it, and run the suite to check if:

New tests are passing - so the new feature works as intended
Old tests are still passing - so you didn't accidentally break any seemingly unrelated things

Then you can commit with greater confidence.

But there is a catch - more tests run longer and former seconds may prolong to minutes. So you wait minutes and then you come back and see the test suite failed. You fix the error, run the tests again...and wait minutes again. Do this couple of times and you suddenly don't like the whole idea that much.

Framing the problem

Test suite for my Nuxt module for Neon database connection reached 180+ seconds of runtime. This didn't feel right anymore. The tests were testing, but the inefficiency hit my DevEx hard. It was the turning point when premature optimization turned into a required one.

Because it is 2025, I invited AI to check the situation and brainstorm for possible solutions.

Copilot quickly pointed out, that I am using separate Nuxt app instance for each test file. At first it looked like a good decision to separate concerns - testing SELECT operations in an app for selects, INSERT in another one. It should help keeping things small and organized. But booting them up takes time and all tests had to wait until their app is rendered.

To make the problem worse, I decided to run my tests sequentially. Because if something messes up and the module cannot even connect to the database, why tests the functions? Or if SELECTs are failing due to an error in constructing the SQL query, why to try INSERTs that would also inevitably fail? This stacks the waiting times up. And despite everything eventually works, I ended up waiting those 3 minutes.

First iteration - double speed

The fix was apparent - merge the separate test apps into one. This was quite easy to do, because I designed my tests so that each has its dedicated Nuxt page (this means separate URL) where it connects, perform SQL action bound to a button and check the resulting HTML for expected values. So I really just have to squash multiple /app/pages directories into one and make some small adjustments in app.vue file.

But it wasn't enough. Because my E2E test files would still

await setup({
  rootDir: fileURLToPath(new URL('./neon-test-app', import.meta.url)),
})

via a function from @nuxt/test-utils/e2e package. This would still create and bind new instance of Nuxt app for each test file. So it would still take a lot of time.

To be honest, there was already an observable speed-up. I guess it was because it can re-use some cached pieces and mounting the same app 5 times was about twice as fast as mounting 5 different apps, but it was still very sub-optimal.

What I really needed was that whenever any test case does

const page = await createPage()

it should connect to the same instance of underlying demo application. This would only start once and then all tests should call it with a snap.

Second iteration - 10x speed, but...

So how to do that? I didn't know. So I asked my smarter/dumber electronic assistant. It came up with very unorthodox solution. If you want to follow along, the result was committed HERE. I will now sum up the most important pieces.

In vitest.config.ts, new setting was added:

globalSetup: ['./node_modules/@nuxt/test-utils/dist/runtime/global-setup.mjs'],

It took me a while to understand what it is even intended to do. I challenged my Copilot's reasoning and cross-checked with my standalone ChatGPT 5.2 Plus. It confirmed the idea. Despite it testified it didn't find any article or discussion about it, it says it assumed from the code, it would work. The justification made sense. I had nothing to lose. So I believed.

In short, running this file in globalSetup before other Vitest actions start should "magically" grant me existence of a mounted app in emulated browser. To tell it, which app I want to mount, I should feed NUXT_TEST_OPTIONS environment variables which are swallowed during the process.

const rootDir = resolve(fileURLToPath(
  new URL('.', import.meta.url)), 'test/neon-test-app')

// Used by @nuxt/test-utils/runtime/global-setup
process.env.NUXT_TEST_OPTIONS = JSON.stringify({
  // path to neon-test-app
  rootDir,
  // don't create a Playwright browser in globalSetup
  browser: false,
})

The second integral part was e2e.setup.ts - a file to add actions to be run by Vitest before every test file. In beforeAll method it should construct a virtual browser instance - but only for the first time when it is non-existent:

const ctx = useTestContext()
if (!ctx.browser) {
  await createBrowser()
}

And just like that, this would grant all test files access to the shared context with prepared virtual browser with mounted Nuxt test app. And all tests should just:

const page = await createPage()

and start navigating to desired routes and testing the stuff.

I tried to follow my usual sceptical approach to AI and understand the intents behind the code spitted out - at least briefly. I couldn't grasp all details, but overall it appeared to make sense. And when I tried it - it worked!

Well, not for the first time. We had to tweak couple of things, but in the end the suite was running. And boy, it was fast! Less than 20 seconds and all tests already passed. If I deliberately made a test fail to check, whether it actually runs and tests something, it started failing just as expected. My job here was done. Commit, close the issue, go to sleep with good feeling.

Except there was a "tiny" detail I missed at the time. The Vitest suite was running fine, but once the process is finished, the output just disappeared from the terminal! So there was no chance to recover the result. Unless you looked at it, you had no chance to tell whether it passed or not. And if it failed, there was no way to see what exactly went wrong.

My tests essentially become useless 😨

Third iteration - to hell and back

The reason why I missed it when I worked on it is interesting per se.

Because we tried a number of things with my Copilot during the process, at some time we introduced $env:DEBUG='@nuxt/test-utils*' setting into my current terminal. Thanks to this extra environment setting, the program started to log differently - extensively and without interruption. All the log messages were prefixed with [source] tags, but I barely noticed that. I saw the Vitest output and I was happy.

But the default way of things with the globalSetup is, that the terminal is first occupied with the test Nuxt app build and then it is automatically switched into a new alternate screen that is visible in the terminal, but only as long as the associated process is running. Then it is just thrown away and replaced by former (empty) terminal.

I didn't know that, until I spend HOURS of useless attempts of adding config here and there. AI was spitting out fabricated theories, and I was struggling with implementing them and keep failing again and again.

After some time we at least isolate the DEBUG option as a possible workaround. But it also came with a very noisy and verbose output. Filtering out was possible, but platform-dependant. Or I could have wait for 20 seconds of silence and then got the filtered result processed by Node. Also not good.

I tried to bargain with AI until I finally - for the first time I thing - managed to force ChatGPT into saying: "No, this is not possible." More precisely, it wrote: "This is the moment where I need to be very explicit and honest, because you’ve now hit a hard boundary, not a missing trick." which I find hilarious now, but I didn't laugh back then.

The harsh truth hitting me that evening. I wasted hours chasing my own shadow. With AI happily assisting me and encouraging me to continue.

I have fast, but badly observable tests. Either no output at all, or an output littered by tons of non-related debug messages, or platform-dependant script commands to polish it.

Fourth iteration - deus ex homine

In my last article I went to sleep on the problem, and it didn't help. But this time it does. When I woke up this morning, prepared to finalize the ugly but so-so working solution, I suddenly got an out-of-the-box idea.

What if I stop trying to abuse Vitest into doing something it is not designed for?

What if I just aggregate my test files into one big suite?

Like that it would only need to build and mount the test app once and then it will run fast. Yes, there would be a little trade-off - one big test file with a lot of test cases. But to be honest, this doesn't really matter from the runtime perspective. And I can still keep the source code isolated by having separate definition files that will be dynamically imported in the actual single e2e.test.ts file, the only one that will be executed by Vitest.

And so just like that, I throw away most of the "clever hacks" from the solution #3 and came up with something else. Despite my AI assistants failed yesterday, I indeed used them again to help me fabricated the vivid solution. Now when I was back with a clear intention in mind, I got helpful output and tips again. The final solution is HERE.

Calls for globalSetup and even the setupFiles were removed from vitest.config.ts. The all I need now is a nice, small and clean e2e.test.ts file:

import { fileURLToPath } from 'node:url'
import { setup } from '@nuxt/test-utils/e2e'

// only setup nuxt-test-app ONCE
await setup({
  rootDir: fileURLToPath(new URL('../neon-test-app', import.meta.url)),
  // Playwright browser is not required for now
  browser: false,
})

// import and run E2E test suites AFTER the test app is ready
await import('../neon-test-suites/01-basic')
await import('../neon-test-suites/02-select')
await import('../neon-test-suites/03-insert')
await import('../neon-test-suites/04-update')
await import('../neon-test-suites/05-delete')

It prepares the Nuxt test app via dedicated setup function and then just awaits and executes one file with test definitions after another.

And that's it. No hacks, no mess in console. It works like charm and it is still fast. 20 seconds and you're done. The output remains in the console.

To infinity and beyond

So now you know how I wrestle with Vitest with Nuxt and won. If you'd like to know more details about the final implementation or you have objections and ideas for improvement, let me know in the comments.

You also seen how AI tools still lead you astray easily. To their defence, in this case both Copilot and ChatGPT pretty much resembled a common developer, who is desperately throwing solutions that "should work" without realizing the whole picture. Where they failed and I eventually succeeded was ability to step back and re-think the whole situation. I believe this is still the gap between human developers and the artificial pseudo-intelligence.

Lastly, this wasn't meant to be an anti-AI rant. It is helping me on daily basis, and I really enjoy getting further and further with its assistance. I just think there are still limits we need to be aware of. It was another nice lesson for me, and I hope you found it somewhat interesting too.

Looking forward to your feedback and questions.

The Mysterious Case of the Query that Never Ran

Alois Sečkár — Sat, 13 Dec 2025 09:54:47 +0000

Over the past weekend I encountered a weird bug.

I was refactoring code for my personal website. I am a casual runner and I have a page with all my run records. The data for it are stored in Neon database and I am reading them through my own custom nuxt-neon module.

I was updating the code to reflect the latest changes in my module. Namely I tried to change the filtering by date (year and/or month). Originally, I use literal string WHERE condition r.date BETWEEN '${fromDate}' AND '${toDate}'. Now I planned to battle-test my new object syntax:

where.push({ 
  column: 'r.date', 
  condition: '>=',
  value: fromDate,
});
where.push({ 
  column: 'r.date', 
  condition: '<=', 
  value: toDate, 
  operator: 'AND' 
});

Now, you may argue this is much more complicated and you'd probably be right. But I wanted to test how it works beyond sterile tests defined inside my module. And...

It was a complete failure.

No data. Just an ugly HTTP error when trying to get data from the Nuxt server endpoint:

NuxtNeonClientError in fetchFromNeonBackend: 
[POST] "/api/_neon/select": 400 Bad Request (status: 500).

To make a quick explanation - my module is providing a client-side composable useNeon that exposes couple of wrappers for SQL functions (namely select in this case). Those wrappers are essentially just forwarding input query to Nuxt server endpoints for each SQL function. Like this, I can keep the DB credentials safely stored on the server side and not leak them via runtime config into the browser. AFAIK Neon does not provide safe public API keys as services like Supabase do.

So I started to investigate what might be wrong.

At first, I thought I messed up the implementation, and I am constructing a bad SQL query. But there were two "buts" to this theory:

The very same query worked just fine when I reproduced it as a test case in my module codebase. And in fact, I was already testing whether "greater than / less than" operators pick the right data.
Despite I set enhanced debug logs for my module (you can debug both the execution flow and the actual SQL produced inside the module), I saw no data for my request. Actually, it looked like the API endpoint wasn't even called.

I found myself desperately tampering with the files inside my node_modules folder trying to track down where I am and why I am not seeing any usable output to understand the issue.

I had a faint suspicion that the literal characters > and < should be the root issue. But no viable theory of why it would matter.

I gave it a one-day break and unsurprisingly I didn't get any brilliant idea overnight. As a last resort, I just tried to ask my Copilot. I was postponing this move, because what would my question be? I don't understand what is going on, how should I instruct mindless LLM to come up with a solution? Without good prompt, I can't get good result, can I?

Well no, but actually yes. Copilot didn't magically save the day. But it gave me one important clue to follow: "Reproduce with curl (bypasses browser and frontend)"

This means, just call the API endpoint directly with a bare HTTP request. Strip it down from all frontend framework noise. Then you might understand better what is breaking up before backend can process your request. So I did as machine mind said and voilà!, everything clicked together.

Turned out my request was being rejected by Nuxt Security module and its XSS attack protection:

...\node_modules\.pnpm\nuxt-security@2.4.0_magicast@0.3.5_rollup@4.52.5\
node_modules\nuxt-security\dist\runtime\server\middleware\
xssValidator.js:38:18

Like that, it is pretty obvious. The problem was this particular line was swallowed inside Nuxt leaving me only with a cryptic error with no apparent reason.

Naturally, it was because of the > and < brackets. Nuxt Security treats them as potentially malicious attempt to smuggle a script into the payload. Between me and you - this module is pretty good in protecting your Nuxt applications with little to no effort of setting it up, but then it keeps biting you back like that.

So this was the missing piece. It worked in my tests because the naive demo app is not concerned about security that much. But I chose to shield my homepage with more advanced protection, and it backfired.

To mitigate the problem, I am adding an internal mapping that translates angle brackets to text abbreviations on client and back when constructing the actual SQL query on the server. For user convenience I decided to keep them available instead of forcing everyone to learn they should use GT and LT abstraction.

Despite the root cause and the solution itself isn't groundbreaking, I still thought the unique combination of circumstances is worth an article. I wanted to share following lessons learned from this debugging struggle:

Don't be shy to ask AI for help - Even if you don't know the right question yet, just ask: "Why do I have this error?" Start explaining the situation and you may vibedebug the solution eventually. It keeps surprising me how effective this becomes lately.
Isolate the problem - If backend seems not to respond properly, call it directly to abstract from possible interference. I should have known this after all those years in software development, yet I got lost in the frontend land and needed virtual assistant to pull me out.
Take 3rd party SW in account - Maybe it is not just your code that causes the trouble. Maybe some other library is acting up (because of something in your code).

I have been developing software for at least two decades now. I feel like a senior and being treated as such. But as you can see, I keep getting stuck in trivial situations and feeling rather stupid afterwards. I believe this is part of the process. You keep running into the walls, keep falling down and keep raising up, being ready for more.

Thank you for reading this and may it help someone in the future. Until the next awkward issue to solve.

New in Vue - November 2025

Alois Sečkár — Thu, 27 Nov 2025 13:21:49 +0000

Attention! More news and events from the ever-evolving world of Vue, Nuxt, Vite, and their awesome open-source ecosystems are there.

I would like to start 5th issue of my Vue newsletter with something I haven't done yet - sharing a video:

As you can see, it is a flashback from the ViteConf I was talking about last month. The reason why am I featuring this is interesting topic of not-so-distant future of our ecosystem together with the awesome stage presence of the speaker. I remember my very first impression was "Oh wow, the guy sounds quite nervous". But then Jim Dummet delivered one of the most memorable IT talk I can think about. The fact it was his only second live talk ever makes it even more awesome. Give it a try if you have a spare 30 minutes.

Speaking about ViteConf, two more interesting news I forgot to point out in October were released there. The Vite DevTools project was announced by Anthony Fu, which will bring the developer experience one more step (or even a leap) forward. Despite it seems nowhere near close to stable release yet, it is something worth paying attention to. And I am looking forward to the result. Second update came from Nitro - an alpha version of its v3 major upgrade was released during the conference by its maintainer Pooya Parsa. Also not finished yet, but another gamechanger in the ecosystem that is knocking at the door.

To get a comprehensive overview of what happened in Amsterdam (and should NOT stay in Amsterdam) was written by Alex Lichter, so if you want more detail plus direct links to respective talks, give it a go.

Overall November was quieter in terms of hot ecosystem news. Or they went past me if there were any. The one that hit me and I find it worth mentioning was the alpha release of Nuxt Hints module. It is promised to provide "real-time feedback on your application's performance, accessibility, and security right in your browser". I believe it will become very helpful to make our Nuxt apps better. It is out for two weeks now, and I am looking forward to set it up and give it a try. Sadly, there wasn't time for that yet.

Tiny promo (getting no commission for this, I just like it) - if you need an easy way of integrating Share with <<insert_socal_network>> buttons to your website, Nuxt Social Share is there for help. It is incredibly easy with zero knowledge of the APIs required - you just add a component, pick the target via a string prop and get the sharing functionality. I set it up within minutes for my blog. The "hardest" part is to adjust the default styling, but it uses Tailwind CSS, so it is actually not that hard at all. I really recommend this 👍

Did you ever feel overwhelmed by different approaches to managing stateful data in Vue applications? Michael Hoffmann wrote a useful guide for how to pick between Composables, Provide/Inject, and Pinia which might help you navigate through it. He also runs Weekly Vue News email newsletter, so consider subscribing for even more "New In Vue" stuff from him.

I'll be back in late December. Thank you for reading this and if you have any questions or feedback, feel free to use the comments bellow.

Upcoming events

VueJS Amsterdam 2026 - 12-13 March 2026, Amsterdam [NED]
Vueconf.US 2026 - 19-21 May 2026, Atlanta [USA]
MadVue 2026 - 22 May 2026, Madrid [ESP]

Past issues:

Follow me for more updates on Vue, Nuxt, Vite - and maybe even more!

Nuxt Tutorial 6 - Vue.js Intermezzo

Alois Sečkár — Sun, 23 Nov 2025 22:01:10 +0000

In this inserted article, we take a closer look at selected fundamental concepts of the Vue.js framework that Nuxt builds upon. I believe it is not a good idea to use any tool without at least a rough understanding of how it works under the hood. Before we continue exploring more of Nuxt’s great features, we’ll go back to the roots without building anything specific here. But you will end up better prepared when you try it yourself later.

To begin, note the best available source of Vue information - the official documentation. You will learn much more about everything mentioned in this article there, and you can always return to consult questions and issues.

Now for the promised overview of the basics. First, we return to components, which we briefly described earlier, and go a bit deeper now.

Components

The basic building block of a Vue application is a component. By composing and nesting them you create the required functionality. By far the most common (though not the only possible) way to define a component is the SFC – single file component. As the name suggests, it combines all UI parts and logic into a single file identifiable by the .vue extension.

Vue’s built-in compiler can interpret these files and, during the application build, translate them into fully functional HTML + JavaScript. This means that if we want to use them, we must include a build phase during which the transformation happens. I mention this because Vue can also be used statically via a simple standalone script inclusion in an HTML page. But this effectively limits you to use only bits of Vue here and there. However, I already tricked you into adopting the build step from the very beginning with the first pnpm dev command. That’s why we could use SFCs without worrying about anything.

An SFC consists of three main parts:

Template - an HTML‑like template that defines the final appearance of the rendered page
Script - a section for JS/TS code that drives rendering logic, backend communication, and coordination with other parts of the app
Style - a place for defining CSS styles

It is not strictly necessary to include all three. A valid component can contain only <script> (a “renderless” or functional component) or only <template> if you don’t need more substantial data preparation or manipulation. A standalone <style> is not allowed because it wouldn’t be clear what the styles belong to.

I prefer having <template> first, <script> second and <style> last (if present). I found out I swim against a current with this habit, because you'll probably see <script> before <template> more often, but it just feel more natural - first I want to see how the component will look like and only then what values will it display. Data without context seem less useful for me. Anyway, it is a matter of personal preference. The only guideline set is not to mix the order up within a project. Pick just one style and follow it everywhere.

It’s also theoretically possible to define arbitrary custom blocks. Vue lets you declare them, but you must handle them yourself. While I haven’t needed them in practice yet, a good example is an <i18n> block in the eponymous library for facilitating webapp localization.

SFCs are primarily a way to keep all logically connected parts of a certain functionality in one place. This is somewhat at odds with the more traditional (at least for me) separation of concerns. However, in my recent experience it makes much more sense and is much easier to work with than constantly jumping between multiple files. If that’s hard to accept, Vue has sort of a workaround - using the src attribute you can import block contents from other files. I still don’t recommend it. If your .vue files feel bloated, rather consider splitting them into several smaller components.

Now let’s look inside each base block:

Template

Inside the <template> tag is the definition of the content of the future rendered (part of the) page. You write code very similar to HTML, but you can use certain special Vue syntactic features:

Double curly braces (the “mustache” syntax) allow inserting JavaScript - {{ msg }}. During template compilation, the expression is evaluated and interpolated as plain text, and the evaluated current value appears in the rendered HTML. Typically, you want to evaluate only simple variable references or function calls. Technically you are not limited, but it’s considered a good practice to keep the template clean and push heavy JS work into the <script> section or other files - you already know Nuxt allows you to reference them directly thanks to auto‑imports.
A colon : before an attribute name (native or your own - see props section later) is shorthand for v-bind: and binds the attribute to a JavaScript expression. The same advice as above applies - don’t abuse templates for complex inline logic.
An @ before an event name is shorthand for v-on: and binds a handler function. When the specified event is captured (native like click or change, or custom - see emits later), the given function is called. The function can be written inline, but it’s again better to reference a callback defined in the appropriate place.
Other v-* directives are pseudo‑attributes that give the compiler instructions for special handling. For example:
- v-if - renders the element if the condition is met
- v-else - renders the element if the condition is NOT met
- v-show - always render, but show the element only if the condition is met
- v-for - render multiple items from a list in a loop
- v-html - insert HTML‑styled content into an element (beware, potentially dangerous)
- complete list is HERE
- you can also define your own

Vue templates also have the ability to understand references to other components. Use the .vue filename in PascalCase notation as an identifier. In plain Vue, components must be registered before use. Nuxt handles this automatically as long as .vue files are in the /app/components folder (or you configure directorsies where auto‑import should happen).

Thanks to this, you can compose larger functional units from individual SFCs. Vue also fuels the simple, yet powerful two-way communication. We’ll show how it works in a moment.

Script

Because Vue values flexibility, the following is not the only option, but in my opinion there is currently no better approach than wrapping your JavaScript/TypeScript logic using:

<script setup lang="ts">
// your JS/TS logic
</script>

The tag name is obvious. The setup attribute tells the compiler that we will use Vue’s Composition API. I’ve kept quiet until now that another variant exists, but the Options API is, in my view, an obsolete approach not worth learning first. You may come across guides, libraries and legacy codebases that still use it, but there’s no need to burden yourself until you actually need it. I’m confident you won’t regret using <script setup>. All the Vue/Nuxt features mentioned later implicitly assume using it.

The lang="ts" attribute denotes a preprocessor that enables TypeScript support. It isn’t mandatory, but without TypeScript and its static analysis I can’t really imagine my development. Properly configured TypeScript in your IDE immediately warns you about accessing undefined variables, passing wrong argument types, or calling functions that don’t exist - and much more. It’s worth investing a bit of effort up front to understand its principles.

Any JS variables and functions you define inside <script setup> are automatically available to the component template. They are also safely sealed off from the outside unless you explicitly expose them using defineExpose macro. I recommend keeping this block short - declare only elements tightly bound to the current component and refactor longer sequences into separate utils or composables (see the earlier tutorial part). Once we introduce the last section, we’ll get to more concrete examples.

Style

The <style> tag wraps the CSS definition. If you want more than plain CSS, you can use the lang attribute to define a preprocessor (e.g., Sass), but you must first configure it in your project.

It’s a good practice to keep styles inside an SFC local to that component and avoid letting them leaking into the rest of the app. That can have unexpected consequences elsewhere and the source of such bugs is hard to find. Vue makes file‑level encapsulation easy - just add the scoped attribute: <style scoped> - and you’re done. Styles meant to apply globally should be defined at the top level in app.vue, or, if there are more of them, in a separate CSS file loaded via Nuxt config.

You can define multiple <style> blocks in a single component, but I think it’s not very practical. I also haven’t used CSS Modules much.

I would say you’ll likely start relying on this block first, but then you shift towards using it more sparingly - only for specific requirements. Appearance is often handled by UI libraries, and there’s no need to reinvent the wheel. Or if you reach for Tailwind CSS (see this tutorial part for more info), classic CSS almost disappears for you…

Passing Data Between Components

Encapsulating parts of the app into separate components is great, but they must also communicate. Vue provides support for this indeed.

Props

With the special defineProps() function, you can define a set of variables that can be passed into the component from outside. Conceptually this corresponds to public attributes of a class in object‑oriented languages. To be precise, this is not a real function but another compile‑time macro whose contents are transformed when translating the .vue file into real code.

The macro argument is an object of declared properties that Vue refers as props. There are several syntax variants. For a long time I liked so-called object syntax, because it looks natural:

const props = defineProps({
  foo: { type: String, required: true },
  bar: { type: Number },
})

The downside is that for more complex type you need to re-type it via generic Vue utility PropType:

const props = defineProps({
  foo: { type: String, required: true },
  bar: { type: Number },
  ext: { type: Object as PropType<CustomType>},
})

This is not very intuitive and it is unnecessarily complex. Because of that I finally adopted newer type based syntax. It looks weird, but it is more suitable and much shorter:

const props = defineProps<{
  foo: string,
  bar?: number,
  ext?: CustomType,
}>()

You can then use the defined values inside <script> as props.foo and props.bar. In <template> expressions, you can refer to foo or bar directly; the compiler is smart enough to resolve that they are props.

Passing into the child from one level up looks like this:

<template>
  <ChildComponent foo="foo" :bar="2" />
</template>

Thanks to TypeScript, type checking works, so foo only accepts strings and bar only numbers. Note that text can be passed as a normal HTML attribute value, while all other types must be prefixed with a colon (shorthand for v-bind:).

Also remember that you should treat props as read‑only inside a component. If you mutate them, you tightly couple parent and child, which undermines encapsulation and reusability. You can use a prop value to initialize your own local variable (beware of pass‑by‑reference with objects). Usually it’s even better to use v-model or state management (see below).

Emits

That covered passing data into a component; now we need the other direction. Use the defineEmits() macro to declare custom events that a component can emit. In the simplest case, pass an array of event names. In the template, trigger an event by passing its name to $emit:

<button @click="$emit('event')"></button>

In <script>, as with props, refer to the defineEmits result:

const emit = defineEmits(['event'])

function buttonClick() {
  emit('event')
}

In the parent component, listen with @ (shorthand for v-on:) before the declared event name. When the child emits event, the parent’s foo method is called:

<template>
  <ChildComponent @event="foo()" />
</template>

To pass data upward along with the fact that something happened, events can declare payloads whose values are sent with them. Details here: typing component emits.

Provide/Inject

Passing props works well when the component tree is flat. As components nest deeper, you may find you are passing some props only to forward them further down, until finally a deep child uses them. This can lead to the anti‑pattern known as prop drilling. The result is a tightly coupled structure that is hard to maintain because a change in internal implementation forces you to adjust prop definitions in many intermediate components.

Vue sidesteps this with provide and inject. Using provide() you can declare that a component exposes some data to all its descendants:

provide('message', 'foo')

Provided the component is in the ancestor chain, a descendant can request the data with inject():

const message = inject('message')

You can also provide data globally at the application level using app.provide().

While this distribution mechanism may seem useful at first; in my experience I’ve rarely used it. In practice I find state‑management libraries work better (see below). It’s good to know the option exists, though.

We don’t have a similar problem with emits because events naturally bubble up the DOM tree and it’s up to you where to catch them. Additionally, Vue lets you play with event behavior via modifiers.

A brief comment on the DOM: it stands for Document Object Model, the internal representation of an HTML document - tags, their attributes, and content. By nature it’s a tree-like structure from the root element down to the deepest descendants. A lightweight JavaScript variant is the virtual DOM, and because manipulating its objects is much faster and more efficient than touching the real DOM, Vue and other frameworks primarily work with it and only then project the result into actual HTML for rendering.

v-model

A common scenario in interactive apps is a component that accepts an initial value, lets the user work with it, and notifies the parent when it changes. A typical example is a form input.

The v-model directive in combination with the defineModel macro provides a more straightforward definition for this. You can create a simple Child.vue component like this:

<template>
  <input v-model="model" />
</template>

<script setup>
const model = defineModel()
</script>

And call it just as simply from Parent.vue:

<template>
  <Child v-model="foo" />
</template>

Vue automatically ensures that user input updates foo; there’s no need to wire extra handlers. Another nice simplification of routine tasks.

State management

The mechanisms above work fine for simpler apps. As the number of components and interactions grows, constantly thinking about where to wire connections becomes annoying. In such cases, raise the problem a level up and keep the state in one place across the entire application.

Nuxt provides the useState composable, which is sufficient for less complex data on its own. The de facto standard for state management in Vue is currently Pinia, which makes it easy to create, maintain, and safely use global state anywhere in a Vue (Nuxt) app. More on this later in a separate article.

Reactivity

Vue’s true power appears when you start working with dynamically changing data. For example, after clicking a button, you want the “number of clicks” value to update. You register a click listener, increment a variable… and then what? How to force a redraw on the screen? Should you reach into the DOM and edit an element’s text content? None of that - in Vue it just “happens” thanks to reactivity.

In the Vue world, reactivity means you can create special wrapper objects around data that automatically track value changes and react by propagating them to every place where the value is used. Different frameworks solve this general notification problem differently. Vue offers the Reactivity API that makes it straightforward.

We won’t dive deep into the technical background here. If you’re interested, continue with Reactivity in depth in the docs. For now, three functions suffice:

ref() - takes a primitive/object/array and wraps it so the return value is reactive. Wherever you use it, it updates in the future whenever it changes. Such objects (refs) can be used in templates, passed as function arguments or even as props to components and carry their reactivity with them. The small cost is writing name.value when used in scripts to access the inner value. Inside <template>, name suffices because the compiler fills in .value.
computed() - takes a callback function that automatically re‑runs if a reactive change is detected inside - i.e., when some value the system tracks changes. This defines dynamic computations. For example, for a simple adder, you can define two ref() values bound to user input, and their sum is computed(() => a.value + b.value). Whenever the user changes one of the inputs, the result re‑computes immediately.
watch() - allows observing a reactive value and performing a side effect whenever it changes. The first argument determines the value to watch; the second is the callback to run on change. For example, you could track the count of failed login attempts and, after exceeding a limit, set a variable that disables the “Log in” button.

That was a whirlwind tour. The reactivity system is, of course, more complex; more functions exist and offer various options. You can read them as needed. Even with these three basics, you can cover many scenarios.

It’s more worth pointing out a pitfall now. In my experience, the ease of use tends to tempt overuse in places where it’s not needed. As an application grows, especially with computed() and watch(), more and more re‑evaluations happen and a seemingly small change can cause a cascade of calls, not to mention the subsequent manipulations of the DOM. Vue cleverly batches reactive updates and optimizes DOM work, but background load still grows. It also becomes difficult to trace update flows when debugging hidden changes that shouldn’t occur.

To make the problem worse, at first you might not even realize there is any. All reactivity operations run quietly in the background and, because Vue is well optimized for performance, you won’t notice anything wrong in simple apps. When it starts catching up with you, refactoring and optimizing can be quite hard already. It’s better to approach reactivity skeptically from the start - don’t ask “what can I make reactive”, but “what doesn’t need to be reactive”, because it won’t actually change, or it can be solved otherwise than adding computed()/watch().

Still, it’s a very powerful tool and an integral part of a Vue developer’s arsenal. Just beware the Man with a Hammer syndrome.

Component lifecycle

Reactive or not, a Vue component instance is not a static entity. It goes through several phases of its virtual life. Very briefly and simply:

1) When the compiler determines a new instance should be created, it first runs the code inside <script setup>. Variables are created and initial reactive state is set.
2) The mount phase begins, when the necessary HTML structure is created inside the virtual DOM that Vue uses to control what ultimately gets rendered. The finished component is then displayed.
3) The mounted component can enter the update phase if a relevant reactive state change is detected - values are recalculated, the virtual DOM is patched, and the HTML is re‑rendered.
4) The component is unmounted because different content is rendered, navigation occurs, or the app exits.
5) The component instance ceases to exist.

Before and after each mount, update, and unmount phase, you can register a callback that Vue runs every time it reaches that point. Use the special lifecycle hooks functions onBeforeMount(), onMounted(), etc. This can be useful if, for example, you want to show a message that page initialization completed or release resources after the component is done.

Beware of two things:

Async functions are not awaited here. If needed, put await directly in <script setup>. An async function inside onBeforeMount() does not guarantee that DOM mounting starts only after it finishes.
Don’t place hook registration inside an asynchronous block (e.g., within setTimeout). As soon as <script setup> finishes synchronously, Vue loses the current component instance context, so there is nothing to attach to.

More information, including a clear diagram, can be found HERE.

Summary

This article is already quite long, even though we only skimmed the surface of most topics and didn’t start many others. I repeat my tip from the beginning - read the Vue documentation, where you’ll find much more. There is, of course, an extensive documentation for Nuxt too.

At this point, you should be armed with enough knowledge about Vue and the Nuxt framework to start building larger, more realistic apps yourself. To make them look good, in the next part of the tutorial, we’ll show how to integrate CSS with little to no effort.