>Node was created by software developer Ryan Dahl
as a way of building and running entire online applications
with JavaScript—the standard programming language for writing
code that runs in your browser.
> The massively popular programming framework Ruby on Rails,
for instance, is still sponsored by its creator, a company called Basecamp.
[1]: https://www.youtube.com/watch?v=lBfVxBj61z0&feature=youtu.be...
And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mozilla, then Node doesn't use that anyway :p
> I thought that they intentionally choose javascript because it doesn't have any features like threading.
I wanted to point out that JS doesn't preclude parallelism, it's just implemented as async calls. It would be more correct to say the runtime owns the thread pool. Thanks to other commenters for making the distinction.
> Really? I thought that they intentionally choose javascript because it doesn't have any features like threading.
So I'm wondering if Node.js, Io.js or both will embrace coroutines, yield and generators. The real danger of threads was always shared memory, not so much simultaneous execution. I'm hoping that we'll start to see Go, Erlang and even shell-style piping of data through predictable, testable and debuggable threads of execution begin to replace callbacks.
If anyone has a general approach for converting callbacks to use coroutines and yield in Javascript, I'd be very eager to hear it. Also the problem of how to enforce scope in Javascript, to prevent sharing state between coroutines.
In this case, we see sort of an "arab spring" of open source projects lately. Consider MySQL after it was bought by Oracle, and then the MariaDB fork was born. Now we have Node.js and Docker being forked. Until now, most successful communities have been monarchies or oligarchies, whether it was Linux or Python. Corporate sponsorship played a big role. But if more headless or democratic communities succeed, it will be interesting to watch. PHP is an example of a more headless community, and it used to be all over the place.
There are two ways politics and internet interact. One way is how the tools we use affect our society in meatspace and the other is how we organize online in cyberspace.
> Why not just fork Docker?
> From a security and composability perspective, the
> Docker process model - where everything runs through a
> central daemon - is fundamentally flawed. To “fix”
> Docker would essentially mean a rewrite of the project,
> while inheriting all the baggage of the existing
> implementation.But what were seeing with Node along with the other examples from the post you're replying to is that so long as the source is freely available, the core developers and the community is what's important. There was a quote in yesterday's thread that 95% of Docker contributors don't work for Docker, Inc. This means that Docker, Inc will need to walk a tightrope between over-monetizing their platform, pissing off the 95% of contributors from outside Docker, Inc and under-monetizing it, pissing off their investors. If they try things that lock people into the platform and force them to pay for other Docker products, you'll see the developer community rebel with an actual fork of the Docker codebase. This is exactly what we're seeing here with Node...Joyent's stewardship of the project is being seen as lacking and the people who are really important, the core developers and the community are taking a proactive step to remedy that.
It think we're nowhere near the point where this will happen to Docker, but this should be an object lesson for Docker, Inc about what can happen if they try to push too much of the Docker, Inc agenda into Docker, the open source project.
I think the most interesting aspect of this is the cross-disciplinary nature, when analyzing something like the Internet and information technology through the lens of a different field, politics. The way politics presents itself and interacts in this field (much like other fields) is a whole area of study itself.
In the long run, they need to make decisions for the company that are not in the best interest of the project, and either the project dies or is forked or abandoned.
Sun did really well by the OSS community for a very long time, but they had nothing to show for it and Oracle has since foisted a lot of their efforts on to the ASF. LibreOffice, hhvm, Mint, just to name a few, have all come about because the companies responsible for the stewardship of a project weren't doing their duty in the eyes of the community. I honestly think we're going to see a Firefox fork in the next 2-3 years.
It's just the nature of OSS and while it means that, long-term, fewer companies will invest in the space, the companies that do invest will do it for the right reasons.
Who is going to fork it? The active contributors that are employed by the Mozilla Foundation? Google? Microsoft? Opera? Some currently peripherally involved third party?
And what will the goals of this fork be? To be more focused on something other than producing a standards-compliant, multi-platform, performant browser?
There are already semi-forks (downstream distributions that continue to pull from upstream and are mostly synced, but also maintain distinct and divergent feature sets) -- both GNU IceCat is an example (Debian Iceweasel I think is less so, because IIRC it is synced but for branding with upstream.)
Are there convincing number of examples of very popular projects being forked and both ends being discontinued, or is this just a typical example of spreading FUD?
Forking is a natural process in the open-source world.
Whatever the outcome, this is absolutely eyeball-grabbing FUD. A popular open source project, by definition, has identified "job(s) to be done" and has attracted an audience of supporters (users and developers). That's what keeps any project afloat. In long-term, a big project fork is a sign of a healthy community. That community occasionally has to come to grips with the evolution of their software. For a fork, this is usually a combination of social and technical dynamics. In the short-term, it's hard to see past the difficult (and occasionally acrimonious) social mechanics.
Future of Popular Coding Tool Unclear After It Splits in Two
It's frustrating to get invested in a product if you know that it's got stagnant parts that nobody seriously plans to fix in the near-term at all.
It has very strong growth in Google trends:
The use cases for a single-threaded web server are specific and limited in the real world. Node.js will continue to solve those use cases (simple web server for static content or I/O bound apps) but the resultant decline will lead some to believe that the framework is dying.
All of those node services have since been rewritten in Go by the formerly-pro-node people. Go has been much more manageable and powerful.
I can't help but wonder how much of this is a power struggle between Strongloop and Joyent.
I'd probably reject this too from a do-gooder searching github for pronouns to change.
"Get another hobby. Rejected."
It's bad enough that I have to use browserify to get working features in the browsers... I shouldn't have to do that for a leading edge server-side JS platform in the development version. Don't get me wrong, still love node, and JS is very effective, just the same, I'd rather not have to require in libraries that should be baked into the engine at this point... or writing shims to make for an easier transition.
co/koa are over a year old now... developed against features that still aren't in the supported release... prior to 0.10, v8 had been kept very close to the edge... it's now over a year behind.
"it has to do with developers getting really frustrated at the stalled pace of development on the Joyent branch"
is so hard to understand? Cuz this gets incessantly repeated in a calm, rational manner by people involved with the branch.
This is an advantage it shares with other new languages like Go that had good concurrency support from the start. Go has the same advantage with goroutines. All code written by the community since then uses goroutines.
Compare this to python and java which had better concurrency bolted on long after those languages were released. Twisted is basically node.js for python and it existed for a long time before node.js. But one of the main problems with Twisted is that all other existing python code is not written in an async way. A python dev could use Twisted, but as soon as they get some useful library form PIP, it's probably going to block and ruin the whole async.
Java has a similar issue. It was released with heavy threads as the only way to handle concurrency. There have been attempts to try to bolt on async and lightweight thread models. But there is a massive existing ecosystem of java code. None of that will work well with async and no one can rewrite all of it to use some new lightweight thread model.
This is the advantage of a fresh start like node.js or Go. Wheels will be reinvented, but it will have improvements that can't just be bolted on later.
The biggest flaw with node.js right now is that it came too early. If it came out with ES6, it would be a much better ecosystem. If generators/yield had existed from the start, all the callback mess could've been avoided. However, although the callbacks were an unavoidable mess, it did fundamentally force async on the ecosystem. NPM libraries like co show a migration path to the generators/yield future for older node.js code. The IO.js fork should use this opportunity to put something like the co library into core and push generators/yield as the way forward. If Joyent was the cause of the delayed generators/yield support, then they have done great damage to the node.js ecosystem. Node.js should've heavily promoted generator/yield use as soon as it was in V8, not hide it behind a --harmony flag for over a year.
Why Elixir - http://www.theerlangelist.com/2014/01/why-elixir.html
http://nodejs.org/api/child_process.html#child_process_child...
The new contributors: https://github.com/iojs/io.js/graphs/contributors
Joyent really fucked up.
Is that naivete on the side of Io.js here, or is there more to the story?
> the team hasn’t actually set up this foundation because they’re still hoping that Joyent will let them to use the Node.js trademark.
Frankly, I kinda like the name Io.js better than Node.js
Well, if it was for a project that was implementing Io [0] on top of JavaScript, sure. For a server-side JS stack based on V8, I don't really like the name at all.
http://compositecode.com/2014/12/05/im-so-mad-my-response-to...
I'm pretty sure he's right, nothing to freak out about.
I think that the confusion around Node.JS versus IO.JS will persist for some time though. If I wasn't a regular HN reader, I would have missed this completely.