streamline vs. native async/await

[spollack]

Hello @bjouhier! i hope all is well with you.

as you know i have been a big proponent of streamline for ~6 years, because it has made writing node code sane. we have a substantial streamline codebase at this point. we owe you enormously!

given that modern node.js has async/await support, i'm wondering if/when/how we should move from streamline to native async/await. rereading #254, i am reminded of some of the concerns, such as performance (we do use the streamline fibers runtime) and syntax.

another consideration is what level of continued support and investment you plan to make in streamline. i expect there will be substantial ongoing ecosystem investment in async/await since it is part of the core platform.

I would love your thoughts on this topic. have you done any recent performance measurements? have you moved any codebases from streamline to async/await? what are your plans in this regard?

Thanks,
Seth

[bjouhier]

Hi Seth,

We are still using streamline in a large part of our code base so I will continue to maintain it for some time but I don't intend to develop new features.

We are not switching to async/await for our own projects. Instead we are writing our new server-side code with the f-promise library. This library reduces the async syntax overhead to a minimum and eliminates transpilation. OTOH, it requires fibers so it only works server side.

We are using async/await in the browser but this code is not translated from streamline as we did not use streamline in the browser before.

The other way forward is to migrate to async/await. We did not do it for the following reasons:

• heavier syntax
• heavier array API (Promise.all calls, f-promise works directly with ES/6 array API).
• no async accessors (streamline did not support them but f-promise does)
• no support for global context
• poor stacktrace support (unclear if this got solved in async/await land)

We did not develop any conversion tool from streamline to async/await as we chose a different path. I did some experiments with an async/await transpiler mode a long time ago but I did not complete it. It should not be too difficult to develop such a tool, though.

Thanks for your continuing support BTW. I really enjoyed your blog article!

Bruno

[spollack]

Bruno, thank you, that is helpful!

[spollack]

Hi again @bjouhier ! I hope you are well. It's been a wild past year for sure.

We are finally looking to make this move from streamline to native async/await. The async/await tooling support has gotten good, we are missing out on newer ES features because of streamline being a babel 6.x project, and we don't want to make you keep maintaining this forever! ;-)

I'm curious if you did ever end up doing any conversion tools that might help? if so, great! if not, we are busy looking at how to do these transforms.

Thanks,
Seth

[spollack]

@bjouhier i want to let you know that we've made the transition to native async/await now.

thank you SO MUCH for this library, and all the help over the years. i really appreciate it!