@tobbe it was the silly pilot error that prevented me from editing @thedavid’s original post. Yes, I can edit it, and I am still proposing to use this alternative because it has all of the features of a good wiki (side bar with the document’s index/content), with issues to support discussing the document without interrupting the flow.
I am suggesting this purely from my desire to simplify this task - anyone please feel OK to veto it - but only after seeing what I am building there now 
Hi Redwooders,
Regarding coding in Redwood on windows, to me it is hard enough to learn a new framework and language, and don’t have time for bugs on a certain OS Windows. What I did instead, as RedwoodJS runs smooth on Ubuntu, was download and install VirtualBox for free, install Ubuntu 20.04 on a VM, and do all your coding and debugging on that Ubuntu VM *which supports snapshots etc, so you can revert back if needed, (all though, you should probably use git for that)… but still learning the git ropes. Use VScode or your prefered editor in Ubuntu. Bob’s your uncle.
Best regards, Stian
Hello @smaurstad - I believe that you misunderstood the instructions @thedavid wrote above. The information he asked for will be written for Redwood users (folks that use RedwoodJS framework to develop their applications) - not the Redwood team (core/community members).
I do not know the number of Redwood customers (aka users) that develop on the Windows platform but the mere fact that @thedavid finds the need to create better documentation for that platform suggests that it does make sense to offer them the best possible experience.
Note: the fact that most of the RedwoodJS platform team do not use the Windows platform is demonstrated by this recent discussion and it is likely that has the consequence on RedwoodJS Windows customers.
The document that @thedavid suggested to create should improve this situation a lot.
Thanks, everyone! And agreed on the point + scope of all this. Although I’m not sure if we can support all Windows experiences + cases when building an app with Redwood, we can definitely set a vision and communication what people can expect. But what do I know… I’m a Mac user ¯_(ツ)_/¯
I 
nominate @adriatic for this project. Huge help.
I’ve opened the Wiki here on Redwoodjs.com Repo to public editing. So, things could get out of hand. But it’s a bit hidden and should fit our purposes to be a temporary place for collaborative work. Once there’s a draft you all nominate as GoodEnough™, we can easily move it to a Doc on the website.
Will that work @adriatic? Please take a look and let me know.
Have any of you guys heard of http://www.colinux.org/? I used to love running that. A tiny linux kernel running in win32 land. A small distro on top and I could ssh to it and run my editor in the terminal. It’s how I developed everything for years. But then Windows switched to 64 bit and colinux died 
I’ve run virtualboxes a lot of times too, but could never get the same level of integration as I got with colinux. WSL pretty much is what colinux was so if @aldonline could get the extension working in there that would be awesome!
Hi, @thedavid - the wiki you created works just fine; you can even take a look during the day to see it in the creation 
Once I create the initial skeleton, I will invite all interested people asking them to provide their comments in the issues tool, so we all discuss and manage this document the same way as any other Redwood “object”
I have exclusively only used Redwoodjs on Windows with powershell. No additional terminal downloaded or Windows Subsystem for Linux being used.
TLDR - take a while to load everything up, but is generally smooth after it
Lets first start with hardware information.
CPU Information
RAM information
Output of Yarn rw info
Internet Speed Test
Now lets put the screenshot of timing each commands
Setting up tailwind on the project - 446 seconds ( 7.4 minutes)
Generating first page - only 13 seconds that’s awesome
Generating the page is quick but the CLI sometimes hangs when I do so. Luckily didnt hang this time
@asdethprime,
copy @thedavid
Thank you for this data - and allow me to mention that your decision to "exclusively develop Redwoodjs apps on Windows with Powershell, deprived you of a lot of world-class UX offered by VS Code. The whole reason for my document mentioned below is to prove that (strong) point 
I will integrate this into my (still under the development) article RedwoodJS applications development on Windows Platform. This article is being created as a wiki - meaning that anyone could trample it with ease, so please do not write on these pages until I officially submit this first draft to @thedavid. At that time we will decide how to save it initially and how to maintain it one the future.
I am merely a hobbiest so haven’t tried any other operating system. I will hopefully look into other OS down the line.
For my use case redwood on windows works fine. It’s the initial scaffolding that takes a long time , but given it takes me normally 2/3 weeks at least to finish working on 1 single app that delay really hasn’t been a big problem.
Though rather than changing OS or using other subsystem , I am hoping someday redwoodjs will becomes better at windows as I presume there are other hobbiest who would prefer to use it in Windows as is 
I’m guessing @asdethprime still uses VS Code to write the actual JS/TS code, right?
What shell you use has nothing to do with using VS Code or not…
Ugh, that’s horrible! Your C drive is an SSD, right? How much free space do you have on it?
Do you have a feeling for if it’s a specific part of the process that takes a really long time? Are there any other processes on your computer that takes a lot of resources in the background? (Just look at mem and cpu usage in the task manager)
Hey Tobbe (@Tobbe ), its a SSD drive 128GB.
Has 99 Gb of free space so free space is likely not the issue.
That being said it’s certainly not a high end machine; its a rather cheap laptop which I have been using for a while so perhaps that’s a reason why its much slower.
For comparision purpose, the closest comparision would be perhaps a blitz.js app which takes 419 seconds (6.9 minutes) and creating just a normal react app with CRA takes 332 seconds (5.53 minutes).
In regards to consuming resources, when I am scaffolding a redwood app, my CPU actually hits 100% for a sustained period of time vs when using CRA I am generally around 81%.
When I am using neither, CPU usage is at 17% so I don’t think its something on the background, though I will perhaps wait for someone with a better hardware to post those stats
Oh and yeah I am using VSCode powershell is just for bootstrapping app, and I tend to run CLI commands on powershell itself rather than the embedded terminal in VSCode, it tends to work faster on powershell itself.
Thanks for the update. So at least it’s not just RW that’s slow. That’s a relief for us, but doesn’t help you much…
I generally use a terminal outside of VS Code too. It’s what I’m used to and it works better for me. But you do know you can run PS inside the VS Code terminal, right?
Just so everyone is on the same page; when it comes to VS Code you can set which shell you’d like do use in settings.json (where WSL and git-cmd needs to be installed).
WSL
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\wsl.exe",
PowerShell
"terminal.integrated.shell.windows": "C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe",
cmd
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
git-cmd
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\git-cmd.exe",
Or git bash, if that’s what you want to use
git bash
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
@adriatic Some feedback on your wiki pages
Leave all platform dependency issues to standard Javascript development tools (NodeJS, NPM/Yarn) and use Redwood CLI with a choice of several native “consoles” (CMD.EXE, cmder, Windows Terminal)
I think there might be some confusion here, so let’s first start by defining a couple of terms.
terminal = text input/output environment
shell = command line interpreter
So in general you’d use a terminal to interact with a shell. So a shell runs inside your terminal. Using the terminal you can instruct the shell to launch some other program, and so you’d interact with that program for awhile (like yarn, or prisma), until it exits back out to the shell again.
Some terminals let you interact with different shells, and some terminals only work with a specific shell.
Some examples of terminals:
Cmder
ConEmu
Windows Terminal
Some examples of shells:
Cmd
PowerShell
git-bash
To make it more confusing, Cmd is both a terminal (the “Command Prompt”) and a shell. git-bash is also both a terminal (git-bash.exe) and a shell (git\bin\bash.exe). And PowerShell is also both a terminal (that only runs one shell) and a shell.
So we can’t tell people to use (or not to use) a terminal that can host multiple shells without also specifying what shell we mean. So we can’t say “Cmder has problems with using single quotes”. We’d have to say “Cmder, hosting Cmd, has problems with single quotes”. Because if you’re running git-bash inside Cmder it works perfectly fine with single quotes.
In addition to NodeJS, NPM/Yarn, use VSCode as your principal tool. This way you do not need to depend on any text editor nor console, and you could use the identical tools set on all three platforms.
VS Code doesn’t call it a “console” (at least not with my locale). It calls it a terminal. And the VS Code terminal can host different shells. So again, if we want to recommend people to use the VS Code integrated terminal, we need to specify what shell to use as well.
Even more, your VSCode created application can be debugged on other supported platforms - a feature that no other approach will facilitate, not even WSL/WSL2.
What text editor or IDE I use does not influence how well my RW app can be debugged on other platforms. And the same goes for WSL. Using/not using WSL does not in any way change how any RW app can be debugged on other platforms.
RedwoodJS CLI a
command line interfacebased tool designed to generate (build) new Redwood applications from scratch.
I think the CLI is designed to work equally well with existing or old RW apps. It’s not just for creating new apps from scratch.
At the moment, there is a couple of issues, that speaks in favor of using yarn dependency management tool instead of npm
- it is a package manager that doubles down as a project manager, handling the smallest one-shot projects as well as enterprise sizes monorepos.
- it is free regardless of the set of features is supports
Meta:
Not sure whether the above issues qualify as advantages over npm, perhaps npm’s issue with the ‘create’ argument that require the syntax "npm create_newapp instead of npm create 'new-app is a better reason
I don’t think we need to even mention npm. IMHO it only adds to the confusion. And I don’t think npx create-redwood-app my-app is any better or worse than yarn create redwood-app my-app.
Thanks, Tobbe, for your fast response with great comments - the section
So we can’t tell people to use (or not to use) a terminal that can host multiple shells without also specifying what shell we mean. So we can’t say “Cmder has problems with using single quotes”. We’d have to say “Cmder, hosting Cmd, has problems with single quotes”. Because if you’re running git-bash inside Cmder it works perfectly fine with single quotes.
Incidentally, you fetched the text that I am typing in just know, so it is least vetted (by me, by re-reading them). That is not to say that I would catch all places you pointed out.
Since wiki content is not fully git-supported, I cannot ask you to create a PR 
- meaning that I will be responsible for manually merging your suggestions. This will not be too tough as I do not expect feedback from 25 people.
I kept both terms specifying that in this document both terms are used interchangeably. I know that many Unix users like console, and Windows user prefer terminal. Since we are trying to behave in a “platform independent” way, I wanted to keep them both. If more folks lean your way, it is a problem that is easy to fix
In order to avoid the confusion
I am recommending just two tools Windows Terminal and VSCode. This eliminates any user run console configuration problems, as both these tools come integrated.
That has yet to be written in mu document
Again, Windows Terminal is just that, a terminal. You need to specify what shell you mean as well. The shell is much more involved in how stuff works than the terminal.
Hi, @Tobbe
I will respectfully disagree, with a tiny bit of disappointment that you felt the need to say (quote below):
after you rightfully corrected me above.
So for the record, Windows Terminal is not “just a terminal”, but rather a brand new desktop application with built-in multiple shells, that are selectable via a tabbed interface (see below):
My point is that going forward, developing RedwooJS applications on windows can be done either using this Windows Terminal or VSCode, which give you access to all different shells without the risk of misconfiguration issues.
Remember, this document is intended to advise our customers how to develop on Windows, without having to use old methods. Naturally, we are only advising - so anyone who is not to be advised, will have access to the last section of this document that will list all known “tricks” from the past.
Hope that this resolves the issues related to the terminal versus shell confusion. Anyone with a different opinion, please pitch in.
