Hi @adriatic This feedback is absolutely welcome! And I want to make it clear that the interest you’re getting on this thread from many on the Core Team is based on the fact is valuable. We want to make things better, but we often are blind to system-specific experiences unless individuals join the conversation and submit feedback. So, that said, thank you! And as much help + leadership you’d like to offer, it’s all welcome here (no pressure of course).
Things we can’t control
There are concerns here that are ultimately outside our control:
- The state of the industry, aka NPM packages are a (powerful) beast
- Network speeds
- Windows + Node
Someday, I predict, most package handling will switch to Plug and Play. Until then, we’re stuck with managing node_modules and all that comes with it. To be clear, NPM has been a boon. There’s a downside to every upside.
Windows performance issues have been around for Redwood since the beginning. Tobbe has led the effort and improvement to (no exaggeration) probably 1000x performance for Redwood on Windows. But we’re not done. And some efforts (like mine that stalled out) still need to be done.
For anyone reading this and finding themselves concerned that all these numbers above regarding the development framework will correlate with the negative performance of deployed applications — that is not the case. It’s actually the opposite. All the “tools” included in the development framework are being used to enhance, compile, organize, minimize, etc. for an improved end-user experience regarding deployed apps.
This is more like downloading an Editor or IDE to build an application – it’s the tooling you need to build the thing.
Things we can control
Identifying and Optimizing for a Windows "Setup"
@Tobbe we’ve talked before about creating a doc that recommends Windows tools, shell, setup, etc. for developing with Redwood. Maybe it’s time to start making that list, which would also allow us to focus an effort toward monitoring and optimizing.
CI Metrics
Next.js has a lot of CI stats, available with every PR, that monitor applicable stats like build size, build time, etc. Because we can run CI on both Linux and Windows environments, this could be an opportunity to set some benchmarks.
Local Analytics
We have discussed using tools like Telemetry to start gathering analytics like this. Maybe it’s time to prioritize, especially as we get close to v1 release.
I know I’ve talked to Aldo about this. @danny did you and I discuss this as well?
What did I miss?
How do people feel about where this fits amongst all priorities?
What other actionable ideas do you all see here?