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`.

You don't even need the `Array.from` anymore. `.forEach` on `NodeList` is standard https://developer.mozilla.org/en-US/docs/Web/API/NodeList/fo..., so all you need to do is load a polyfill for that.

It's even easier now. `.forEach` on `NodeList` is standard https://developer.mozilla.org/en-US/docs/Web/API/NodeList/fo..., so all you need to do is load a polyfill for that.

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?

I switched to Fi about a month ago and it has served me very well in the Bay area so far, and it made a trip to the east coast with good wifi and bad cell service much easier because I could just use wifi.

Also liking the Nexus 6. After playing with a coworkers a little I decided I was fine with the size and after a month I'm still very happy with it. I upgraded from a Galaxy Nexus.

Please who doesn't love being able to ditch Verizon.

JSON is a very specific subset of JavaScript, and there is no literal syntax for Symbols, so there is no defined way to represent a symbol at the moment. Unless you wanted to encode them as a function call or something, which sounds terrible.

To me at least, that's more up to NPM to manage though. As it is, it means you're essentially sidestepping npm. There's also no guarantee that people will install a version of babel-runtime that is compatible with the version of Babel that you used to publish the code.

It also means trine can never upgrade the version of Babel it is using internally, since Babel could change the helper name that it uses or something, but that might not exist in the version of babel-runtime being used in the code that depends on trine.

Looks cool.

Not sure I get why installing `babel-runtime` would be something you'd have as a separate install step though, since there is no guarantee that the user would install the right version.

The main other benefit of decorators is that they work on property descriptors, and are automatically passed property names and the target object, so you have a bit more info.

Having the descriptor means for instance that you can switch a value to use a getter function, and that enables a bunch of interesting functionality that you couldn't otherwise do.

One example that I like is automatically binding methods to the current instance on first property access.

Yeah, I wish that were handled better too. Since the parser is expecting a statements, it parses it like

    {
      a
    }

    = 5

You can however do

    ({a} = 5);

Happy to hear Babel is working well for you. I'm loving it too so far. Just to noet, named imports aren't technically destructuring though, since the syntax is different and doesn't nest. e.g.

    import { fooFunc as otherFooFunc} from './Bar';

    import { fooFunc: otherFooFunc} from './Bar';

I see an "aliceblue". No idea if there is a history behind it.

http://dev.w3.org/csswg/css-color/#named-colors

Overall, totally agree, just wanted to mention two things.

2) I've always found passing callbacks by name to be very difficult to read/follow, but this is a case where I think ES6 arrow functions will help readability a lot.

    getUserByName('nolan')
        .then(user => getUserAccountById(user.id))
        .then(userAccount => // I got a user account!)

The main thing in my mind is that it means your code could have cases where it throws synchronously, and cases where the promise rejects with an error.

One place this is mentioned is: https://github.com/petkaantonov/bluebird/wiki/Promise-anti-p...

That was my first question too. QUIC is all user-land code.

Definitely second writing your own as a way to learn. I wrote one that could mostly play pong a while back and it was super satisfying. The PPU was definitely the toughest part.

Maybe it's only a hashed version of the characters? :P

I save pretty compulsively, so this would annoy the crap out of me...

Definitely. Thankfully, ES6 will introduce

    "🍣".codePointAt(0)

    for (var c of "🍣"){}