DEV Community: Daniel Roe

The virtuous circle

Daniel Roe — Tue, 03 Mar 2026 12:34:45 +0000

The virtuous circle is the most powerful pattern in developer tooling. And it's the myth of the 10x developer that makes it hard to see.

I've been thinking about this a lot recently, because of npmx.

The 10x developer

In a 1968 study, researchers found a gap between the most productive developers and the average developer. The 'best' developers were producing 10 times more output than the average.

Something about this number stuck. Many of us believe that there are 10x developers out there. We either want to be a 10x developer or we feel inadequate because we feel we aren't.

Or maybe we simply enjoy imagining our heroes as 10x developers.

After all, there are rock stars out there – both in open source and within our companies.

But I think it's unhelpful. And I think it misses the point.

Building together

There are a couple of interesting studies out there that suggest that iteration beats one-off design (at least, under time constraint), or that working in parallel produces better results than a traditional serial waterfall. And there is research to show that teams outperform individuals on complex tasks.

This doesn't refute the idea that some individuals might be 10x developers. But it does suggest that looking for individuals isn't the best approach.

We would be better off finding highly motivated teams, who are able to iterate and build together.

The virtuous circle

I started thinking about the idea for npmx late one night (I couldn't sleep, and spotted a Slack message that nerd-sniped me). I posted on Bluesky to ask for people's wishlist for https://npmjs.com – and started building npmx almost immediately. By the next day, I had an MVP.

But the real key was the response on Bluesky. Everyone wanted something. Everyone wanted to make https://npmjs.com better.

And, seeing that response, I messaged a friend.

And as we started reaching out to friends – and then to people we respected on Bluesky and elsewhere – it became clear.

This was a project where the virtuous circle would work.

What's a virtuous circle? Well, it's the positive form of a vicious circle.

In our case, the audience for https://npmx.dev are the same people who can contribute and build it. That means, if we want to improve our experience using the npm registry, we hold all the tools to make it better. The better it gets, the more we use it – and the more people who might contribute and make it better.

The great thing about this is that we aren't being driven by a corporate agenda. We're not being limited by lack of funding. npmx will continue to grow to make our lives as developers better, incrementally, in parallel – and as a team.

Where we're going

I don't think we need 10x developers to build great things. I think we need 10x teams – groups of people who care about the same problem, who iterate together, and who make each other better.

npmx is community-driven and open source, and we have open doors for anyone to contribute. If you've ever felt the pain of navigating the npm registry, you already have something to offer.

Come and build with us.

The golden thread

Daniel Roe — Wed, 14 Jan 2026 23:03:06 +0000

There is a story I read as a child, in The Book of Virtues.

It goes like this: a boy is given – by a mysterious woman – a ball of golden thread, with a single thread poking out.

He discovers that when he pulls the thread, time passes. Pull it a little, and a painful exam is over. Pull a little more – and the school year is done.

As the story unfolds, the boy's life passes faster and faster. He jumps from success to success without effort. And then waking one day, old, he realises that life has run through his fingers.

It's not too dissimilar from the more grisly fable of the butterfly struggling to get out of its chrysalis. A child helps it by tearing the chrysalis open, only to find that without the effort of fighting its way out, its lungs never fully develop and it dies.

The moral of both stories is that there is worth in what seem to be boring or painful experiences. Effort has intrinsic value.

We would be diminished if we always skipped directly to success.

Winning immediately

I certainly have spent a lot of my life looking to skip directly to success. As, probably, have we all.

It surprised me recently to discover that 'former gifted kids' report a set of similar experiences. Many had effortless success in early life. Validation from teachers, parents and others. Later on, they start to feel demotivated or aimless as life gets more complicated and 'success' feels harder to achieve.

We become failure-averse – reluctant to try new or difficult things for fear that we won't immediately achieve the success we want.

It seems that something in our psyche needs difficulty. Or, more precisely, to overcome difficulty.

Maybe by learning the feeling of persisting through difficulty to an eventual success, we become more confident to tackle new and more difficult problems.

Effort and grift

Grift, on the other hand, is diametrically opposed to effort. Almost every grift involves the promise of something for nothing.

"Spend pennies, get a guaranteed return with no risk."
"Purchase my template, and you'll have a profitable SaaS."

(Some 'fear of missing out' comes from listening to grifters. We feel we're late to the gold rush.)

This is absolutely happening in the AI space.

Sometimes it's unintentional. People are excited about what's possible. ("I built this whole app with an agent – it did it all itself!")

Sometimes it's to sell a product.

Regardless, if we listen to some of these stories, we might see AI as 'value for nothing'. Why not vibe code your way to success? Or build your network with your new LinkedIn auto-responder bot?

Of course we want to maximise our leverage. We want to get the most possible value out of the effort we put in. But we can't avoid this one truth: the value we receive is always a function of the value we contribute.

That might be anything:

the vision that brings people together
the effort of showing up daily
the genius idea (though rarely is the idea the most precious thing)
the kindness and care that makes a team work

Value isn't replaceable.

A better story

I can't but help think that we might as well tell the story of The Developer and the Golden LLM.

One day a developer meets a wizened old man in the forest.

"My name is Claude," he introduces himself. "I wish to give you this golden LLM. You can ask it any question at all and it will answer it for you. Write code, edit your tweets, evaluate your boyfriend's texts."

With joy, he receives the golden LLM. Day by day he uses it. First, a little. Then, more and more. Soon it seems that he barely touches any task without directly bringing out the golden ball.

But as the years pass, he realises he can't recall much of what he's shipped. Bugs surface that he must have introduced – but he has no memory of them. He has more followers than ever on Twitter, but he's not sure any of them actually want to hear what he has to say.

One day, he sets out to create a side project on a plane and finds himself just staring at the screen, unable to code.

In the original story, the boy chooses to go back and live his life again, but without the ball of golden thread.

For us, turning back time isn't an option.

But we can learn from the story.

How we approach these tools makes a huge difference. If we treat them as a substitute for effort, we're barely a step away from grift – and I really believe we'll wake up one day, completely hollow.

But that doesn't have to be our story. We don't have to treat AI as a zero-effort shortcut to success.

We can:

treat generated code as ephemera rather than the finished product
review every line, increasing our skillset at the same time
solve new problems and build new instincts

AI serves us as a force multiplier, augmenting our own agency and making the most of our own effort, hard work and value, not by replacing it.

Diversity, equity and inclusion

Daniel Roe — Mon, 10 Mar 2025 14:44:09 +0000

This really shouldn't need to be written:

I'm in favour of diversity, equity and inclusion.

Let me explain why.

Politics

But first, this isn't political.

By that, I mean it's not party-political. What I think and say about diversity, equity and inclusion isn't because of my political views.

Rather, I'm writing about values - core beliefs. Values are the things that should shape our politics. They should affect who we vote for and who we align ourselves with.

For that reason, I think it's dangerous when your politics starts shaping your values. That can lead to extremism and tribalism - and demonising people who vote differently. My opinion? We should talk less about politics, and more about values - even if that's dismissed as 'political'.

Hold your politics lightly but your values tightly.

Direction

In fact, I would be remiss not to speak about values.

Values shape the direction of projects and people. They also shape the culture of open source communities. They make the difference both in where we end up and what the journey there is like.

As a leader, whatever you say matters.

Even if you say nothing. Especially if you say nothing.

So here are a few reasons why diversity, equity and inclusion will be core values in any project I'm involved with.

Diversity

I can think of no better way to stop growing as a person than to be always around people who are just like me.

Being around people who are not the same as us broadens and strengthens us.

Not to mention, it's more fun.

There's also another very real way diversity is a necessity in open source.

In building any product - or open source project! - one of the most valuable skills is empathy: the ability to place yourself in the position of someone using your product.

That is true for developer tooling too. It's a bit easier because we're developers already - we're much closer to the 'user'. In a sense we can build for ourselves.

But there's diversity amongst developers. We have different needs.

If we take that seriously - if we value empathy - then the value of diversity within a team isn't controversial at all.

Sometimes diversity and capability are seen as opposite poles. And that's an insult, honestly, that I won't even bother responding to. If you think that, please take a long hard look in the mirror.

It should go without saying, but I would love to see increased diversity of backgrounds in the Nuxt team and contributors.

Equity

There's a very strong sense of fairness in open source. Projects like Nuxt are community-based. It really matters how things feel and how people are treated.

It's important to recognise that we don't all start from the same place. Making adjustments to accommodate differences isn't special treatment - it's creating a level playing field.

If people are treated badly, or unfairly, then we need to make it right. Please don't be silent about it. I've written a little bit about it.

Inclusion

I'm an outsider to the tech world, even if I'm privileged in many other ways. I know what it was to be welcomed in. I'd like that to be true for many more people too. 'Freely you have received, freely give,' are words that mean a lot to me. Plus, half of the fun of open source is in working collaboratively.

So from my point of view, open source is and should be open. Come on in! We'd love to have you. And have a chat with me if that would be helpful!

Why write this?

Nuxt, like many other projects, adheres to the Contributor Covenant. You can read our code of conduct here. We're not unique in caring about diversity, equity and inclusion.

I'm not winning any friends by writing this. People who like me already probably know where I stand on this. And those who disagree might find me overbearing.

But I think it's important to speak clearly about this for several reasons:

I want people of all backgrounds to know that you are welcome in projects I'm involved with.
'Diversity, equity and inclusion' are being rejected at government and corporate levels. In places they are banned terms. Silence in the face of this becomes implicit acceptance.
I want people to reconsider letting their values be shaped by their politics. Whatever country you live in, and whoever you vote for there, this is more important.

The strength of open source has always been its community. And the strongest communities are those where everyone can contribute their unique perspectives and talents.

I would be very glad of your thoughts on how we can better implement these values.

Zero sum games

Daniel Roe — Tue, 04 Feb 2025 11:11:47 +0000

Open source is about mutual giving. So how does that square with commercial open source? Or building a for-profit product on top of an open source project?

There are plenty of examples of projects that (at some point) push back against third-party commercialisation, whether that's MongoDB or Elasticsearch. And it's also not uncommon to see open source developers become jaded, disillusioned and bitter that the money being made using their software isn't flowing back to them.

In recent days, the most obvious example of that is Matt Mullenweg of WordPress, whose lawsuit against WP Engine seems to stem from a frustration that they are profiting from something he has built.

If I can communicate one thing on my own behalf here, it's this:

👉 Flourish! Build a company if that's your thing. Bless the people who work for you. Make money. Enjoy! No strings attached.

By default, if you are building with Nuxt, I want you to succeed.
If you are a third-party provider with a great Nuxt module or integration, I want you to succeed.
If you are creating a course to teach other developers, I want you to succeed.
If you're a consultant helping people make great, performant Nuxt sites, I want you to succeed.

... and I don't want that goodwill to be conditional on sponsorship or 'paying Nuxt back'. Nor do I care if you are 'competing' with me (or any of the Nuxt team).

Here's why I feel that way:

Open source is a community project. I can't possibly feel bitter about not getting 'what I deserve' when it's not me, but a whole group of talented and lovely people who have made it possible. In many cases - including my own - we have done so because there were no strings attached.
Compensation doesn't follow value. If I start trying to find my value in how many donations or sponsorships I get, I'll destroy my own mental health. Better to let go of that expectation. And, where I need compensation, find it by seeking it out in consultancy, entrepreneurship, retainer or employment.
Success is contagious. The more commercial projects succeed, building on top of open source work, the more the whole ecosystem benefits. Jobs are created. Conferences flourish. Educators produce articles and videos. More people contribute. More companies are created.

Someone recently wrote to me via an #ama:

Should I feel bad for trying to make a for-profit product using Nuxt ecosystem? It's unbelievable how many great free things it offers, it makes me feel kinda bad trying to use it for my own benefit

My answer is pretty simple: Don't feel bad. Build your product - and flourish!

∗ I'm speaking about my feelings, but if anyone should be 'paid back' for Nuxt it would probably be Sebastien & Alex Chopin, who created it in the first place.

Today is your day

Daniel Roe — Tue, 04 Feb 2025 11:11:44 +0000

What a year.

Reflection isn't my strong suit. I think. But I wish it were more part of my life. So I thought I'd try to piece together … part of … my story in 2024.

Oh, the places you'll go!

This year, I've attended conferences or meetups in Toronto, Prague, Seattle, Amsterdam, Glasgow, Middlesbrough, Bonn, Portlaoise, Athens, New Orleans, San Francisco, London and Edinburgh. I've also enjoyed making EdinburghJS a regular part of my life.

I've loved every moment of it. Not the places, so much as the people. The tech world is amazing - but the greatest part for me is meeting people I respect and collaborate with.

I also find that travelling can be productive. I love coding on the plane or train - it's often joyously focused - and I always notice bursts of creativity after conferences.

Next year, I'd like to widen the circle.

I'd like to see more folk I don't already know. That will mean answering CFPs at conferences further afield. Recommendations welcome 🙏

You’ll be seeing great sights!

This was the second year that I have led Nuxt. It's been exhilarating to see how things have grown.

We're rising in retention, positivity and awareness compared to other meta-frameworks. I don't claim credit for that - but it's a pleasure to be a part of the community that makes that possible.

This isn't a zero-sum game. Nuxt doesn't 'lose' when other frameworks do well. I want to see our community characterised by the kind of relentless kindness that (I firmly believe) will in the end lead to continued growth and success.

The unjs project is an example of our commitment to go further, together, and I'm delighted to see other frameworks are joining us in building on top of Nitro.

I've spent most of this year focusing on improving the stability and trustworthiness of the Nuxt ecosystem in the run-up to the release of Nuxt v4, but I do feel a bit lost in the details.

I have managed to launch a few projects, from Nuxt Fonts, unifont, page-speed.dev to smaller ones like oxc-walker, impound, errx, zero-vue, nuxt-workers or nuxt-rebundle.

Nevertheless it feels like my idea list is full to overflowing, and I would love more time to create features or launch new projects! ✨

Next year, I want to do more pioneering.

You’re off and away!

I love coding. It's fun and my hobby. I don't have an objective to be 'active' on GitHub every day. But, as it happens, I have been.

That's a side-effect of doing something that I enjoy.

the chart shows [issues, PRs, discussions and commits](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/why-are-my-contributions-not-showing-up-on-my-profile) on GitHub

I count myself incredibly fortunate to be able to make a living from being a full-time open source maintainer.

It's something I get to do rather than have to.

That's one reason I stream maintenance, building things or talking to people. You can find me on Algora, Twitch or YouTube. I think of it as 'coding with friends' and it's part of the fun.

If you've joined me on stream, sponsored me, contributed to Nuxt - or supported me in any of the many other ways people have made my life a joy this year, thank you ❤️

Next year, I want to continue to take joy in my work.

There is fun to be done!

In early 2023, arriving back from New Year holidays, I realised that I had really neglected my own health. On recommendation from Jessica Sachs and Marc Backes, I downloaded Noom, dusted off my Oura Ring and set off to look after myself a bit more.

That year I lost 15 kg - and found my way back to good health. I also discovered some things that I loved doing - like bouldering.

It's a lovely, inclusive community, and if you ever fancy joining me for a climb (even as a total beginner!) you'd be very welcome.

I've been bouldering just over a year (I started in September 2023), and in that time - mostly in 2024 - I've climbed in 35 gyms around the world. Blending physical fun and intellectual work has been a recipe for feeling like more of a whole person

I can't attribute it just to bouldering, but over these last two years, I've begun to discover the importance of looking after my own needs. Rather than living entirely in my head, I think it's important to enjoy physicality and being 'embodied'.

I don't entirely know what that will mean, but I want to continue to live in sync with what I need.

Next year, I want to continue to look after myself.

You’ll join the high fliers who soar to high heights

I was tremendously honoured this year to join the ranks of GitHub Stars. I loved joining others at GitHub Universe and meeting folk in San Francisco - which absolutely lived up to its reputation!

I was also mentioned by some of those filling out the State of JS 2024 survey. Thank you - it means a great deal. ❤️

Next year, I don't want to stop learning and growing.

Bang-ups and hang-ups can happen to you

This year has brought it's own share of pain. I don't think that's unusual, but my own griefs are dear to me - at least because they are mine.

I don't particularly want to write about them here, but for me it's important that I really feel these things, not set them aside.

Next year, I want to take time to feel the things that hurt, too.

And YOU are the one who’ll decide where to go

To finish with a few more words from the poem that's inspired the title and headings of this post:

You have brains in your head. You have feet in your shoes. You can steer yourself any direction you choose.

I'm optimistic about the future. I don't know exactly what it will hold, of course - but let's surf the chaos together. Here's to another year of joy and love, friendship and fun! 🍻

Using AI in open source

Daniel Roe — Fri, 16 Aug 2024 20:04:38 +0000

If you want to use AI to help you contribute to one of the projects I maintain, I would be delighted. But I have rules.

Here's my take: Tech gives superpowers to people.

For good or ill, technology is a force multiplier. It enables. Unlocks.

And I'm thrilled that so-called 'AI' and the careful use of LLMs might empower people to contribute to open source and help them achieve amazing things.

In fact, I'm experimenting with AI in some of the projects I maintain, using maige, dosu and more. I particularly like Copilot Workspace - I think its approach is spot-on in creating code and docs in partnership with human direction.

But I've also seen some (mostly unintentional) bad behaviour. So, on reflection, I think it's important to lay down two key ground rules:

1. Never let an LLM speak for you

If I read a comment or an email or an issue summary or a PR from you, I want to know that I'm hearing your words. I don't care about grammar or spelling - I won't think worse of you for that. I care more about real connection.

A note: AI-generated summaries of PRs are often terrible and LLMs often optimise for long-winded, dense (and inaccurate!) text that is the opposite of what I would consider well-written. Simplicity is an art. The goal is not to sound impressive, but to communicate clearly.

2. Never let an LLM think for you

Go ahead - drop the codebase in an LLM or get it to write the function or test you need. But the final step (and goal) before contributing that to an open source project should always be understanding what it's written.

Use computer aids to point you in the right direction, but always take personal responsibility. Saying, 'I'm not sure if this is helpful, but ChatGPT says ...' is always a cop out. I don't want to see quotes from an LLM in a PR or issue - I want to know what you think.

While I'm only speaking about open source contribution, I would commend these principles more generally.

If this seems difficult, or feels like it might put you off contribution, please do let me know.

And equally, if you have any ideas for using LLMs to empower contributors or maintainers in open source, I would love to hear them.

I'm optimistic about the future.

Little oak

Daniel Roe — Fri, 26 Apr 2024 15:41:44 +0000

In the very centre of the forest, on the first day of spring, a little twig poked out of the ground.

Every day he grew a little bigger.

Every day new leaves unfurled.

Before the end of the summer, he had two little branches, and he was very proud of himself.

'Look at me!' he would shout out to his mummy. And Mother Oak would tell him he was perfect.

In the autumn his leaves turned beautiful colours and then fell to the ground.

And in the winter the snow fell in great drifts on the ground, and he could see the beautiful stars and the bright moon clearly through the branches of the bigger trees.

The little oak tree was happy.

And when the spring came again, even more leaves came poking out, and he started growing even more.

Every day he grew a little bigger.

But this year there was something new. By the end of the summer he had two little brown acorns with grey caps on his branches. He loved them so much.

'Look at these!' he would shout out to his mummy. And Mother Oak would tell him the acorns were beautiful.

But when autumn came and his leaves turned red and gold and orange, and all around him the forest was beautiful with colours, the little oak tree started to feel anxious.

And when he started seeing the other trees dropping their acorns to the ground it got even worse.

Every day he held on tighter and tighter to his little acorns.

At night he was afraid they would fall to the ground.

One day he was very upset, and Mother Oak asked him what the matter was.

The little oak tree was still very small. He told his mummy why.

'You don't need to worry,' she said reassuringly. 'If you let the acorns fall to the ground, then next year you will have even more.'

And so the little oak tree let them fall, and the winter came, and then spring and summer.

And the next year the little tree grew even bigger.

And every year there were more acorns in his branches.

How I'm funded

Daniel Roe — Sun, 28 Jan 2024 21:57:29 +0000

⚠️ Update: this article was originally written in January 2024 but has been updated.

Being a full-time open source maintainer is a rare privilege. In the interests of transparency, let me explain a little more about how I am funded.

My story

I had been increasingly involved in open source - and particularly in contributing to the Nuxt ecosystem - whilst running first a creative agency and then a SaaS startup.

But when I decided (with my co-founder) to shut down the startup, Sébastien Chopin asked if he could sponsor me to work on Nuxt. I was already committed to the core team - so it didn't take me long to accept.

That enabled me to work on Nuxt full-time, and I was able to do so for several years, before NuxtLabs was acquired by Vercel in July 2025.

I also accepted a position at Vercel, where I have the privilege of working full-time as the Nuxt project lead.

I prize my independence highly and deeply appreciate the trust of Sébastien and the team at Vercel.

Sponsorship

While I don't receive any direct funding from Nuxt via GitHub Sponsors, I do have a number of individual and corporate sponsors that I value very highly.

I see open source as about 'mutual giving' and I appreciate these givers.

Their kindness is deeply appreciated. I am looking for opportunities to thank my sponsors for their generosity, and would welcome ideas 🙏

Workshops and conferences

I am sometimes asked to give paid-for workshops at conferences, and I have in past received a share of the revenue of these workshops.

In addition, conferences cover the costs of my flights and hotel and (sometimes) a speaker's fee.

If cost is ever a factor, please ask. I do not charge for community events, nor do I speak at conferences for financial reasons.

Streaming

I receive some revenue from streaming on Twitch. I do not enable ads or otherwise seek to monetise the streams.

Using shared data when generating pages

Daniel Roe — Mon, 15 Jan 2024 21:17:38 +0000

You may have loved the shared 'payload' feature when generating Nuxt 2 apps. But did you know you can do the same in Nuxt 3?

Why use a shared 'payload'?

First, what is a shared payload - and why would you want it?

Rather than running the same code over and over again (for example, for every page of a blog that fetches some data from a CMS), you can perform the step once and share the data across all the generated pages.

For example, if they are used on more than one page, you might want to extract and share data like a list of breadcrumbs, or a list of blog posts, or even the social links in the footer of your site.

As the time taken to generate static pages slows down every deploy, if you share this data across successive page prerendering, it can significantly speed up the deployment process and decrease the number of hits on your content management system.

Using a shared payload in Nuxt 2

In Nuxt 2, shared payload support was built in. You could use a shared payload as simply as this (see Nuxt 2 documentation):

~/nuxt.config.ts

import axios from 'axios'

export default {
  generate: {
    routes() {
      return axios.get('https://my-api/users').then(res => {
        return res.data.map(user => {
          return {
            route: '/users/' + user.id,
            payload: user
          }
        })
      })
    }
  }
}

This 'payload' then becomes part of the Nuxt context, accessible (for example) in your data fetching hooks:

export default {
  async asyncData ({ params, payload }) {
    if (payload) return { user: payload }
    else return { user: await fetchUser(params.id) }
  }
}

Using a shared payload in Nuxt 3

When we released Nuxt 3, we didn't document a successor to this shared payload functionality in Nuxt 2.

👉 Note that we also use the word 'payload' to refer to everything we transfer from the server to the client in Nuxt 3, so I've tried to use 'shared payload' consistently here - but be aware that if you're reading old articles it might be confusing.

We didn't directly port this feature across to Nuxt 3 for two reasons:

We want the nuxt.config to be fully serialisable. Ideally it shouldn't contain much (if any) code that couldn't fit in a normal JSON object. (And zero runtime code.) That has already unlocked future capabilities for us including the ability to have an entirely self-contained .output/ folder for Nuxt builds.
More significantly, we already support a much more powerful storage layer. It's possible with a very few steps to duplicate this functionality in a much more granular and customised way, with the shared storage layer we've built into Nitro.

Before I share an example of how you might do that yourself, I should say that there's a module to make this much easier: nuxt-prepare by Johann Schopplich. Check it out!

But if you wanted to build this yourself, here's how you might do it. This approach uses Nitro's storage layer to store data between prerendered routes, running in a Nitro server plugin:

~/server/plugins/payload.ts

const getPayload = dedupe(cache('payload', async () => ({
  todos: await $fetch('https://jsonplaceholder.typicode.com/todos'),
})))

export default defineNitroPlugin((nitroApp) => {
  // expose payload to each request if we are prerendering
  nitroApp.hooks.hook('request', async (event) => {
    event.context.payload = import.meta.prerender ? await getPayload() : {}
  })
})

// avoid duplicating calls in parallel as prerender process
// calls a number of renders at the same time, before the
//  first payload is initialised
function dedupe<T>(fn: () => Promise<T>) {
  let promise: Promise<T>
  return () => {
    return (promise ||= fn())
  }
}

// cache result in memory by default - though
// we could also cache it in data store:
// 👉 https://github.com/unjs/nitro/pull/1352
function cache<T>(key: string, fn: () => Promise<T>) {
  const data = useStorage()
  return async () => {
    let value = await data.getItem<any>(key)
    if (!value) {
      value = await fn()
      await data.setItem(key, value)
    }
    return value
  }
}

You could then use this shared payload in a Vue component (or Nuxt plugin) like this:

const event = useRequestEvent()
const { data } = await useAsyncData(async () => {
  if (import.meta.prerender) {
    return event.context.payload.todos
  }
  return await $fetch('https://jsonplaceholder.typicode.com/todos')
})

This approach uses import.meta.prerender, which allows us to tree-shake code out of our builds so you only include this payload code in your app when you are prerendering your app. (In the example above it's quite minimal, but it's worth being aware of in your own projects to optimise your bundle size.)

You can check out this full StackBlitz example - make sure to run pnpm generate to confirm that the console log only runs when the first page is prerendered.

Payload extraction

It gets even better. Nuxt turns on something called 'payload extraction' when you prerender your pages. (You can also turn it on manually even when you have a runtime server, with the experimental.payloadExtraction option.)

Without payload extraction, your data fetching composables (useFetch and useAsyncData) will rerun on client-side navigation. But with it, this data is extracted into a payload.json file which can be used instead of rerunning the composables.

If you are prerendering every route of your app, you can therefore confidently early return or throw an error which means your data fetching code can also be tree shaken out from your final app. (That's what I do in my website: see here for example.)

Next steps for prerendering optimisations

👉 In addition to nuxt-prepare, we're already talking about how to make this easier for users (and automatic!). Follow pull request #24894 for our thoughts and implementation.

Governance and abuse

Daniel Roe — Thu, 27 Jul 2023 16:10:36 +0000

Whenever you have people working together, there's potential for great things. There's also potential for harm - and sadly that's something we need to think about too.

I'm not writing this in response to a problem, but because I believe two things:

The Nuxt community should be safe for you.
If there's a problem, something should be done about it.

Nuxt governance

Before starting as framework lead, I worked on both governance documents and put a code of conduct in place.

I think the most important line in our governance document - one I care about being there - is this:

The project lead is selected by the authors and can at any point be changed if there are issues with their leadership.

That means I lead Nuxt, but only by agreement.

So if you ever have an issue with someone within Nuxt, even me, there is always a way to report and handle it that does not involve that person.

Here are some thoughts about why I think that is particularly important in open source - and a request. 🙏

A community of choice

First, an open source community is made up of people who choose to be part of it. I love that. I think this freedom of choice unlocks some wonderful things that we should rightly aspire to:

No barrier to entry. No interview to start. No necessary privileged background. No special career path. You are welcome here.
No power games. Do what inspires you, not what you have to do. Contribution to open source should not be a millstone around your neck.
Shared vision. Because we're all here by choice, to some degree we share a vision. That makes it possible to have real team spirit to forge genuine relationships around a common goal.

But it also brings some potential dangers when things go wrong:

If toxic behaviour becomes part of the ecosystem, people may choose to leave quietly. That makes it very possible for a maintainer not to know that there is an issue until far, far too late. It's even worse if a team member is the one causing issues.
There are fewer ways to enforce good behaviour. It's not a job. There's no HR department or contract with consequences if things go wrong.
Because it isn't just 'work', when things go wrong people can be affected even more deeply. Any toxic behaviour is bad, but somehow it feels more destructive when it appears inside a hobby - something that was life-giving.

So we need to be active in establishing what acceptable behaviour is - and listening out for anything that indicates we have a problem.

An appeal

As I said, I'm not writing this because of a problem with the Nuxt community. But neither is it a purely theoretical question. Because we're a community of people, we can get it wrong - and what matters is how we deal with that.

👉 So here's my appeal. If you encounter any toxic, abusive, or unkind behaviour within the Nuxt ecosystem, please let us know, even anonymously. Especially if that person is me or on the team.

You can contact any person listed in our code of conduct via their personal email address. They will investigate appropriately and keep your identity confidential (if permitted by law).

I would be very grateful.

❤️

A guide to Nuxt server components

Daniel Roe — Mon, 24 Jul 2023 20:56:33 +0000

'Server components' are becoming increasingly common in the web development ecosystem, for good reason.

Traditionally, in a single-page application, even a server-rendered one, the server is only relevant for the first load, after which the client takes over. That has meant that every part of a web app must be capable of being rendered on both client and server. Alternatively, people have opted for multi-page apps, or MPAs, with the cost this brings in user experience.

But this is not always desirable.

Instead, server components allow server-rendering individual components within your client-side apps.

It's possible to use server components within Nuxt, even if you are generating a static site. That makes it possible to build complex sites that mix dynamic components, server-rendered HTML and even static chunks of markup.

Key benefits

⚡️ Server components allow you to extract logic out of your client-side bundle.

By moving code into server components, these components (and the components they use) no longer need to by hydrated or 'tracked' by Vue. This is particularly useful for complex or expensive operations that probably don't need to be 'rerun' on the client, like applying a syntax highlighter or parsing markdown.

In most cases, using server components in your Nuxt site won't be a magic bullet. Rather, it will be a useful option when there is an disproportionate amount of code needed to render a component on the client.

🔐 Server components ensure that privileged code runs securely.

When your logic requires access to a database or needs a private key or secret, server components can be a useful solution. They are one way of separating your concerns. (Though note that other good alternatives exist, like moving your server-only code into a Nitro server route that is 'fetched' by your component.)

📦 Server components don't necessarily require a server at runtime.

By default, Nuxt will prerender any server components used in your application. As long as you've crawled every page of your site, and don't load them only on the client, or change the props at runtime, server components should work just as well on a fully static website.

This means you can use server components on static hosting - no need to update to serverless/edge rendering in order to benefit.

⚡️ Plus, if you have enabled payload extraction (which is enabled by default in generated/static sites, and can also be enabled for hybrid deployments), then Nuxt will even prefetch server components used in pages you might navigate to, so they will load instantly.

🔄 Server components are interchangeable with normal components.

Server components/islands can support all the features of normal components, including shared state, access to the current route, and more. Because they behave just like normal components, you can nest them within server components or just sprinkle them through the rest of your code.

By default, all your plugins will run when rendering server components, unless (coming soon) they are explicitly disabled by setting island: false when defining your component.

Similar but different

There are a other similar-sounding terms floating around that are worth mentioning:

React server components (or RSCs). This is an entirely different approach to rendering server components which is often linked to streaming responses from server to client.
'Island' architecture: named by Katie Sylor-Miller and popularised most recently by frameworks like îles or Astro, this is an architecture which embeds dynamic 'islands' within more static surroundings. The Nuxt approach is the opposite - we embed static 'islands' within a dynamic Nuxt app.

Using server components

So, how do you use a server component?

First, you'll need to enable the feature (which is still experimental):

~/nuxt.config.ts

export default defineNuxtConfig({
  experimental: {
    componentIslands: true,
  },
})

Then you can 'convert' a component to a server component simply by adding a .server.vue suffix. For example, here's a version of my site footer:

~/components/the-site-footer.server.vue

<script lang="ts" setup>
const links = [
  {
    name: 'GitHub',
    icon: 'i-ri:github-fill',
    link: 'https://github.com/danielroe/',
  },
  // ...
]

const year = new Date().getFullYear()
</script>

<template>
  <div>
    <footer>
      <small> &copy; 2019-{{ year }} Daniel Roe. </small>
      <ul>
        <li v-for="{ link, name, icon } in links">
          <a :href="link" rel="me">
            <span class="h-4 w-4 fill-current" :class="icon" alt="" />
            <span class="sr-only">
              {{ name }}
            </span>
          </a>
        </li>
      </ul>
    </footer>
  </div>
</template>

There's no need for any of that to be dynamic, so this is a great candidate for a server component. All I did was add the .server. suffix. I still use it in exactly the same way as before.

<template>
  <div>
    <LayoutTheSiteHeader />
    <NuxtPage />
    <LayoutTheSiteFooter />
  </div>
</template>

Case study: Nuxt Content

One interesting use-case is to create a server component that simply renders a Nuxt content page. Assuming you have @nuxt/content installed, this magical component will render any route as a server component.

~/components/static-markdown-render.server.vue

import { ContentRendererMarkdown } from '#components'

export default defineComponent({
  props: {
    path: String,
  },
  async setup(props) {
    if (import.meta.dev) {
      const { data } = await useAsyncData(() =>
        queryContent(props.path!).findOne()
      )
      return () => h(ContentRendererMarkdown, { value: data.value! })
    }
    const value = await queryContent(props.path!).findOne()
    return () => h(ContentRendererMarkdown, { value })
  },
})

I then use it like this:

<template>
  <StaticMarkdownRender path="/" />
</template>

⚠️ For now, <NuxtLink> components are not interactive, meaning you might need to add some code like this in the parent page, as a 'pretend' version of client-side routing:

import { parseURL } from 'ufo'

function handleNavigationClicks(e: MouseEvent | KeyboardEvent) {
  const anchor = (e.target as HTMLElement).closest('a')
  if (anchor) {
    const href = anchor.getAttribute('href')
    if (href) {
      e.preventDefault()
      const url = parseURL(href)
      if (!url.host || url.host === 'roe.dev') {
        return navigateTo(url.pathname)
      }

      return navigateTo(href, { external: true })
    }
  }
}

Roadmap

I plan to keep this article up-to-date as we roll out new features and update how this works. If you have any questions, please let me know and I'll do my best to cover them here.

If you're interested in following on, here are a few next steps I'm pretty excited about:

🌎 Remote sources. It will be possible soon to load server components from other websites, enabling you to create Nuxt microservices that render components which you can use in different websites. Check out this PR.
😴 'Lazy' server components. Soon it will be possible to display 'fallback' content while a server component loads to avoid blocking navigation. Check out this PR.
🏝️ Islands of interactivity. It's already possible to have interactive client slots within server components, but soon we will support arbitrary interactive components within server component HTML.
💡 ServerOnly. It might be nice to support a <ServerOnly> component that automatically converts sections of markup into server-only sections that get rendered on the server...

You can also follow the Nuxt server component roadmap in our GitHub repository.

Exploring futher

If you want to see which parts of my site are server components, try clicking this button to see what I've chosen to render as a server component - and then click around to other pages:

Show server component outlines

An open invitation

Daniel Roe — Sat, 24 Jun 2023 21:12:08 +0000

A few months ago I tweeted out an open invitation for anyone new to contributing to open source.

If you're new to contributing to open source or @nuxt_js, and want to, let me know. I'd be really happy to have an informal chat, pre-PR review, etc. ❤️

— source

When people messaged me, I sent through a link so they could book a short call at a time that worked for them.

I was honestly astounded at how many people wanted to chat. People I had never met or encountered. And even people I 'knew' from online. Some wanted to contribute but were entirely new to open source. Some had ideas they wanted the chance to implement. A couple wanted me to 'pitch' Nuxt to them.

What I learned

I had mixed feelings that so many people wanted to talk - at first. Seeing virtually every free day I had be booked for the next month was a little daunting.
Looking back at those calls, I don't regret a single one. A number of people I'd now consider valuable contributors to Nuxt messaged me - and we had a chance to talk for the first time. And I think there were plenty of folk who would be assets to any project.
I've summarised a few thoughts about contributing to Nuxt that came out of these calls.
I absolutely want to have an open-door policy in future.

An open invitation

So here's the deal. If you want to have a 10-minute chat about anything, then I would love to talk to you.

Particularly, if you want to be involved in open source and you feel you lack experience or background, please let me know. I will make time for you and I know others will too.

https://cal.com/danielroe/intro