It does show a little of React's dark side though. It's worth asking... Why would Slack need to debug into their view rendering library on customer machines? It's not their code that's made accessible here, it's React's.

React introduces a layer of indirection into your rendering. Rather than saying "draw a profile pic" and then "a profile pic means these DOM manipulations", with React you add another layer: "hey, oracle, what does the whole page look like this now, and what DOM manipulations should we do to get there?"

It's like having an AI look at your code and decide how it should actually run. Very cool, very futuristic. Not convinced it's a practical decision.

Putting something like that in your app means for a much more complex debugging process. It always seemed like the React team was trying to solve a really really hard problem in order to avoid solving an easier problem a bunch of times. Which is classic programmer thinking, and generally a good strategy. But I wonder if it's good for us in the end.

The principle you could adopt, which would make React a bad choice, is something like "solve one hard problem if it means you can avoid solving a lot of easy problems, but only if you're solving those actual small problems in bulk. If you're only solving a subset of them, you're going to cause problems for yourself later."

Which DOM queries and manipulations make sense? Is React actually answering that question for you, or is it mashing the buttons until it works?

I think you are overthinking the meaning of this. As engineers we tend to blame complex layers we didn't write, especially if we don't have insight into them..

Giving their engineers the option to peer into react whenever they like is probably getting them more pure slack bugs fixed. That is not to say I think the current slack resource use is acceptable. There should be a middle ground where most users aren't wasting resources all of the time.

How is this absurd? I've had problems debugging minified Javascript in production too. So from my point of view, this seems like an appropriate response.

There are ways to debug minified JS in production, sourcemaps being one of them.

In addition to the speed difference, there's a significant payload size difference: something like 1.5+MB for the dev build, vs 70kb for the production build, last time I checked.

Sourcemaps have the drawback that you actually need to generate them first. Sometimes, getting all of the tooling together is teedious.

And about the size: if the JS file is cached properly, downloading 1.5mb once doesn't seem like a huge issue, especially for something like Slack where only desktops use the web client (most mobiles probably download the Slack app). I don't know if this was the case here though.

They've retracted this tweet, now believe they were not using Dev at all.