Thoughts on Nuxt.js alternatives

[zackkrida]

While I was on parental leave I took a cursory look at some potential paths away from using Nuxt.js. Let me provide some background on why I think that might be a good idea, but feel free to jump straight into alternatives.

My subjective feelings on Nuxt's place in the JS ecosystem

I feel like Nuxt occupies a challenging slice of the JavaScript ecosystem that makes it difficult to work with. It's the "biggest fish in a small pond", meaning that it's the largest framework in the small Vue ecosystem. It's React's Next.js without the VC funding, large developer base, and community. It tries to be all things to all users and ends up not being the best choice for any use case.

Nuxt's GitHub activity for the last month

Next's GitHub activity for the last month

This applies doubly to libraries in the Nuxt ecosystem. Often key, integral parts of a "meta" framework like Nuxt are left to community-managed plugins and libraries. These libraries are typically coupled to specific versions of the core framework and extend them, meaning they need to be developed tightly alongside the core framework for compatibility and kept up to date with any 3rd party dependencies. Examples of this type of code in our project are:

• @pinia/nuxt
• @nuxtjs/i18n
• @nuxtjs/sentry
• @nuxtjs/storybook

to name a few. These libraries are often maintained by very small teams or even solo developers, which can also pose challenges like slow updates.

How to avoid this ecosystem problem

I see two possible solutions to breaking out of this slice of the JS ecosystem:

• Use a framework that isn't Vue.js-specific
• Use a framework with the smallest possible API surface as "close to the metal" as possible

There are two tools I've encountered that match one or more of these goals:

Astro

• Use a framework that isn't Vue.js-specific

Vike

• Use a framework that isn't Vue.js-specific
• Use a framework with the smallest possible API surface as "close to the metal" as possible

Let me explain each of those a bit.

Astro

Astro's GitHub activity for the last month

Astro is a "UI Library" (they mean React, Svelte, Vue, Solid, Lit, HTMX, and so on) agnostic web framework that includes SSR and data fetching functionality comparable to that of Nuxt. In theory it should be able to do everything we use Nuxt for and more, while being decoupled from Vue.js and it's ecosystem directly.

Vike

Vike, formerly Vite-plugin-ssr, is a lightweight Vite plugin that is also UI Library agnostic. It's essentially a smaller, more bare-bones astro that tries to be intentionally manually configured and "more work" so that it is subsequently less intrusive and burdensome.

---

I don't have time to go into depth on these frameworks yet, but wanted to share them early to outline my thinking. In general, migrating to either of these is likely to be time-consuming, error-prone, and full of "unknown unknowns", but then so has the migration to Nuxt 3 😆.

What do you think, @WordPress/openverse-frontend?

[dhruvkb]

Nuxt is undoubtedly a huge framework that's trying to do everything for everyone but in a small community that's basically the only way to ensure that the project has a sustainably large "tent". There have been smaller projects like îles or Gridsome that have materialised but are now not actively maintained. Nuxt also lacks backing of large teams like Vercel. I don't agree that Nuxt "ends up not being the best choice for any use case" because if your use case is a large, multi-page Vue site with SSR, Nuxt is the best you have 😉.

That said I have also had a conversation about our lock-in with Nuxt with @sarayourfriend and I agree that Nuxt moves very slowly and we usually do not get to make use of faster, smaller updates across the Vue ecosystem that would be possible were we not locked into Nuxt.

Astro

I have used Astro a little bit and while it's very enjoyable to work with, I have some minor complaints.

• Some parts of the framework have to use .astro components. It is not possible to use Vue in all places so it's one more framework to learn.
• TypeScript is a bit challenging to implement because it needs to process two different types of SFC's (Astro and Vue).
• I also encountered similar overlap+conflict issues with other linting and formatting tools like ESLint and Prettier.

---

Overall I do not think that we should be deciding a framework based on how decoupled it is from Vue as it is not realistic for us as a resource-constrained team to port the entire frontend into a different UI framework. Even upgrading to Nuxt 3 was considerable effort that was difficult to parallelise and spread across multiple developers, so I could see switching to a new framework would be a massive year-long project.

[sarayourfriend]

TIL that Astro has full SSR capabilities. I didn't know that, very cool.

