DEV Community

loading...

Discussion on: Modernize your ReactJS application with async/await in 2018

Collapse
codeprototype profile image
Kevin Le Author

It's good to have an eye on the transpiled code. For a simple case, it might seem like there's no gain of using async/await over using then clauses. But the benefits of using async/await will be more obvious when the business logic gets more complicated. Async/await code will be more readable than "then" clauses.

Now if you have to stop each time to compare the size of the transpiled code, then I recommend against that. I also recommend against coming up with a rule that says something like "Ok, less than 2 "then" clauses, then no async/await".
Business logic does change. So suddenly we have to make one more asynchronous call, then such rule is more trouble than it's worth.

Collapse
nickytonline profile image
Nick Taylor (he/him)

It depends what browsers you're targeting. Assuming (and I hope) you use babel-preset-env, async/await will only be transpiled to ES5 for pretty much just IE11 and below. All the other browsers support await now.

If most of your market is IE <= 11 , then maybe perhaps it's not wise to use async/await. Honestly though so many things come in to play for bundle size, but obviously a smaller bundle size is usually a good thing.

Thread Thread
domysee profile image
Dominik Weber

This is great news! Since it's ES7 I assumed it won't be implemented by browsers yet.

Thanks for pointing out that it is.

Regarding the bundle size, I agree that many things affect that. But I don't think that bloating up async/await statements to 10x the original code size is negligible.