Distribute source maps for easier debugging in Chrome's Performance tab

I want to propose the addition of a new file in the react-dom npm package called react-dom.production.js — a non-minified version of react-dom production build.

Edit: After some discussion(see below) it seems that distributing source maps makes more sense. Source maps will help you see the real function names and explore them. (The points below apply for source maps as well.)

Why?

There are a few ways to profile React’s performance — none of them provide a low-level view of what’s happening. I believe the best way to profile React is using Chrome’s Performance tab using a non-minified production build. Here’s why:

• Familiar. People use the Performance tab for every other performance profiling so they are familiar with how to use it.
• Powerful. The Performance tab is extremely powerful. Years of engineering have been put into developing it.
• Better understanding. When using the React DevTools profiler I have a common problem – I see a component being rendered slowly but I don’t know what is causing it. In order to understand I need a more low-level view. Here are some questions that can be answered only with the Chrome Performance tab:
  • What’s the balance between the app’s code and React execution times? Should I implement some frequently updated components using custom non-React implementation?
  • What time is spend on setting attribute values, setting innerHTML and adding and removing listeners?
  • What time is spent on disposing effects? Is there a specific dispose function that is taking more than usual?
  • What time is spent on mounting effects? Is there a specific effect mount that is taking more than usual?

Disadvantages

As with every solution, there are some drawbacks to using this approach:

• Documentation needed. In order to make sense of what’s happening you will need some knowledge of the core functions in React. A little guide with the names of the functions for mount/unmount, effects, and DOM manipulations will be useful. This of course can be done by the community(you are already linking to some community posts in React’s documentation).
• Requires more skill. This isn’t for everybody. It’s aimed at more experienced developers. This type of profiling is a lot more overwhelming than the current approach.
• May not fit your principles. Maybe it’s not part of your principles to introduce and promote such a complicated solution. Maybe you are more interested in searching for a more elegant and minimal solution.

[bvaughn]

Discussing it seems fine!

[astoilkov]

No. These tools show the time spent in user code. This is because (a) a lot of energy has already been put into making React as fast as we can (given constraints) and (b) it’s more feasible for people to performance-tune their own components and not React anyway.

Thanks, makes sense.

What do you think about the source maps idea? Are you open to discussing and implementing it?