These 80 seconds are my whole time spent with Redwood, so to help my positioning I would appreciate what other Redwood developers think: is it fast, or slow, or not yet ready to be measured. Note: most of that time was spent running yarn install - and based on that I find it very slow, without understanding why. I am using yarn for years and this is the longest install I can recall
Hey @adriatic sorry to hear that, that’s definitely not what we want the first 80 seconds of redwood to be like. Unfortunately your experience isn’t unusual. I think @Tobbe has waited multiple minutes before. @Tobbe dare I say five minutes plus? I know he’s timed it. He’s on windows by the way, and that seems to affect some things based on my own experience as well. I used to run ubuntu on an old thinkpad and would just checkout while installing a new app, but upgraded to a mac recently and now the install just flies.
In terms of is it fast, slow, or not ready to be measured, I’d say it’s definitely slower than it should be, but also by design since we haven’t deliberately worked on it.
Revisiting the GitHub issues now, most of them are about yarn rw dev and the like.
Work to be done all around for sure!
It’s all relative based on the underlying frameworks and libraries. Using create-nuxt-app can take a few minutes, whereas something like ElderJS which uses Svelte takes 2 seconds. I think Redwood is on par with most projects in the React and Vue ecosystem.
Thank you @dom and @ajcwebdev for sharing your opinions. I find the ideas behind Redwood very attractive (mostly from reading a few blogs from your founder, who is very smart and very eloquent; having started a few companies in Silicon Valley myself, I know how important it is to be smart and eloquent). So my attitude is certainly positive and having experience with many other tools and frameworks in the Javascript world, thought that pointing out some potential weaknesses would help. Please do take it in such way.
A couple more data points:
- after creating the app, I was curious to find out how long will it take to delete the app (on Windows 10, using the file manager). I was surprised to see that the app was 500 MB in size and that it took twice as long to delete it than to create it.
- after deleting the app, the second create took half the time of the first creation. This ought to be due to caching on several levels
I plan to have a detailed view of the whole Redwood environment and share my impression - assuming that by doing that I am contributing at least a little (and yes, my plan includes contributions in a more open-source style as well
2 Likes
We’re all about improving Redwood and the snappier the dev experience the better, so we certainly appreciate the feedback and any tips!
I was on a stream the other day and they were able to generate a Redwood app in 30 seconds which kind of blew my mind cause I’ve never seen it go that fast. I’m on a 2014 Macbook and it usually takes longer than 79 seconds for me, so I think it would be good to get a bunch of metrics from people using different machines.
1 Like
Just ran on a 2019 MacBook Pro:
✨ Done in 50.41s.
Deleting via
rm -r timed-test
Took ~ 8 seconds
Second install took
✨ Done in 41.23s.
Deleting that via
rm -r timed-test
Took ~ 8 seconds
Dell XPS 9550 16 GB Ram (2017) Windows 10
Delete
Installation times is going to fluctuate depending on your internet connection speed as well.
Yes, it’s definitely been very bad. But it has gotten a lot better as you can see from the numbers above. I think a lot of that has to do with my Internet connection being much faster and much more stable now.
Hi @thedavid
I would be hard-pressed to create a better response to my few measurements than you just did 
(at some point in the future I will tell you how I was in a very similar position you are in now, just 25 years ago).
More seriously, I do believe that I can help you in more than one way and am very happy to see how much you care about performance as well.
In my experience, good (or better) developers have a very strong aversion to Windows, regardless of the fact that in your case one can hardly “see” windows in the JamStack environment)
Gigabit connection is still rare and it spoils you. My connection is 150 Mbits and that is a lot more often the speed your customer normally encounters.
1 Like
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?
1 Like
This question might be in the weeds, but how did you delete the App? E.g. on Mac I’m normally on CLI using rm -rf ...
Asking because I’m assuming it’s details like this that could go a long way to making a great “Developing Redwood on Windows” guide.
I’m on a 2017 iMac Pro (3.2GHz, 8 core, 32GB RAM) and yarn create redwood-app was 36.86 seconds, the vast majority in the Running 'yarn install'... step.
Then a delete:
rob$ time rm -rf prisma_test/
real 0m10.550s
user 0m0.146s
sys 0m8.917s
Then another yarn create redwood-app, and that one took 27.17 seconds.
The trend here I’m seeing is that we Mac users aren’t feeling the pain of Windows users…
1 Like
Like you said @thedavid this is also very dependent on your internet connection. Downloading 500MB of libraries from npm is gonna be painful for those with slower internet. I’ve got Gigabit which helps a lot in my install time.
But there’s not much we can do to speed up yarn or npm…
@thedavid I used the same method (rm -rf …) on windows. The underlying API uses different code, but I am pretty sure that it functionally equivalent and performs similarly.
In my last 6 years history of open source development I used probably all JavaScript frameworks and tool. The most recent affection for JamStack led me to Redwood, and I decided to look it from a lot closer distance than I expected initially. Part of this decision comes from this face:
The brilliant acting being surprised by the camera warrants at least a Golden Globe
4 Likes
Thank you, thank you! The intros get wackier in parts 2, 3 and 4!
1 Like
In order to make this discussion a bit more “orderly”, I will create the RealWorld app and share the all performance information with you, leaving the decision whether you want to add this data to the Real World collection before or after you tun it up 
3 Likes
Thank you! Helpful.
Part of this decision comes from this face … The brilliant acting being surprised by the camera warrants at least a Golden Globe
Ha! Be careful what you encourage. We do 
our TutorialMaster9000™
Lastly, you can thank me later for this 
1 Like
Looking at those of my coworkers who are not Mac users I see two patterns: Delete windows and go Linux, or run Linux inside Windows using WSL2. Assuming we don’t want to tell people to switch OSes the obvious option would be to recommend WSL2. But there are a couple of reasons I’m not doing that.
- I haven’t tried it myself (because of hardware limitations on my current computer)
- The RW VSCode plugin doesn’t work on WSL2 (or WSL1)
I definitely see a lot of potential and value in adding more Github actions. Especially more complete testing. I had fun writing the PR build script and could definitely see myself doing more work like that. I don’t know, but I’m assuming the Github actions run on shared server instances, which might make performance test fluctuate depending on what other loads run on that same server instance.
Maybe I’ve become complacent, but for me the performance is good enough for a v1 release. But of course, anyone who wants to come in and take lead on improving performance should 100% be encouraged to do so!
2 Likes
Tobbe, I believe that we see things the same way (at least in the context of our current discussion). I also agree that the platform use amongst the team should be defined in the form of a company document as @thedavid suggests.
You certainly do not want to force your team members to switch the OS for the benefit of the company as it very quickly evolves into a problem (that rule should be applied to the current (as different from the future) team. You can however offer a couple of powerful Linux machines that present something similar to the Digital Ocean interface to the developers using Windows machines. I am doing this for years and am very happy with such “distributed development”.
I wrote my first message with a pretty firm impression that the Windows performance is sufficiently worse than other JamStack platforms, to turn first visitors off. So, without suggesting that you are indeed complacent, I would like to help in any way I can.
Disclaimer: I am not interested in getting a job although if I were a lot younger, Redwood as described in several documents written by @mojombo would rank very high on my list of very interesting projects 
. With this in mind, just think about me as someone who wants to help Redwood project to be as successful as possible,
Attempting to keep some momentum from this conversation over here: