4 ms·

There is no performance reason to make developers hand-code in the continuation-passing style. node certainly recognizes this. However, there is no need to do

by jeswin 13y ago

There is no performance reason to make developers hand-code in the continuation-passing style. node certainly recognizes this. However, there is no need to do anything here since JS is taking care of this with ES6. Even if you don't want to use ES6, there are now multiple ways to compile it down to ES5. Hence the slowly rising mindshare of Promises Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future. In terms of expressiveness, there isn't much to choose between dynamic languages. While it took some getting used to, programming JS wasn't that different from writing Python. However, JS/node is succeeding because this is the first time ever that we have a language/platform that is truly write-once, run-anywhere. A significant advantage in favor of node. [1] https://github.com/visionmedia/co https://github.com/visionmedia/co

ef4 13y ago
Yes, I'm looking forward to ES6. And I agree that Node's strength is that Javascript is truly the lingua franca of the modern web, which I why I would even bother using it. But the value of running everywhere is also why ES6 is not a panacea. As you say, soon we won't need promises "on the server". But I want my codebase to run correctly everywhere. Promises are a bandaid that I'll need for quite a while yet.
- phillmv 13y ago
  If you're not shipping your js code to the browser, then it's frankly kinda silly to write it on the server.
  - ulisesrmzroche 13y ago
    No one pay attention to this dude. Of course it isn't silly. Plenty of people build their servers with JS and put them into production.
    - twic 13y ago
      Plenty of people build their servers with PHP and put them into production. It is still germane to ask if this is silly. for LANG in Java Scala Ruby Python C C++ Groovy Clojure; do s/PHP/$LANG/; done
      - ulisesrmzroche 13y ago
        Something silly is like putting shit-tons of fish into a box and expecting it to make HTTP requests. Writing a web server in PHP, regardless of what you think of the language, isn't. Comments like that are just gonna clutter someone's Google search one day.
        phillmv 13y ago
        "Right tool for the right job". If all you have is a room full of PHP developers and all you need is a REST site, then well you could do worse but I would like to discourage you from the practice. Similarly, unless you have a highly specialized need - fun asynch chat server or complex app where business logic is being directly shared between client and server - I too would discourage locking one's self into that platform. Javascript is not the worst thing ever, but why bother if you don't have to?
        ulisesrmzroche 13y ago
        1) Laravel is a fantastic choice for building web servers if your team is primarily PHP. 2) There is no such thing as locking yourself into the JS platform, because JS has the advantage of being our lingua francua, is a general purpose programming language (servers, clients, and more!) AND is the language with the most momentum TODAY. Not last year, not 20 years ago.
babby 13y ago
>A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1] Dont you mean you won't see standalone Promises, and instead Promises + Generators?
masklinn 13y ago
> Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future. I'm impressed that you apparently completely failed to realise co is an abstractive layer over promises, something it states upfront: > Generator based flow-control goodness for nodejs (and soon the browser), using thunks or promises What you yield from your generator is not magical pixie dusts, it's promises.
- sync 13y ago
  Actually, it's not promises. It's generators. co thunkifies promises: https://github.com/visionmedia/co/blob/master/index.js#L209-L215 https://github.com/visionmedia/co/blob/master/index.js#L209-...
  - masklinn 13y ago
    > Actually, it's not promises. It's generators. The generator is the driver, but the driver on its own its useless if it's got nothing to drive. And what it has to drive is promises (or thunks since most existing node code is thunks-based I guess it makes sense to support that. taskjs uses promises more or less exclusively for the same purpose, Python 3.4's asyncio uses behaving much like JS promises, etc...)
    - jeswin 13y ago
      Seems you have misunderstood how it works. https://github.com/visionmedia/co/blob/master/index.js https://github.com/visionmedia/co/blob/master/index.js Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there. Here is a file from my ongoing project, should explain how generators are being used. See getPosts() or addPost() https://github.com/jeswin/fora/blob/master/server/src/models/forum.coffee https://github.com/jeswin/fora/blob/master/server/src/models... [Edit: Just read your earlier (Gr.GP) comment. Might want to avoid the unnecessary snark, especially when there's a chance you might be wrong.]
