> 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.
That's a big selling point for me, props to the engineering team for accommodating this, I work mainly on integrations and the trickier bug reports are weird edge cases that involve a lot of getting specific descriptions of what happened and replicating it manually on a sandbox so as not to impact API calls, getting on the phone to talk through exactly what they're doing, asking for screenshots via email, clarifying conflicting understanding of in-house terminology etc. You know the story.
Being able to get them to record the exact process and scrub through it at my leisure without having to worry about hammering APIs would be a massive timesaver, replication is about 90% of the time taken to fix a bug, while the fixes themselves are usually trivial. Not having to worry about accidentally replaying a bugged-out API call is a huge plus.
In my case the major hurdle I can foresee is the majority of my enterprise-level clients use Windows and a brief look at the website says currently there's only Mac / Linux support for the replay browser. What's the timeline on Windows support?
The only other thing I can think may be an issue is that the recordings are cloud-based and a lot of the clients I deal with are finnicky about exfiltration and governance, and would be a lot more comfortable self-hosting where possible. Is that possible or on the roadmap?
This looks like a super useful tool to add to the toolbelt for sure, I would love to have all my clients using something like this to report issues. Nice work all!
(Replay engineer): re: Windows, we have an alpha build out now, with a wider beta release coming later this year.
re: on-prem, it's definitely something we plan to support, and something we have engineered in to the infrastructure. If you're interested email hi@replay.io, we'd love to talk more.
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.
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.
Isn't (or wasn't, when it was 6to5?) the entire point of babel to make jumping into ES6 as easy as possible for browser users? My expectation is that the default is "Compile my ES6 to ES5 that browsers can run", and anything further than that would be configurable.
Unfortunately, because of browser support "ES5" itself is a moving target. With the release of Babel 6 they've dropping automatically polyfilling for Promises, so you'll need to include an additional polyfill or it will expect the browser supports it. Some setups use Babel to run on Node.js v4+ which supports most of ES6 natively.
There's no magical "ES6"-level of browsers which support all features of Promises, though[1]. Some products support IE11, some don't. Some only support the latest versions of Chrome and Firefox. Additionally, more people are using features not even in spec[2], known as "strawman proposals", some which are quite popular in real-life code examples[3]
Because of the moving targets on what Babel is transpiling from and to, they went for a "you decide" approach which promotes no particular level of "modern javascript" or "compiled javascript".
It's unfortunate they don't have `npm install --save-dev babel babel-preset-es2015` and "write `{"presets":"es2015"}` to a new .babelrc file" smack-bang at the top of the homepage though. The "handbook" links to a page of links, the "setup" page asks more questions than it answers. With modern Babel, no matter what build system, the above 2 steps are the same, and the 3rd is "add babel to your build system, or `npm install -g babel` and run that"
How about just shipping it with all the main presets all configured and built in?
Not even the need to understand what presets are, choose the presets, install the presets, diagnose the problems with the presets etc. Just make it work out of the box.
Making it "work out of the box" is something we had before, and we watched as proposals changed and we blew through 5 major releases in like 6 months getting more and more complicated as we went.
On top of that it was only going to get worse as people were throwing proposals around left and right and we never were quite sure what a "sane default" was. We were never sure how to keep people on track with rapidly changing proposals.
The move to a completely configured Babel, meant a move from implicit behavior to explicit behavior. People are forced to tell Babel what they want out of it.
Configuration means explicitness, explicitness means safety.
This strategy underestimates the cost and difficulty of configuration.
Hopefully the message that is coming through here is that configuring Babel is extremely hard and time consuming and error prone and is a massive, massive headache.
I am still right now trying to work out why async and await do not work after spending all day on it.
Probably for Babel experts configuration is easy and quick but for those who are not specialists in it forcing users down a configuration path is deeply, excruciatingly painful.
They need a big getting started page and direct newcommers to it where they don't try to be clever, but directly list scenarios.
Or they (or you) could make a configurator (they already have a build-tool focused one, but they need one kind of like what jQuery has) on the website, where you can select your target browser version(s), and what features you want enabled. Bam. Magic! Here's a JSON file, put it into your project root.
Async/await, I'd just go with TypeScript and then transpile the ES6 to ES5 with Babel.
>It's unfortunate they don't have `npm install --save-dev babel babel-preset-es2015` and "write `{"presets":"es2015"}` to a new .babelrc file" smack-bang at the top of the homepage though.
I think this would be a great first step towards making startup for new users less painful. Or maybe making an onboarding process similar to `npm init`, where the user is walked through a series of questions about what they need for their project and the initial .babelrc is generated automatically.
Exactly! Enabling unstable language features like decorators by default is the opposite of a novice-friendly decision, as is enabling by default features that require pulling in e.g. the Regenerator runtime.
The author of the post doesn't seem to understand that many of the transforms supported by Babel touch on proposals that are actually at various stages of being experimental or unstable, which actively should not be enabled by default for the sanity of users who don't know better.
Opting a novice user by default into a language feature that might well change is not a good thing! Otherwise we end up with something dumb like the legacy decorator transform, where people unknowing code against proposals that are liable to change under them.
>> actively should not be enabled by default for the sanity of users who don't know better
The idea that users should be protected from themselves isn't an effective one and is at the heart of the idea that Babel should do less and more should be configured in.
Nothing terrible will happen if a user uses a feature that is experimental or unstable. They might get to use it successfully however if it comes preconfigured. I can just update my code when the spec stablises.
>> the sanity of users
The sanity of users is broken by the myriad problems with Babel configuration.
It's not that the users should be protected from themselves, but that they should be protected from instability.
Proposals are constantly changing, and keeping a monolithic Babel on track with them without breaking things for users all the time is a difficult problem.
The configuration is more than just configuration, it's explicitness. It's telling Babel exactly what you want out of it. That way you never have to worry about changing behavior until you want to make the migration.
The situation is more nuanced than you are recognizing.
>> but that they should be protected from instability.
Appropriate protection is a warning in the docs "this code might change when the spec is finalised".
Inappropriate protection is hiding those features away behind difficult-to-configure barriers making it only possible for experts to configure their systems to run it.
If we don't decide to include "everything" by default, we can work on better docs (help is appreciated in where that could be improved as well as contributors!), and create a better setup experience with something like a `babel init` command. We can also run that/error when a user tries to run babel without specifying a preset/plugin.
Main gripe a lot of people I know share with me is that Babel 5 was easier, and babel-node was useful out of the box. Now it feels like getting someone's dev style getting foisted on us to get something useful out of it..
> ...but that encourages people to not consider how things actually work, which is rarely a good idea.
I'd actually take the opposite position here: people should typically not have to consider how the tools they use work, until they need to go beyond the basics.
If all I want is "the latest javascript", I should be able to get it without pondering the genius of a library's creators.
Simplification, preconfiguration, removing of the need to configure. If these were major project goals then the developers could be reminded of them every time they implement something. If a developer implements some new feature that requires (yet more) configuration then other project developers can remind them "hey was there any way you could have done this without config, or built the config in?".
I do think the kitchen sink should be included by default, even for experimental stuff. Optimisation and minimisation should be the expert case. Maybe the kitchen sink costs are size of executable or performance of compiled code but I'd gladly pay that price for something that actually instantly works without always expecting to descend into configuration hell.
Consider async/await. Why not include it fully configured out of the box? Right now I am sitting here wasting my Easter public holiday trying to get async/await to work - it still does not.
async/await are a great idea and developers will want to use them. Who cares if the standard is not yet ratified, why does that mean I should live with the cost of trying (unsuccessfully) to configure it? Why didn't the developers do it?
>> I don't feel that it's reasonable to assume that setting up a build system will be trivial.
Absolutely correct, and that's the precise reason why projects like Babel should do their utmost to make it as trivial as it possibly can be.
>> Enabling everything by default is one option here, but that encourages people to not consider how things actually work
This isn't a good enough reason to force me to do configuration.
I really want to defer the need to know how things work as far as possible into the future unless I really need to know it now. It's not that I want to be ignorant, but right now I am focusing all my learning effort on programming my application, and how the language works, and how the libraries work. Do I really need to be forced to understand how Babel works too? I'd prefer not to unless that learning directly gets me some outcome.
>> It also assumes that adding complexity around knowing what to _disable_ is actually better, which I'm not convinced it is.
Yes but better to invert the formula so that configuration is a process for experts to disable functionality in order to optimise rather than forcing beginners to enable.
Also, don't you Babel developers find you have to spend time constantly diagnosing configuration problems and errors?
> I do think the kitchen sink should be included by default, even for experimental stuff. Optimisation and minimisation should be the expert case.
A common theme in the counter-argument is that developers should be aiming to get Babel to some "ideal state" which is neither zero-config or full-config.
I'm not ES/Babel expert, but I think that's a reasonable point.
HOWEVER, I strongly feel that it is easier to get to this "ideal state" if you start with a most-uses-cases config. It's always easier to optimise from something that works, instead of trying to optimise from a broken state in the way that Babel now ships.
