loganfsmyth

(Replay engineer here): We don't currently support inspecting network requests, but that is something we plan to support in the future.

> What's the timeline on Windows support?

Work on Windows support in ongoing now and we're hoping to have at least an initial beta Windows release some time in the next month or two ideally, though it certainly depends on if anything unexpected comes up.

(Replay engineer here):

> What are the limits for the recordings in terms of time and input data size?

The best answer right now is that it varies a lot depending on overall CPU usage, the amount of memory used, and the length, so it's somewhat difficult to nail down. Right now we recommend less than 2 minutes long as an attempt to keep things reasonable, but if it's 2 minutes at full CPU usage it may still not load.

> on Ubuntu 18.04 I get the following error:

For the Glibc error, I'll ask around but not sure off the top of my head.

(Replay employee here): We have experimental support for some react-specific features using react-devtools since React is such a common framework, but the Replay is a general debugging tool and will work with other frameworks well too.

Once a recording is made, you can jump around in it as much as you like. The network requests will only be made during the initial recording process as they would normally, and when debugging it will all be pulling the request/response data from the recording itself rather than querying the network.

Very excited to see what folks here think. Replay has been a wonderful project to work on so far.

Babel on its own only addresses syntactic functionality and wouldn't cover this, but it is indeed extremely easily to polyfill `classList`.

That doesn't appear to replace variable names with shorter versions, or remove dead code, which Uglify and other minifiers do.

I totally agree that the initial user experience for Babel could use some work. We don't tend to do a great job of guiding users through initial setup. It absolutely needs work. I'd be curious to hear the author's thoughts on what we can do better in that respect, since "no config" probably isn't going to happen off the bat.

On the other hand, I don't feel that it's reasonable to assume that setting up a build system will be trivial. Jumping into ES6 isn't and shouldn't be a trivial decision, transpilation is a complex process with edge cases. That doesn't mean it should be a pain in the ass, and I don't want it to be, but it doesn't mean it will be instantaneous and easy. Users have totally different build targets (different Node versions, different browsers, some need IE8 support, some don't). Different systems need different levels of polyfilling and differing output syntax.

Enabling everything by default is one option here, but that encourages people to not consider how things actually work, which is rarely a good idea. It also assumes that adding complexity around knowing what to _disable_ is actually better, which I'm not convinced it is.

I've also hit this in the past. However I feel like I remember seeing that the error messaging had been enhaced in whichever version of Chrome came out next. I've forgotten the details now, but I feel like it explicitly said that an extension had blocked the request.

ES6 imports are declarative, so dependencies are resolved and executed before the body of the module is executed. That means you don't conceptually have to think about whether your dependencies are loading synchronously or asynchronously.

Just a nit, but that isn't destructuring. Named import syntax has several differences, since name aliasing uses a different format and you cannot nest or provide default values.

Both are useful, but I'd hesitate to call it better. What makes you say it is better?