Io.js 1.0.0
iojs.org
iojs.org
Hmm. Lets hope the spork gets spooned so that no projects get knifed. If not then I guess we have to hope for a knork so we don't get stuck with a couple of chopsticks.
Glossary
Forking : Creating a fork to intentionally diverge from main-line development.
Spooning : Merging a fork back into the main line of a project
Sporking : Creating a fork that you would really like to become the next main-line version but you kinda have to prove its awesome first (sporks are pretty awesome)
Knifing : Action killing a project, abandon hope :(
Knorking : A fork replaces the original project which dies off i.e. a fork knifes the original
Chopsticking : Two forks vie for popularity splitting the community and becoming lone chopsticks. Chopsticks need to work together to make stuff happen!
Don't get me wrong, thanks for the information. But seriously. It's like when you come up with a whimsical naming scheme for your home network devices and you get trapped in that naming scheme and have to come up with more and more obscure Lithuanian folk demons that fit into your conventions and it becomes a parody of itself and you're not sure if you're serious or joking anymore.
OTOH, Vishnu himself has a thousand names (Vishnu-Sahasra-nama)!
I'd say you are in fairly good shape.
I do website and irc stuff for io.js and I had trouble describing what the project was in relation to node.js.
So I called it a spork, because "sporks are friendlier". Whatever that means. Aside from being friendly.
Proof is somewhere in the io.js irc logs back near when the project sporked.
From the FAQ:
> What is io.js?
> io.js is a JavaScript platform that is compatable with Node.js & npm.
What does that even mean?
Edit: Thanks for those answering. I started figuring out what it was, but sometimes folks really need to learn that "A correct definition" is not the same as "a useful definition". However, if it's as cool as described, definitely might give it a shot.
Edit2: Is this expected to be as stable as Node.js consistently? And how solid is the upgrade path- is it going to be a pain upgrading between versions the way Node used to be, or is there a smoother upgrade process? I guess what I'm wondering is, do I get any benefit from using this right now, or would it be smart to still wait for whatever version they consider release quality?
"Rails is just an implementation of the MVC pattern, not a framework."
Current Project Team Members
============================
Isaac Z. Schlueter
Ben Noordhuis
Bert Belder
Fedor Indutny
Trevor Norris
Chris Dickinson
Colin Ihrig
Mikeal Rogers
Rod VaggMikeal is overtly political. Isaac is political from time to time since he's strongly aligned with the identity politics mob that attacked ben noordhuis back in the day. I really hope identity politics doesn't creep into the io.js governance.
Oh, wait...
It confuses me deeply that this fact could turn people off of the project regardless of its other practical and technical merits.
Still, the inclusion shows that not all bridges are burned, which makes me happy.
So Ben Noorddhuis was a major contributor to NodeJS and a volunteer (that is, not a Joyent employee). It turns out Ben rejected a pull request that would have made pronoun in the document gender neutral. The documents were already grammatically correct, but whoever made the pull request had a political preference for using a non masculine pronoun. Ben rightly saw this a trivial change. But the political harpies made an issue of it. Joyent put an embarrassing and immature blog posting which essentially called Ben an "Asshole" and said that if he was an employee he'd be fired. https://www.joyent.com/blog/the-power-of-a-pronoun Ben, on the other hand, handled himself quite well. https://github.com/joyent/libuv/pull/1015#issuecomment-29568... https://news.ycombinator.com/item?id=6845286
The request is/was/remains a relevant one. Language is important, it is after all the one of the few tools to describe percieved reality.
a) Talk is cheap, action matters, and the PC police's main strategy is to complain until other people change, instead of enacting change themselves. Accommodating them is useless, they will simply find something new to complain about. Apologies are always insufficient, defiance is considered a declaration of war.
b) Language is indeed important, and redefining concepts like "privilege", "misogyny" and "harassment" to mean whatever the club of the perpetually offended thinks they mean is damaging to sane discourse.
For the record, I believe that's what should be written as the first answer on the FAQ (and maybe on the site's index.hml). The current one is atrocious.
TJ Fontaine Alexis Campailla Fedor Indutny Trevor Norris Nathan Rajlich
Rather strange to see Fedor as a core team member in both projects, or at least one of them (likely node.js page) is out of date.
Yes I know, I need to add `s/anymore/yet`. But the statement is pretty much accurate. Its been almost 2 years since 0.11.0 was released and 0.12 is nowhere in sight.
io.js has many of the top core Node.js contributors. They're trying to move server-side JavaScript forward with open governance, faster release cycles, ES6, etc.
On the other hand, they've been saying that 0.12 will come out 'soon' for over a year, so this too may take longer than I expect.
By comparison, @nodejs announced on Dec 17th, 2014 that 0.11.15 was "tomorrow", but still haven't released anything: https://twitter.com/nodejs/status/545349270241435648
Thanks.
That website needs serious work in terms of wording. Absolutely zero information on the website apart from the extremely vague tagline. I clicked a few links and all I could find was politics. Without the context given on HN I would still be wondering:
Is it a node.js replacement? Is it a NPM replacement? Is it a dog? Is it a cat? Can I eat it?
Even you want to sell something to people (even if that something is free as in beer) they need to know what that something is, first.
It's more like a new version of node with a different name to circumvent trademark issues.
io.js is a fork of node.js but is "better" because:
1) io.js always uses the latest JavaScript engine.
2) io.js is not controlled by private interests.
Also of interest, the state of ES6 in io.js: https://github.com/seegno/io.js/wiki/The-state-of-ES6-on-io..... Highlights: 'let', generators, promises, template literals, symbols are all enabled by default. EDIT: just realized this wiki page has been updated and integrated into the website at https://iojs.org/es6.html
In Node.js to use ES6 you would have to use the --harmony flag to enable them because the version of V8 that is used is so old. Whereas in Io.js anything V8 deems stable is available in Io.js without having to use the --harmony flag.
> io.js is an npm compatible platform originally based on node.js
It's not a library, it's a platform that's based on node.js. It's more or less a fork of node or "spork" as they call it.
The github repo is a bit more clear: https://github.com/iojs/io.js
The main point seems to be that it's run on an open governance model: https://github.com/iojs/io.js/blob/v1.x/GOVERNANCE.md
"io.js is an api-compatible alternative to the node.js runtime, including support for the npm ecosystem, that aims to release faster than the node.js release cycle and move according to a community-driven open governance model."
Given the tremendous volume of packages released to npm, the current one-liner initially just doesn't convey much information. In context of the comments here, it all parses perfectly, but I was one of many who needed this context to understand the (apparent) goals of the project.
Ya, I think the main problem is that no one has any idea what that means from a practical sense. Will my code go faster? Will I get better support? etc.
I think es5 is a dinosaur as of today, so I say go ahead and publish es6 code, and if you want to be nice to es5 people then add a prepublish transpiler that makes something like this possible:
// es6 people can do
var foo = require('foo');
// es5 people can do
var foo = require('foo/es5');That means there need not be a split in the ecosystem: people who want maximal coverage can target ES5, while people who want the latest features can target ES6. Unlike the browser, however, where people can't control their runtimes, I suspect there will be much less tolerance for sticking with older versions of JavaScript.
Indeed, the pain and suffering people have felt with IE6 will likely make everyone much more willing to reject an unnecessary lowest-common-denominator approach on the server. We're liberated on the server. Let's act like it.
I'm liberated on the server in my own app, but not necessarily if I'm publishing something for everyone to use. In that case I'm either forced to feature-detect my way along, or target certain engines. The reason I think the latter will happen is devs to whom node was an escape-hatch from client-side hell will loathe the idea of going back. E.g. [1]
[1] https://twitter.com/brianleroux/status/554753200503271424
Though I'd imagine this will not hold true with addons, seeing as there are vastly different versions of the V8 engine.
I don't think so. People publishing libraries in ES6 are asking for trouble. There are far too many half-complete ES6 implementations out there and compiling to ES5 definitely is the way to go (for libraries) unless there's a really compelling reason not to.
EDIT: I don't think anyone is going to be sympathetic to holding back from using conveniences because people are choosing to stick with an old runtime. It's a different ballgame than the browser.
Example: I wanted to use the WHATWG streams code. But then I realized that they used an ES6 subset that is currently only compatible with traceur. The result: I had the choice between patching the code or downloading traceur, compiling the library, somehow get traceur out of it, and then require the resulting file into my otherwise fully working ES6 environment. I take a nice, tested, ES5 version any day over that experience.
(*) I hope you add such a paragraph when your library relies on a global require hook that changes the default behavior of require for all .js files in all libraries.
I've never run into issues with the CoffeeScript require hook, for example.
will it impede functionality? probably not. will it add precious time to server process start time? definitely, especially if the problem gets compounded.
(I say this as a member of the TC39 committee in charge of the ECMAScript standard.)
Also, when do we go back to one executable already?
...but if node wont play ball, it'll become 'the new node', yes.
(there's a lot of backstory to this, which you can read about here: http://blog.izs.me/post/104685388058/io-js)
I couldn't resist: https://github.com/npm/npm-expansions/pull/245/files
$> diff <(node --v8-options | grep harmony) <(./iojs --v8-options | grep harmony)
1,6c1,18
< --harmony_typeof (enable harmony semantics for typeof)
< --harmony_scoping (enable harmony block scoping)
< --harmony_modules (enable harmony modules (implies block scoping))
< --harmony_proxies (enable harmony proxies)
< --harmony_collections (enable harmony collections (sets, maps, and weak maps))
< --harmony (enable all harmony features (except typeof))
---
> --es_staging (enable all completed harmony features)
> --harmony (enable all completed harmony features)
> --harmony_shipping (enable all shipped harmony fetaures)
> --harmony_modules (enable "harmony modules (implies block scoping)" (in progress))
> --harmony_arrays (enable "harmony array methods" (in progress))
> --harmony_array_includes (enable "harmony Array.prototype.includes" (in progress))
> --harmony_regexps (enable "harmony regular expression extensions" (in progress))
> --harmony_arrow_functions (enable "harmony arrow functions" (in progress))
> --harmony_proxies (enable "harmony proxies" (in progress))
> --harmony_sloppy (enable "harmony features in sloppy mode" (in progress))
> --harmony_unicode (enable "harmony unicode escapes" (in progress))
> --harmony_tostring (enable "harmony toString")
> --harmony_numeric_literals (enable "harmony numeric literals")
> --harmony_strings (enable "harmony string methods")
> --harmony_scoping (enable "harmony block scoping")
> --harmony_classes (enable "harmony classes (implies block scoping & object literal extension)")
> --harmony_object_literals (enable "harmony object literal extensions")
> --harmony_templates (enable "harmony template literals")The hell? Seems it's intentional:
https://github.com/iojs/io.js/issues/251#issuecomment-694177...
It was not my post and I care less about being downvoted and more about the problem that some people seems to prefer downvoting to explainating.
Downvoting, -in my opinion, is for things like redditism, clear breach of site guidelines etc. It is not for being uninformed (within reasonable limits) and certianly not for asking reasonable questions.
An ironic statement given that one of the main motivations for io.js is to upgrade to the new awesome versions of V8 with all of its great new features.
V8, of course, has always been "corped": it was created and is maintained almost entirely by Google.
> Is it io.js or IO.js or iojs or IOjs or iOjS?
> The official name is io.js, which should never be capitalized, especially not at the start of a sentence, unless it is being displayed in a location that is customarily all-caps (such as the title of man pages.)
Version 1.0.1 (Beta stability)
A bunch of people are unhappy and fork the project, and make the initial version 1.0, but make a point of saying (despite not using a related version number/identifier) that it's beta.
Realistically it sounds like both projects should be at v0.9.x.
Declaring something as 1.0 means that any 1.X releases are going to be backwards-compatible with the 1.0 spec.
This is objectively different than versioning something 0.X, which implies that the baseline spec is not finalized.
Calling something "Beta", however, just means that a feature-complete major version is still being actively developed (i.e. new minor features and bugfixes).
In other words "1.0 Beta" just means "Stable spec, active codebase".
EDIT: confusing if the intention of the iojs team was to have the querystring actually mean something... they may well not have that intention, in which case meh :)
If the api is fixed and its just bug fixes before release why isn't this 1.0.0-beta or -rcN, with a 1.0.0 (a vanilla version is always considered higher than one with an identifier like "-beta" or "-rc1"
But apparently "beta" equals "stable" to these people.
Node 0.12 was always being referred to as 'pretty much the 1.0 API', not calling it 1.x.x was a kind of 'get out of jail free' card in my opinion. So i'm glad the iojs team have least drawn a line in the sand and declared their API stable.
>How do I know when to release 1.0.0?
>If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
ls -l /usr/local/bin/node
lrwxr-xr-x 1 502 staff 4 Jan 13 20:10 /usr/local/bin/node -> iojs
I'm wondering, what technical reasons are there for Node not using the latest version of v8 for each release? I can understand Node keeping some new ES6/7 features behind a flag (just as some are behind a flag in Chrome).
There is a compatibility layer to assist with making these modules work across different V8 versions: https://github.com/rvagg/nan
https://github.com/joyent/nodejs-advisory-board/blob/master/...
Why the symlinking as node?
Let's say that ES6 will provide a better runtime that may make transpiled languages less useful. Yes, ES6 does arrow functions and classes but it also provides many more cool stuff that the transpiled languages may never support such as generators if they intend to keep backward compat to older browsers. If you are in this case you should bet on ES6. If you don't care and are happy with what's included in coffee, use coffee ! You can always compile it to JS and continue your project with ES6 !
To sum up, transpiled languages are not dead and are still way more flexible than vanilla JS (as they don't depend on a big specification such as the ES specs) but ES6 does improve the runtime, and one day transpiled languages may use this new runtime.
For manual deployment, the single iojs binary and your project folder should suffice, along with a way to start/restart your app automatically.
EDIT: To clarify, though I haven't tried it myself, it looks like you can just specify `"engine.iojs": "1.0.0"` in your package.json, and Heroku will install the entire io.js system for you.
(screencast: https://twitter.com/HunterLoftis/status/555234067520565249)
We're also excited to see node hit a 1.0 and merge in new V8, ES6 features, etc. I'm especially excited about Cluster's round-robin load balancing which has been a compelling reason to use 'unstable 0.11' for a while.
By any sane logic any release after 1.x should be considered stable UNLESS otherwise stated.
This is why we have the concepts of things like "dev", "alpha", "beta", "rc" (release candidate) identifiers for versions.
Nowhere does io.js use any of these terms except in that homepage. So now, anyone relying on any other source to get the product either as source or in a binary package has no way to know if it's considered "stable" yet.
So what I want - basic common fucking sense is what I want. Nobody in their right mind would release software marked as version "1.0.0" with full knowledge and even the barest of acknowledgement, that it's only beta quality.
The explanation I've seen so far is that the people behind the fork are sick of NodeJS never reaching 1.0 despite being used in production. Sure thats a good reason to make it 1.0 - because a heap of cool kids have jumped on the bandwagon and bet their business on it, it must be stable right?
Oh wait, but then they admit that it's only beta quality. So they want it to be versioned as if it's appropriate to use it in production, but they know its actually not.
In this scheme, version number is not an indicator of stability.
> Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
It also allows for identifiers/metadata after the version eg 1.0.0-alpha or similar.
It also specifically says:
> Version 1.0.0 defines the public API.
> "This package will install io.js v1.0.0 and npm v2.1.18 into /usr/local/. The binary /usr/local/bin/iojs will also be symlinked as /usr/local/bin/node."
Go to reinstall nodejs, and that install says a later version is already installed and cancels the install without giving me an option to install anyway.
Also, good to see bnoorhuids in there.
Node.js uses MINOR even = stable, odd = unstable (which is not semver) and is still in 0.x even though it's been used by giants in production all over the world for a couple years.