Application requirements

[addyosmani]

After discussing it with Sebastien, we think that a Nuxt.js TMDB implementation would be complex enough to give us early signals into where some of the main gaps are hitting the Core Web Vitals when building with Vue and Nuxt.

Aspects that make this a good fit:

• It's based on an API with a good level of complexity (a TMDB client often needs to reason about multiple routes, nested components/views, data-fetching and so on)
• It's beyond a toy application - TMDB supports incorporating authentication and creating custom user data (e.g lists of favorite movies). Reasoning about the loading and chunking stories for these features will be good.
• Interesting challenges relevant to both the work done with Next.js and that will be helpful for Nuxt: e.g when should you preload the LCP image for movie posters? should you preload the API responses? For CLS, we may need to optimize via image dimensions, hero image dimensions etc. How far does critical-CSS optimization get you? etc.
• Flexibility: one of the downsides to demo applications is that we don't often need to reason too much about third-party scripts for tag management and so on. This may be fine, but we should have the flexibility to experiment if needed.
• Metrics: we will aim to optimize the current Core Web Vitals as well as FCP

What am I hoping we will be able to get out of this exercise?

• List of issues and opportunities for improvement hitting CWV out of the box with Nuxt.js
• An understanding of how feasibility it is to hit CWV with this stack (ideally a lot of the patterns we have been exploring via Next.js will translate over)
• Perhaps enough material for a case study, but at minimum an open-source application developers can take a look at will be useful for continuing discussions in public

In terms of 'what' we are aiming to build here, here is a similar implementation Anton and I worked on using Next.js.

[addyosmani]

Something we would love the Nuxt.js team's input on is the stack. I tend to use 'just' Nuxt or 'just' Vue directly when building out applications but I don't know how common it is to use, say Vuex for state management. If it's pretty common / recommended we could keep this in mind.

[danielroe]

@addyosmani I'd suggest using Vuex only if that suits the app needs (truly global, app-wide state). The Nuxt integration is pretty seamless, but I feel best practice is moving more to letting components manage their own state with swr/swrv-style data flow.

[pi0]

Nuxt has a preset of integrations from vue ecosystem like vue-router and vue-meta in addition to vue itself which are mostly required by any realistic vue app.

Vuex integration for nuxt (docs) is optional and when a store/ directory exists in project, nuxt automatically imports vuex and integrates it.

As @danielroe mentioned, global state management in vue applications can be much simpler and specially with vue@3 and CAPI, it doesn't makes sense in many cases to use. Also it has a 12.7kB/gz overhead! > See this refactor how we can make code easier and also smaller by dropping it.

[anton-karlovskiy]

@danielroe @pi0 @addyosmani

Thank you for your input.

If we used Vuex, we would load not only the Vuex package JS bundle but also unnecessary store logic that is not to be used in some pages. For example, although we do not need the store logic and Vuex on the home page, we might end up loading it, which would impact the loading performance.

Actually in the movies Next.js project, I checked that Redux package and its state management logic, which was loaded initially, impacted the loading performance. @addyosmani and I set it as an opportunity to improve the performance further.
We wanted not to use Redux entirely from the beginning but since the original project had used it a bit heavily, we planned to drop it at some later stage of the project.

Besides that, personally, I don't think we should use Vuex for data management like data fetching, adding it to the store, and treating it as a cache as we can see in many apps. I think it might introduce a lot of issues like syncing state between frontend and backend.
As well, I think it will get the store bloated, which is loaded initially, then the pages might end up loading unnecessary code.
(@danielroe @pi0 Please correct me if I'm wrong :). Thank you.)

As @danielroe suggested, I think we can use swrv for caching as we do with React Query, SWR, or Apollo Client in React.
Actually, we did not use SWR in the movies Next.js project, do we want to use swrv here @addyosmani?

FYI: From my experience with the movies Next.js project, the only global state we might need here as well is the authenticated state, which was handled by React context.

[anton-karlovskiy]

@addyosmani

For now, I'm using the same TMDB API key from our movies.zaps.dev project and have not set YouTube API key.
Could you please provide me with those keys when you get a chance?

[addyosmani]

Sure! Just to check before I re-register for keys. We want this for http://nuxt-movies.zaps.vercel.app, right?