Live data from Hacker News

Node.js, a popular tool for building modern internet services, has split in two

wired.com

121–130 of 166 posts

Re: Node.js, a popular tool for building modern internet services, has split in two

#121

Earlier quoted context omitted.

It's a widely held misconception that JS doesn't have threading. User code executes in a single thread, but asynchronous tasks are managed by a thread pool (libuv in node). Because the multi-threading is hidden with asynchronous calls, the user doesn't need to worry about it, which is why many people say JS is single-threaded. In fact worker threads execute async tasks behind the scenes; it's a very nice feature of t…

You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language. And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mo…

Well, there are Web Workers, which are basically threads. http://www.html5rocks.com/en/tutorials/workers/basics/

But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.

Re: Node.js, a popular tool for building modern internet services, has split in two

#122

>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. Really? I thought that they intentionally choose javascript because it doesn't have any features like threading. > The massively popular programming framework Ruby on Rails, for instance, is still sponsored by its cr…

While I think abandoning threading was originally a good move because it spawned (no pun intended) new methods of chaining callbacks together, I'm concerned that there is really no way out of callback hell by way of callbacks.

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.

Re: Node.js, a popular tool for building modern internet services, has split in two

#123

Earlier quoted context omitted.

You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language. And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mo…

Well, there are Web Workers, which are basically threads. http://www.html5rocks.com/en/tutorials/workers/basics/ But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.

That's because it's a Web platform API, not a language feature.

Re: Node.js, a popular tool for building modern internet services, has split in two

#124

Earlier quoted context omitted.

> I honestly think we're going to see a Firefox fork in the next 2-3 years. 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.)

https://www.waterfoxproject.org/ as well -- a 64 bit version.

And another, Pale Moon: http://www.palemoon.org/

Re: Node.js, a popular tool for building modern internet services, has split in two

#125

Earlier quoted context omitted.

Off topic, I guess, but color me unimpressed by the guy claiming he would fire someone for rejecting a pull request that does nothing but advance a political agenda.

Color me impressed, because the political agenda that's being advanced is gender equality in technology, which to me seems pretty worthy.

Problem with that situation was that the Joyent guy was commenting on Noordhuis, an employee of a direct competitor to Joyent. So to many it came off as political opportunism to screw with Strongloop and not a sincere evaluation of the situation.

Re: Node.js, a popular tool for building modern internet services, has split in two

#126
post #55

Earlier quoted context omitted.

Just wait 5 years they'll be re-written in Swift, Dart, Rust (other shiny new thing). The important thing is, it will probably be the same people doing it ;-)

Really? Dart?

Is that not cool anymore. What's the next "cool" thing?

Re: Node.js, a popular tool for building modern internet services, has split in two

#127

Earlier quoted context omitted.

You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language. And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mo…

Well, there are Web Workers, which are basically threads. http://www.html5rocks.com/en/tutorials/workers/basics/ But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.

Web Workers are closer to "processes" in the Erlang sense of the term. They're walled off fairly extensively from the rest of the JS runtime that spawned them because that is pretty much the only good way to backport threading onto a language that wasn't designed with it in mind from the beginning.

Languages like C which had them bodged on years later, well, I'd call that a bad way to do it. It worked for the time but there's a reason why we are all fleeing that implementation of threading and it still stains the entire idea of "multithreading" decades later.

If JS is ever going to get threading, the best case scenario is for it to look like Perl or PHP's efforts... years and years of implementation work to get to something that pretty much everybody recommends you still just stay away from. And Perl and PHP were trying to integrate threading into just one runtime each, and without a browser connected at the hip with its own ideas about threading embedded into decades of code. I would not hold your breath for "true" JS threads anytime soon.

Re: Node.js, a popular tool for building modern internet services, has split in two

#128
There is a big advantage to node.js that used to be mentioned a lot in its early days, but not much now. The advantage is still there, but it's only noticeable if a developer has experience in other server languages. The big advantage is that node.js had an asynchronous development model from the beginning. This caused all the code written since then to also be written using async. When a node.js project imports other libraries through npm, there is no need to worry about some random synchronous code blocking. All code is written using async because that's the way it was enforced from the beginning.

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.

Re: Node.js, a popular tool for building modern internet services, has split in two

#129

>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. Really? I thought that they intentionally choose javascript because it doesn't have any features like threading. > The massively popular programming framework Ruby on Rails, for instance, is still sponsored by its cr…

While I think abandoning threading was originally a good move because it spawned (no pun intended) new methods of chaining callbacks together, I'm concerned that there is really no way out of callback hell by way of callbacks. 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 tha…

Thing is, if you want Go- or Erlang-style piping of data, well, Erlang and Go are right there... and both written from day 1 to support those use cases, rather than bodging them onto a language ten years later....

Re: Node.js, a popular tool for building modern internet services, has split in two

#130
post #53

I think it's great news. Node development has been glacial for a while now. There's an issue where people are sharing logos, https://github.com/iojs/io.js/issues/37 , highly recommend.

Better visualization: http://tableflip.io:1234/

Nice link! Check this one instead of mine if you haven't done so.
Post reply on HN