5 ms·

Just because a build is stable (which is what 0.10.23 stable means) doesn't mean the APIs are stable (which is what 1.0.0 generally means). For example, the st

by sheetjs 13y ago

Just because a build is stable (which is what 0.10.23 stable means) doesn't mean the APIs are stable (which is what 1.0.0 generally means). For example, the streams API hasn't been deemed stable. The specific build is stable, but it's possible that the interface may radically change in the near future. http://semver.org/ http://semver.org/

leokun 13y ago
One might just want to assume that node.js never wants to build a stable API. They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. If they'd ever release a stable version they'd suddenly have to backport fixes and care about keeping an API intact for something other than a few months. Like they will not be able to do that thing anymore where they dismiss all those who built upon 0.6 and don't get security updates unless they rewrite big portions of their code base and find new libraries to replace all those they use that have gone dark. Have they at least committed to some kind of date range for a stable API? It's kind of silly to worry about because all the various node.js libraries that so many people depend upon are either weekend fads that get abandoned, or moving at the same speeds and likewise breaking compatibility.
- sheetjs 13y ago
  > They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. The team claims to have turned the corner. relevant comment from @isaacs: https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 > Have they at least committed to some kind of date range for a stable API? @isaacs mentioned 2014 once. From the same talk, https://www.youtube.com/watch?v=82hJbjqbIt4#t=730 https://www.youtube.com/watch?v=82hJbjqbIt4#t=730
  - leokun 13y ago
    Oh that's awesome then. I hope it happens.
- nashequilibrium 13y ago
  This should really be the top comment, as it explains the frustrations you will run into with this fantastic platform. I love async webservers and most of my dev is done on python Tornado but i built two projects on nodejs and experienced the above issues, so many people start projects and just abandon them, the quality of a lot of libraries are not good and then you get some really cool libraries. Everything changes really fast, so you really need to have your ear to the ground to make adjustments to your codebase. All in all, i had a lot of fun with nodejs but for serious dev, i am using Tornado, when nodejs fully supports backwards compatibility, then i will develop more longterm projects on it. I still believe that if you doing a simple crud api for mobile, the current node will work very well as it is so fast and the code will be easier to maintain.
  - damon_c 13y ago
    Yes. One by one, I have been encountering issues with projects I've done in Node that are more easily fixed by rewriting in Python than by researching replacements for abandoned libraries that are breaking or dependencies that are not updated with the APIs they were written to interface with. It's still handy for Grunt and Bower though!
    - babuskov 13y ago
      What's the best replacement for socket.io in Python?
  - couchand 13y ago
    I'd argue that relying on backwards compatibility for very long is a smell. Probably the stinkiest, most common one in most corporate settings.
    - oblio 13y ago
      And not providing any backwards compatibility is BS :) You do need a stable base to build upon. Not quicksand.
malandrew 13y ago
In addition to semver, it's worth checking out the Node.js docs stability guide: http://nodejs.org/api/documentation.html http://nodejs.org/api/documentation.html While semver is great for getting an overview of the stability of the API interface for a project, I think their guide is a great complement in that it helps people determine the stability of specific interfaces that someone might want to use. This is increasingly valuable as the API surface of a project becomes quite large (which is common for a framework).

by sheetjs 13y ago

leokun 13y ago

One might just want to assume that node.js never wants to build a stable API. They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. If they'd ever release a stable version they'd suddenly have to backport fixes and care about keeping an API intact for something other than a few months. Like they will not be able to do that thing anymore where they dismiss all those who built upon 0.6 and don't get security updates unless they rewrite big portions of their code base and find new libraries to replace all those they use that have gone dark. Have they at least committed to some kind of date range for a stable API? It's kind of silly to worry about because all the various node.js libraries that so many people depend upon are either weekend fads that get abandoned, or moving at the same speeds and likewise breaking compatibility.

sheetjs 13y ago
> They are constantly breaking backwards compatibility and committing to "stable" at this point seems unrealistic. The team claims to have turned the corner. relevant comment from @isaacs: https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 https://www.youtube.com/watch?v=82hJbjqbIt4#t=120 > Have they at least committed to some kind of date range for a stable API? @isaacs mentioned 2014 once. From the same talk, https://www.youtube.com/watch?v=82hJbjqbIt4#t=730 https://www.youtube.com/watch?v=82hJbjqbIt4#t=730
- leokun 13y ago
  Oh that's awesome then. I hope it happens.
nashequilibrium 13y ago
This should really be the top comment, as it explains the frustrations you will run into with this fantastic platform. I love async webservers and most of my dev is done on python Tornado but i built two projects on nodejs and experienced the above issues, so many people start projects and just abandon them, the quality of a lot of libraries are not good and then you get some really cool libraries. Everything changes really fast, so you really need to have your ear to the ground to make adjustments to your codebase. All in all, i had a lot of fun with nodejs but for serious dev, i am using Tornado, when nodejs fully supports backwards compatibility, then i will develop more longterm projects on it. I still believe that if you doing a simple crud api for mobile, the current node will work very well as it is so fast and the code will be easier to maintain.
- damon_c 13y ago
  Yes. One by one, I have been encountering issues with projects I've done in Node that are more easily fixed by rewriting in Python than by researching replacements for abandoned libraries that are breaking or dependencies that are not updated with the APIs they were written to interface with. It's still handy for Grunt and Bower though!
  - babuskov 13y ago
    What's the best replacement for socket.io in Python?
- couchand 13y ago
  I'd argue that relying on backwards compatibility for very long is a smell. Probably the stinkiest, most common one in most corporate settings.
  - oblio 13y ago
    And not providing any backwards compatibility is BS :) You do need a stable base to build upon. Not quicksand.

malandrew 13y ago

In addition to semver, it's worth checking out the Node.js docs stability guide: http://nodejs.org/api/documentation.html http://nodejs.org/api/documentation.html While semver is great for getting an overview of the stability of the API interface for a project, I think their guide is a great complement in that it helps people determine the stability of specific interfaces that someone might want to use. This is increasingly valuable as the API surface of a project becomes quite large (which is common for a framework).