…continuing conversation from Had issues with Win10…
cc: @Tobbe @smenroll @jeliasson
Note: this is an editable Wiki post. Please help me turn this into a set of Polls we can open to the community for feedback.
Each header below represents a specific poll with the list of items to be included. I’m attempting to group logically and include all relevant options. The intent is that each poll would be single-choice. Open to ideas and feedback. Edit and comment away
Overall Satisfaction with Performance*
*specific to developing Redwood on my Windows system + setup
Note: I think I’ll be able to pull the raw data so we can look at correlations between “satisfaction” and system/shell/etc. Even if not, we’ll get some initial feedback that could inform next steps (perhaps even another, improved survey).
I have the following system information
- Node Version (
node -v, e.g.
- Windows version (
systeminfo and locate
OS Version, e.g.
I have performance issues when running the following shells
[ ] Cmd
[ ] PowerShell
[ ] Git Bash
[ ] WSL1
[ ] WSL2
I have performance issues on the following development setup
[ ] Having both Redwood and Nodejs runtime on Windows
[ ] Having both Redwood and Nodejs runtime in WSL
[ ] Having Redwood on Windows, but Nodejs runtime in WSL
I have performance issues when using the following physical storage media
[ ] Local HDD
[ ] Local SSD
[ ] Local nVME
[ ] Remote NAS
[ ] Remote SAN
Remote storage access (if applicable)
I have performance issues when running the project remotely over the following protocols
[ ] Over SSH (e.g. VSCode’s Remote SSH)
[ ] Over CIFS/SMB (e.g. A “Windows share”)
[ ] Over NFS
Windows 10 is kind of like MacOS X, and the build version is like “Snow Leopard”, “Yosemite”, “El Capitan” etc.
Any new big feature in Windows 10 is going to be released as a new “build version”, while smaller improvements/fixes just goes out as a “windows update”.
Windows Terminal is just the terminal emulator (like Terminal, iTerm2, xterm on MacOS). It shouldn’t matter what terminal you’re using, but you never know…
But it’s not a shell, so it shouldn’t be in this list
If it’s a proper dual boot, and you’re in e.g. Linux, it’s not Windows Performance any more, then it’s Linux performance Or did I misunderstand what you meant by dual boot?
I concur with @Tobbe’s replies. Wiki post updated with some clarifications. The terminology might be unfamiliar to some, but hopefully the data points will allow us to identify the underlying setups and remove those bottlenecks
I have exclusively used Redwoodjs on Windows ( powershell as the command line interface) and I do generally run into problems.
2 most recurring ones are:
CLI generators seem to take a lot of time to complete, like a minute or two. What is odd is normally the files are created pretty prompty but CLI generators don’t return.
Say for example I was generating a page called contact and run
yarn rw g page contact; the cli tool will not return for couple of minutes. When I however check my VScode I can see the contact folder has already been created and all 3 files are already written to disk. The cli return however take few more minutes after it.
Saving file on VSCode takes few minutes. VSCode spends few minutes just looking for the correct formatter (eg eslint) and while that is happening the file isn’t saved. I do get the option to just cancel that and move on.
Also I have noticed auto-complete for prisma is not available on windows, I am unsure if that is different on say linux. When I create an new project using prisma only, and not including redwoodjs, all the auto-complete feature are present but with redwoodjs I dont get the auto-complete for prisma.
Thank you for offering your experience @asdethprime Not ideal at all.
This conversation has picked up over here along with some potential next steps: Windows Dev and Setup: Recommendations and Best Practices [Collaborative Wiki]
Could you take a look and chime in if/when you are available?