angersock 13y ago
The linked page doesn't really convince me. What do we get using this new shiny instead of the older shiny bluebird or the old shiny Q?

by jeswin 13y ago

ef4 13y ago

Yes, I'm looking forward to ES6. And I agree that Node's strength is that Javascript is truly the lingua franca of the modern web, which I why I would even bother using it. But the value of running everywhere is also why ES6 is not a panacea. As you say, soon we won't need promises "on the server". But I want my codebase to run correctly everywhere. Promises are a bandaid that I'll need for quite a while yet.

phillmv 13y ago
If you're not shipping your js code to the browser, then it's frankly kinda silly to write it on the server.
- ulisesrmzroche 13y ago
  No one pay attention to this dude. Of course it isn't silly. Plenty of people build their servers with JS and put them into production.
  - twic 13y ago
    Plenty of people build their servers with PHP and put them into production. It is still germane to ask if this is silly. for LANG in Java Scala Ruby Python C C++ Groovy Clojure; do s/PHP/$LANG/; done
    - ulisesrmzroche 13y ago
      Something silly is like putting shit-tons of fish into a box and expecting it to make HTTP requests. Writing a web server in PHP, regardless of what you think of the language, isn't. Comments like that are just gonna clutter someone's Google search one day.
      - phillmv 13y ago
        "Right tool for the right job". If all you have is a room full of PHP developers and all you need is a REST site, then well you could do worse but I would like to discourage you from the practice. Similarly, unless you have a highly specialized need - fun asynch chat server or complex app where business logic is being directly shared between client and server - I too would discourage locking one's self into that platform. Javascript is not the worst thing ever, but why bother if you don't have to?
        ulisesrmzroche 13y ago
        1) Laravel is a fantastic choice for building web servers if your team is primarily PHP. 2) There is no such thing as locking yourself into the JS platform, because JS has the advantage of being our lingua francua, is a general purpose programming language (servers, clients, and more!) AND is the language with the most momentum TODAY. Not last year, not 20 years ago.

babby 13y ago

>A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1] Dont you mean you won't see standalone Promises, and instead Promises + Generators?

masklinn 13y ago

> Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future. I'm impressed that you apparently completely failed to realise co is an abstractive layer over promises, something it states upfront: > Generator based flow-control goodness for nodejs (and soon the browser), using thunks or promises What you yield from your generator is not magical pixie dusts, it's promises.

sync 13y ago
Actually, it's not promises. It's generators. co thunkifies promises: https://github.com/visionmedia/co/blob/master/index.js#L209-L215 https://github.com/visionmedia/co/blob/master/index.js#L209-...
- masklinn 13y ago
  > Actually, it's not promises. It's generators. The generator is the driver, but the driver on its own its useless if it's got nothing to drive. And what it has to drive is promises (or thunks since most existing node code is thunks-based I guess it makes sense to support that. taskjs uses promises more or less exclusively for the same purpose, Python 3.4's asyncio uses behaving much like JS promises, etc...)
  - jeswin 13y ago
    Seems you have misunderstood how it works. https://github.com/visionmedia/co/blob/master/index.js https://github.com/visionmedia/co/blob/master/index.js Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there. Here is a file from my ongoing project, should explain how generators are being used. See getPosts() or addPost() https://github.com/jeswin/fora/blob/master/server/src/models/forum.coffee https://github.com/jeswin/fora/blob/master/server/src/models... [Edit: Just read your earlier (Gr.GP) comment. Might want to avoid the unnecessary snark, especially when there's a chance you might be wrong.]

angersock 13y ago

The linked page doesn't really convince me. What do we get using this new shiny instead of the older shiny bluebird or the old shiny Q?