I hadn't heard of RedwoodJS before but, from a quick look at their website, it seems to be a fullstack framework, server and data access layer included.
NextJS is similar to RedwoodJS in that it also provides some server functionality but it's definitely less of a fullstack framework than RedwoodJS.
In both cases, the main difference is that Vite React Boilerplate is purely a frontend template. It does not include a backend or a means for database access.
Looking at what's included, RedwoodJS is definitely the most kitted out. It has everything you need and moves the burden of configuration and setup completely over to the project maintainers.
NextJS is the opposite. It gives you demo project but you still have to setup your environment this means deleting demo files, reorganizing the folder/file structure, modifying/adding configs, adding additional dependencies, etc.
Vite React Boilerplate is in between the two in this sense. The project comes with reasonable config defaults, adds utility packages for UI like storybook, and headlessui, builds on the default package.json scripts by adding additional commands that will most likely be added later on, and includes tools for improving commits and using git hooks, etc.
Also, this starter template doesn't support SSR or SEO specific tooling like NextJS does. If that is a requirement then NextJS is probably a better fit since it's supported out of the box. Not to say it won't work with this template but it will take some setup on your part.
All in all, they all seem to fill different niches.
Got it, thanks. As I understand it, it's like Redwood (with great defaults and libs included) but only for the frontend. I think that's an important niche for sure.
In a way, yes. I actually used create-vite as a jumping off point for this project. You can think of Vite React Boilerplate more so as an extension rather than a replacement or competitor.
I personally had the experience that when using create-vite, or similar tools provided by the developers or maintainers, it felt like the template was geared towards providing a demo of said library/framework rather than being a foundation for use in production with scalability and maintainability in mind. Don't get me wrong the demos are great but I still needed a bit more to get things really going.
I would still have to add/remove dependencies, modify configs, rearrange the the folder/file structure, add additional scripts to the package.json file, etc. I still had to do quite a bit of work before I had something that I felt could be used in production and be strong in all parts of the development process from UI design to testing, from managing complex state to creating complex components. All this while also minimizing overhead and providing a nice developer experience.
