-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: use Next.js for w3console #419
Comments
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. |
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
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? |
this is done https://github.com/web3-storage/console |
Per my comment in #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.
The text was updated successfully, but these errors were encountered: