4 ms·

The only thing I worry about is while packages will be npm compatible, if they want to take iojs to another level as far as features go you will then have npm p

The only thing I worry about is while packages will be npm compatible, if they want to take iojs to another level as far as features go you will then have npm packages that either only work on iojs or you will have polyfill libraries for iojs features to work on node.js. Yeah this doesn't mean node.js is "fucked" but if they use npm in iojs with packages that take advantage of new API calls any node user is going to have lots of issues. Edit: Having said that I am excited to possibly get newer versions of V8 server-side; I can't wait to start using some ES6 in a place where I don't have to wait for browsers to update.

nawitus 12y ago
If you can implement the new features with polyfills, why do you need io.js in the first place?
- deleted 12y ago
  [deleted]
- munificent 12y ago
  Better performance, debugging, and a simpler developer iteration loop for polyfills that require a compilation step.
- nailer 12y ago
  Having them used out of the box would make them more robust.
  - jessaustin 12y ago
    NPM dependencies are a very robust method for ensuring that a module has what it needs to function "out of the box". What else are you looking for here?
    - nailer 12y ago
      Do you mean to reply to me? I made a commeny about innovation in the stdlib would be good. and I'm quite happy with io.js supporting npm.
      - jessaustin 12y ago
        >>>>If you can implement the new features with polyfills, why do you need io.js in the first place? >>>Having them used out of the box would make them more robust. >>NPM dependencies are a very robust method... What else are you looking for here? >Do you mean to reply to me? In light of nawitus's comment, I interpreted your comment as an alleged reason IO would be necessary, given the existence of polyfills. This reason didn't make sense to me, because npm dependency installation for node is just as automatic as anything in IO could be, whether it uses npm or not.
        nailer 12y ago
        io.js is doing new things, they might be polyfillable on top of node, but more people will use new versions of inbuilts like 'process' of 'fs' if they're in io's stdlib than if they're in some optional module people could (but probably won't) install on node.
- venomsnake 12y ago
  Performance comes to mind. Robustness too.
  - nawitus 12y ago
    Those are decent points, but I'd think Io.js would have more reasons. First of all, if you implement a polyfill in JavaScript, it'll be translated into pretty fast native code. But even if it didn't, most(?) of Node's core libraries are written in plain JavaScript and presumably are as fast as any module in npm. Take a look: https://github.com/joyent/node/blob/master/lib/buffer.js https://github.com/joyent/node/blob/master/lib/buffer.js And if you really want optimized native code, npm supports that out of the box. I kinda dislike npm modules that require a compilation step, but they're out there. As for robustness, there's nothing stopping one to making robust node modules that are not in the core.
- deleted 12y ago
  [deleted]
bsimpson 12y ago
FWIW, https://github.com/petehunt/node-jsx https://github.com/petehunt/node-jsx will let you use many of the JS Harmony features (lambda arrows, destructuring, concise method notation) in Node today. These are all the sugars that are available: https://github.com/petehunt/node-jsx https://github.com/petehunt/node-jsx
- BinaryIdiot 12y ago
  That looks pretty nifty; I don't have an immediate need for it yet but I'll definitely check it out. Thanks!
tracker1 12y ago
There's already some of that... there are packages/tooling built aroud co/koa with features that you need the latest 0.11.x and --harmony to use. I like a lot of the ES6 features... to ES7, if await/async can be introduced with thenables sooner than later, it will mean that co will become irrelevant for the most part, and a lot of tooling around a koa2 will be awesome. There's a lot to be excited about.

nawitus 12y ago

If you can implement the new features with polyfills, why do you need io.js in the first place?

deleted 12y ago
[deleted]
munificent 12y ago
Better performance, debugging, and a simpler developer iteration loop for polyfills that require a compilation step.
nailer 12y ago
Having them used out of the box would make them more robust.
- jessaustin 12y ago
  NPM dependencies are a very robust method for ensuring that a module has what it needs to function "out of the box". What else are you looking for here?
  - nailer 12y ago
    Do you mean to reply to me? I made a commeny about innovation in the stdlib would be good. and I'm quite happy with io.js supporting npm.
    - jessaustin 12y ago
      >>>>If you can implement the new features with polyfills, why do you need io.js in the first place? >>>Having them used out of the box would make them more robust. >>NPM dependencies are a very robust method... What else are you looking for here? >Do you mean to reply to me? In light of nawitus's comment, I interpreted your comment as an alleged reason IO would be necessary, given the existence of polyfills. This reason didn't make sense to me, because npm dependency installation for node is just as automatic as anything in IO could be, whether it uses npm or not.
      - nailer 12y ago
        io.js is doing new things, they might be polyfillable on top of node, but more people will use new versions of inbuilts like 'process' of 'fs' if they're in io's stdlib than if they're in some optional module people could (but probably won't) install on node.
venomsnake 12y ago
Performance comes to mind. Robustness too.
- nawitus 12y ago
  Those are decent points, but I'd think Io.js would have more reasons. First of all, if you implement a polyfill in JavaScript, it'll be translated into pretty fast native code. But even if it didn't, most(?) of Node's core libraries are written in plain JavaScript and presumably are as fast as any module in npm. Take a look: https://github.com/joyent/node/blob/master/lib/buffer.js https://github.com/joyent/node/blob/master/lib/buffer.js And if you really want optimized native code, npm supports that out of the box. I kinda dislike npm modules that require a compilation step, but they're out there. As for robustness, there's nothing stopping one to making robust node modules that are not in the core.
deleted 12y ago
[deleted]

bsimpson 12y ago

FWIW, https://github.com/petehunt/node-jsx https://github.com/petehunt/node-jsx will let you use many of the JS Harmony features (lambda arrows, destructuring, concise method notation) in Node today. These are all the sugars that are available: https://github.com/petehunt/node-jsx https://github.com/petehunt/node-jsx

BinaryIdiot 12y ago
That looks pretty nifty; I don't have an immediate need for it yet but I'll definitely check it out. Thanks!

tracker1 12y ago

There's already some of that... there are packages/tooling built aroud co/koa with features that you need the latest 0.11.x and --harmony to use. I like a lot of the ES6 features... to ES7, if await/async can be introduced with thenables sooner than later, it will mean that co will become irrelevant for the most part, and a lot of tooling around a koa2 will be awesome. There's a lot to be excited about.