5 ms·

Node 8 is the planned LTS release for later this year. Notably, it brings async/await syntax to vanilla JS. This new feature complements callbacks and largely

• rockostrich 9y ago
  It's just Node 8. They stopped prefixing with "v" this version in order to avoid confusion with the V8 javascript engine.
  • pdog 9y ago
    If the goal was to avoid confusion, it was an incredibly dumb decision. I'll continue referring its standard version number: Node v8.
  • almostdigital 9y ago
    But instead they created confusion on how to write the node version number :)
• pier25 9y ago
  Aync/await is the best thing since sliced bread. It has made my life so much easier.
  • almostdigital 9y ago
    Agreed! once you start using it there's no going back (along with `util.promisify`)
  • davidgf 9y ago
    I started using Async/Await and liked it, but I've been learning more about functional programming and went back to Promises
    • b34r 9y ago
      It IS promises ;) labeling a function as async makes it return a promise. await is sugar for avoiding having to roll your own promise tree.
    • cloverich 9y ago
      Sounds interesting -- do you have any resources handy that cover what you allude to (spec. comparing async calls to promises, and favoring the latter?) I use both in my ui code and they seem to have their niche for me. I prefer promise based calls when I want to separate out fetching data from the state-mutating callback, or when I may want to "cancel" something (ex: fetch a list of items for a list component, then unmount the component before the list returns -- no need to handle the response data anymore).
      • davidgf 9y ago
        Unfortunately not, my opinion is simply based on my personal experience and on what I've been learning along the way. I find promises really handy for data processing pipelines (grab some data and perform some transformations over it to get it in the form you need), regardless of wether any of the steps is async or not. I still find async/await really useful and mix it with promises if I need it, but I prefer to keep my code as functional as I can. Besides, I don't really like how JavaScript handles exceptions and would rather staying away from try/catch if possible
    • pier25 9y ago
      There is no difference, async/await is just another promise notation.
      • davidgf 9y ago
        Although async/await is simply syntax sugar around promises, there's a huge difference indeed. With async/await your code keeps an imperative style, while with promises code end up with a functional look
  • mstade 9y ago
    I understand the reasons why async/await is designed the way it is, but I still think it is backwards. Really if you wanted to truly make async programming approachable, you should make it transparent. What I mean by this is that instead of marking a function as async, and awaiting values, you'd mark lines as async, opting out of implicit awaits. I wrote up some thoughts on this here: https://github.com/utilise/emitterify/issues/1#issuecomment-290943980 https://github.com/utilise/emitterify/issues/1#issuecomment-... The way it is now, I defensively await things all over the place. What's worse, it propagates. If any of your function's dependencies are async, your function will also have to be async (or be ok with continuing operation after it's returned) and it turtles all the way down. It is nicer than having to deal with promises directly though, there is that.
    • maxxxxx 9y ago
      Agreed. Async is like a virus. Once you start somewhere pretty much everything else must be async too. In C# you can call async code from not async code and then call Task.Wait. Not sure if JS can do that. But it still beats promises or callback hell.....
      • b34r 9y ago
        You can't really transition between async and sync scopes, no.
      • WorldMaker 9y ago
        A better term than virus is that async is a monad. Welcome to programming with monads. ;) JS async produces Promises like C# produces Task, so you can call an async function and use the result as a Promise.
        • maxxxxx 9y ago
          Can you wait for a promise synchronously? I am pretty new to JS so please forgive if this is a stupid question.
          • 9y ago
• niklasrde 9y ago
  Are they still calling it 'v8' instead of 8? Also notable is that async/await isn't new for node, 7.10 supported it (and previous versions with a flag). It's new for a LTS release. What is new, however, is the in-built util.promisify that can convert callbacks into native promises.
  • ihsw2 9y ago
    They dropped the "v" from the version name. Yeah, a lot of companies won't touch non-LTS Node though, so a lot of users won't use async/await until later this year when the next LTS is released (Oct 2017).
    • petercooper 9y ago
      They dropped the "v" from the version name. Except in their official release blog posts, it seems :-D
• slackingoff2017 9y ago
  Promises are and always were retarded. They did nothing to alleviate callback hell which was most of the point of their existence. I have no idea why they implemented them instead of async/await in the first place. Now we have to deal with mixing both for years. Another fine example of JavaScript trying to be hip and ignoring the lessons learned from countless other languages over the years. I see this constantly with JS like with the 3+ ways to check for NaN and the object "freeze" system that doesn't actually make objects immutable. They take a solid concept from other languages then put a snazzy spin on it that makes it fucking useless. Then try again in the next version. JS library and syntax is littered with corpses of failed experiments. At least they finally have a usable ForEach loop after three attempts. Please typescript save us from this hubris.
  • laggyluke 9y ago
    You do realize that implementing promises is a prerequisite for async/await, right?
    • hderms 9y ago
      Is it really a requirement? I would think callbacks and a preprocessor are sufficient.
      • avaer 9y ago
        Yes, it's a requirement. If you're using a preprocessor you're not supporting async, you're factoring it out. Otherwise the argument collapses to: we don't need any of these features, we just need NAND.
  • Rockslide 9y ago
    You do realise that async/await is basically syntactic sugar for promises in JS, don't you?
  • buu700 9y ago
    How would you propose that async/await work without Promises? Even C#'s async/await uses the same concept: https://msdn.microsoft.com/en-us/library/system.threading.tasks.task.aspx https://msdn.microsoft.com/en-us/library/system.threading.ta... Pending the implementation of new language syntax, raw Promises were a practical solution for what they set out to accomplish. If you don't think they improved callback hell at all, I expect that you probably weren't using them correctly (an easy mistake to make without looking at the documentation and/or reading the wrong tutorials / blog posts). cf. getAsyncValue1(a => getAsyncValue2(a, b => getAsyncValue3(b, c => doSomething(c) ) ) ); and getAsyncValue1().then(a => getAsyncValue2(a) ).then(b => getAsyncValue3(b) ).then(c => doSomething(c) ); Sure, async/await flattens that to zero nested callbacks, which is great, but with that off the table I'd rather deal with code flattened to one level deep (or a few, in some edge cases) than arbitrarily many. And that's just the "callback hell" improvement; don't forget what a nightmare error handling with callbacks can be — you have to handle both synchronous exceptions and error value callback parameters, you have to deal with the possibility of the asynchronous function unexpectedly calling your callback more than once, etc.