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