5 ms·

I've been on a similar learning curve with Node over the last year, and it has certainly been a rougher incline than other languages I've used. The whole async

• sockgrant 10y ago
  Agreed. Checkout RxJS to hold you over while you're in Javascript land.
  • Touche 10y ago
    Please don't use event streams for handling asynchronous code, that's not what it's for.
    • sockgrant 10y ago
      Can you elaborate?
      • Touche 10y ago
        Event streams are similar to Promises in that they provide a value for something that will happen in the future. In the case of event streams it is a value for an event. In the browser this might be a user clicking a button. This event can occur many times. It might never occur. Promises are values for something that will happen in the future, but only once. Use Promises for things that happen once, event streams for things that happen 0 to many times.
        • rescripting 10y ago
          I'm not sure I'm seeing your argument against using promises over observables for single events. Observables are a superset of promises, sure, but you can map them into situations where you'd use promises and then still have the flexibility of observables and all their operators. along with this you get the consistency of using the same async paradigm everywhere. I find you run into trouble when you start mixing them. If you use observables for 0-N events and promises for 1 time events you're always converting between the two.
          • lmeyerov 10y ago
            Yep. We used to do both, but that was convoluted, so only Rx now.
• zxv 10y ago
  Yes, I too find callbacks an obstacle to readability, among other things. If one uses mongodb (popular on node.js), and one needs multiple queries to 'join' several documents, the cascade of callbacks is an obstacle to readability, let alone debugging.
  • mikeryan 10y ago
    If you're writing a cascade of callbacks then just use promises. There's no reason to be needing to cascade callbacks pretty much all libraries now support promises and the rest can be promisified. I'm not calling it a Panacea but Promises are idiomatic Node Javascript now and there's almost no reason for mutliple levels of nested callbacks anymore.
• woah 10y ago
  Callbacks are ugly, but are probably the semantically simplest way to handle asynchronicity. Promises are ugly too, but are semantically the same thing as async/await. I agree that promises and callbacks are not pleasing to the eye, but they are completely logical ways to do things.
  • firasd 10y ago
    So in PHP, you would go (I haven't tested these snippets, just writing them out here): $username = get_username(); echo "Hi, ".$username; do_other_things(); In Node, using promises, you have to write: get_username().then(function(username) { return res.send("Hi "+username"); }).then(function() { do_other_things(); }) And if you're using regular callbacks, forget it: you'd have to nest do_other_things in the callback of get_username(!). It just makes things very awkward. I understand what you mean about sync vs async calls. I won't pretend I have a better solution. I don't mean to say callbacks are illogical, just a bad way to write programs. So maybe not 'wrong in concept', I can concede that. But I think async/await can make things more readable again, i.e.: var username = await get_username(); /* carry on... */
    • spion 10y ago
      If otherThings is unrelated, you could also do this: var username = getUsername(); var resultSent = username.then(username => res.send("Hi "+username")) var otherThings = doOtherThings() return Promise.all([resultSent, otherThings])
    • tomc1985 10y ago
      It's not so much because of promises, its because sync IO blocks the GUI thread, so you have to write callbacks somehow. Pick your poison.
• Silhouette 10y ago
  I find that JS often seems to tie programmers in the most extraordinary knots just to implement even quite simple logic, because of the single-threaded nature of the language. In the programming model used by most other mainstream languages today, if you've got some work to do that interacts with some external system and might take a while, you'd probably start another thread for that task. You'd write the required logic in the usual linear fashion, and just let the thread block if and when it needs to. Modelling this using fork/join semantics and techniques to co-ordinate access to shared resources from different threads are reasonably well understood ideas. Because there is no general support for concurrency and parallelism in JS, you only get one thread, and so in most cases you can't afford to ever block it. Consequently, you get this highly asynchronous style that feels like writing everything manually in continuation passing style, just so you can carry on with something else instead of waiting. That in turn leads to callback hell, where you start to lose cohesion and locality in your code, even though usually you're still just trying to represent a simple, linear sequence of operations. Async/await help to bring that cohesion and locality back by writing code in a style that is closer to the natural linear behaviour it is modelling. However, even those feel a bit like papering over the cracks in some cases. Async/await kinda sorta give us some simple fork/join semantics, but as the blog post linked from the parent shows, we have a lot of promise-based details remaining underneath. Fundamentally, the problem seems to be that JS is increasingly being used to deal with concurrent behaviours, but it lacks an execution model and language tools to describe that behaviour in a natural, systematic way as most other widely used languages can. Being strictly single-threaded avoided all the synchronisation problems in the early days, when the most you had to worry about was a couple of different browser events firing close together and it was helpful to know the handler for one would complete before anything else started happening. I'm not sure it's still a plus point now that we're trying to use JS for much more demanding concurrent systems, though.
  • Touche 10y ago
    > Modelling this using fork/join semantics and techniques to co-ordinate access to shared resources from different threads are reasonably well understood ideas. Writing thread-safe code is anything but easy in languages that support threads.
• ralusek 10y ago
  I feel like I'm taking crazy pills. "Async situation needs to settle down"...? "Completely unacceptable to write code with promises"? Look at the following code: https://paste.ee/r/LJnhg https://paste.ee/r/LJnhg I have function requestFromService and another readFromDB. On a single thread, I issue one request to a service and one to the database server, and you think it makes sense for the thread to just wait around? In javascript, the second I issue those two requests, the thread is available to now serve the next incoming request or do literally anything else while those services take as long or as little as they need. The code itself could not be more clear as to what will happen, except for maybe the syntax Promise.join(), which was only there to illustrate how easy it is to do concurrent, asynchronous tasks. You don't have to think twice about what to do while those requests carry out, and it's not like you had to write your code in a complex manner to take advantage of the asynchronous nature of JS, it just inherently works that way. Maybe I have gone and served 5 more requests while the db server was responding, and I didn't have to even be aware of the concurrency whatsoever.
  • firasd 10y ago
    I'm not disputing the architectural choices behind Node's async model. I'm talking about syntax. It's cool that you can process multiple promises at the same time, but most of the time I need one promise to complete before continuing. In those cases the way it inverts regular code flow is very unnatural. Like I said, I think more support/usage of 'await' will help.