proposal: use Next.js for w3console

[travis]

Per my comment in https://github.com/web3-storage/w3ui/pull/417 we should consider moving to Next.js which provides a more full-featured toolkit for building complicated webapps.

We've already started adding features like routing and may want to add SSR and other more advanced "Progressive Web App" features soon - I'd rather use a toolkit that gives us all those things out of the box if we can.

IIRC the original reason we used preact + vite was to serve as framework-agnostic example of how to use our tools. While I think this is still a good goal, this is now in tension with our desire to build a performant, scalable web frontend for w3up so it's probably time to re-examine.

One potential compromise between these two desires would be to copy the example w3console into its own repository or make it a package and swap out the framework there - we'd still have a good example of how to use w3ui to build an app, and would be able to evolve our "production" frontend separately.

[olizilla]

I'm a big +1 on moving it out to it's own repo. I need some convincing on changing the build tooling unless there are specific problems they are causing. Perhaps split this issue in two, and go ahead and get w3console into it's own repo.

[travis]

ok @olizilla - I moved the proposal to use a separate repo to https://github.com/web3-storage/w3ui/issues/561 so we can talk about that there. I'll make the case for Next.js below!

[travis]

I need some convincing on changing the build tooling unless there are specific problems they are causing

Makes sense! I think #417 is a good example of some of the problems we're running into with the current setup - in order to add new pages we had to hand-roll react-router-dom in the top level app.tsx. This means that we need to either roll our own routing logic that scans the filesystem OR be sure to add new routes every time we introduce a new page, and similarly introduces a need to understand the routing code to figure out where page rendering logic lives. Additionally:

• it means that it would be hard to get good support for code-splitting, since proper code-splitting needs to be router-aware and Vite (which would need to do the code splitting) does not know about react-dom-router. We could probably figure out how to configure it to do so, but I'd rather just go with the tried and true solution baked into Next.js.
• it means we need to start using react-router-dom's Link implementation everywhere in order to avoid reloading the page when a user clicks a link, and imho the syntax and implementation of that is not as good as Next.js's Link
• integration with React's new Suspense primitive would be much more difficult, which means our loading UI will likely be strictly worse (https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming)
• we'd need to roll our own localization support (https://nextjs.org/docs/app/building-your-application/routing/internationalization)
• we'd need to roll our own support for Layouts (new versions of Next.js have a very nice Layout system https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts)

Backing up a little, comparing Vite and Next.js is a little "apples and oranges" - Vite is a build and development tool, while Next.js is a full-featured application development framework (Vite doesn't even try to compare itself with Next.js, I think for this reason https://vitejs.dev/guide/comparisons.html) so the real question here is:

Should we use an application development framework for w3console or should we roll our own?

imho there's very little advantage to rolling our own, and a number of disadvantages. Next's documentation lays these out pretty well:

https://nextjs.org/docs/app/building-your-application/upgrading/from-vite

Slow pages loads and the lack of automatic code splitting are two of the biggest things, imho, but "Choose the data fetching strategy" is also pretty huge for a site that I expect will come to include marketing content - being able to configure caching and server-vs-client render on a page-by-page basis are, in my experience, extremely helpful when trying to get acceptable Core Web Vitals.

Stepping back again, I know what you are looking for is specific pain points - beyond the routing complexity in #417 there admittedly aren't many - I think this is mostly because we have not been actively developing w3console recently and it has until now been a very simple single-page-app. imho Vite + react-router-dom is simply not a good choice for anything that needs more than a couple single SPA-style pages, but the pain doesn't really show up until the app gets larger and you start trying to optimize Core Web Vitals.

Rather than thinking of this as "do we need to switch to Next.js?" I'm thinking of this more like "we're building a new app, what's the right approach?" and for a number of reasons - some listed above, some left out, and some just being "that's what my gut tells me" - I think Next.js is the right tool for the job.

Thoughts?

[travis]

this is done https://github.com/web3-storage/console