I 100% agree with Dhruv that we should not try to move away from Vue. Vue is not the problem here, and like Dhruv said, we don't have the resources to re-rewrite the application from scratch (which, if we did, I think we could broaden the options, or maybe choose some more traditional ones like Django templates).

I need to think about this a bit. The things I want to think about are:

1. Is Nuxt 3 really to be avoided, so much so that an entirely different meta-framework is a good idea for us?
2. If Nuxt 3 is not an absolute "NO" from us, and given other options potentially make sense, is the effort of e.g., re-writing the application for Nuxt 3 vs for some other meta-framework comparable?

Something I am extremely keen to discuss is whether our approach to upgrading to Nuxt 3 can be modified. I shared these thoughts with @obulat when she was in the midst of things in January with the attempted Nuxt 3 upgrade. The update was in a strange and complex space, and I suggested to Olga that the following questions were worth considering:

1. Is upgrading the application "in-place" the best approach? Would it be better to start a new Nuxt 3 project in a separate directory (e.g., packages/frontend) and port over individual pages one by one?
2. What is the cut-off at which point Nuxt in general no longer makes sense? How do we measure this against the implicit mega-project that it would be to move to something else?
3. Are there things about how we leverage Nuxt that make our usage of it particularly difficult? We have no shortage of spaghetti in our frontend codebase (api-service, and heavy usage of JavaScript-based UI breakpoints especially) that comes from needlessly avoiding Nuxt modules/plugins framework or other problematic architectural decisions. Can changing some of these things make it easier to transition, either to Nuxt 3 or some other framework?
   • A good example here is actually @openverse/api-client. It can fully replace api-service and is completely isolated from our application, to the point that the Nuxt plugin for it is trivially simple.
   • Are there other parts of our application (e.g. data stores) that could be abstracted in this way, such that any Vue-based framework could use them without heavy integration into Nuxt or an Nuxt version specifically?
   • Sentry may be another good example; is it possible for us to write a custom Nuxt plugin that simplifies the integration (for our specific needs) and avoids the complexity of a new potentially Nuxt version-specific dependency?
   • Again, for i18n, do we need the community Nuxt plugin, vs using standard Vue i18n tools directly, with a custom wrapper to achieve what we need in Nuxt?
   • These are things we can work on independent of Nuxt or any other meta-framework, by isolating our usage of these complex and deeply-integrated dependencies. It would make any transition, whether to future Nuxt versions or another meta-framework much simpler.

I need to think more about the options you've shared, Zack, but I also think we are missing something important if we don't ask why our application is so hard to upgrade, and whether focusing on that, at least for a bit, rather than significant new frontend features, puts us in a better position for long-term flexibility regardless of whatever meta-framework we use to render our Vue components.

[zackkrida]

From @dhruvkb:

Overall I do not think that we should be deciding a framework based on how decoupled it is from Vue as it is not realistic for us as a resource-constrained team to port the entire frontend into a different UI framework.

To clarify a bit, I also 10000% agree we shouldn't switch away from Vue. The reason to consider a framework like Astro is that it is a way of benefiting from the size and resources of other frontend framework ecosystems (React in particular) while continuing to use Vue and our wonderful existing components.

That said, I think "should we switch meta frameworks" is a small part of our overall 2024 frontend strategy and only one possible avenue. Much of what @sarayourfriend said resonates with me deeply. I think the whole conversation is summarised quite well by this point:

These are things we can work on independent of Nuxt or any other meta-framework, by isolating our usage of these complex and deeply-integrated dependencies. It would make any transition, whether to future Nuxt versions or another meta-framework much simpler.

Generally I think some sort of frontend audit, to identify "pain points", oddities, and inconveniences with the frontend codebase (as opposed to the UI), could be an ideal next step.

[sarayourfriend]

Generally I think some sort of frontend audit, to identify "pain points", oddities, and inconveniences with the frontend codebase (as opposed to the UI), could be an ideal next step.

Agreed.

[sarayourfriend]

I'm marking this as the answer and closing the discussion, if that's okay @zackkrida. I'm not sure if you intended or wanted issues to be created out of this, but for the time being we've got a plan for #411 that we'll stick to, and we can revisit pain points and such later on?