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.
I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
It depends what browsers you're targeting. Assuming (and I hope) you use babel-preset-env,
async/awaitwill 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.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.