NodeJS: To V8 or not to V8 | Hacker News Reader

NodeJS: To V8 or not to V8

olympum.com

36 pointsfosk18 comments

This is a stale nothingburger. Summary:

Bruno: "V8 was not designed as a server-side engine, but as a browser-based engine. Furthermore, V8 was designed squarely to run in Chrome’s multi-process model. As much as I think V8 is a brilliant piece of engineering, it’s software that was not designed to run on a server."

Jason: "I don’t know what this means, or if there’s a difference. More details here would be helpful."

Bruno: "The discussion is not really whether I have technical production problems or not with V8 (within NodeJS); all software has bugs. My issue is about project governance. ... It’s not whether Google’s V8 project is open or not, it’s that since governance of V8 may become a problem in the future, it requires a solution now so that large organisations can put their full weight behind NodeJS."

No idea what sort of patch Bruno is looking for and I don't think Bruno knows either. He's sure not articulating his concern very well.

At NodeConf Summercamp this week Ryan Dahl remarked that the V8 team is very responsive and happy to fix to reports such as "this part of V8 is slow and shouldn't be, can you please make it faster".

He also acknowledged that Google is obviously building V8 for Chrome and not Node and shouldn't be expected to spend time and money on features that aren't beneficial to Chrome. One example of this is the time required to spawn a new V8 context, around 30ms. It could be made drastically faster if all security features were removed from the V8 boot process (not needed for server side trusted execution environments) but Google needs secure VMs for Chrome tabs and it wouldn't make sense for Chrome to spend time optimizing V8 for this use case.

I didn't get the feeling, however, as this article implies, that V8 is a "roadblock" for Node.

Creating a new V8 Context when V8 is compiled with snapshots is ~2 ms on a decent hardware. But it's still too long for node.js needs: the idea was to create an isolated world per request.

Yes, you can spawn a context faster if you strip out the duplication and make Contexts share built-in objects. But then you remove the only important feature Contexts have --- isolation and you don't really need them.

[Another important thing here: in the browser each iframe has a different Context. You can't really abandon isolation --- that would lead to spec violation and massive security holes]

The main item I seem to recall Ryan Dahl and others commenting on was V8's garbage collection which is pretty laze because web pages don't stay open for long periods of time. Obviously this is different on the server. If true, that's pretty deep change inside V8 required for Node.

There are a public issue tracker and v8-users mailing list.

If somebody is experiencing problems with GC then they should stop by and ask or file an issue or submit a benchmark/testcase...

Interesting that creating a context in V8 is so slow. I use JavaScriptCore in a desktop application, and creating a new context using JSGlobalContextCreate() takes something on the order of 1-2 ms on a MacBook -- anyway small enough that I don't need to care about starting lots of contexts.

V8 is a great technical achievement, but sometimes I wonder if its reputation as "the fast JS runtime" isn't more due to Google's excellent Chrome marketing (remember the Scott McCloud comic?) than actual measurements. JavaScriptCore is no slouch either, and is easy to integrate into applications with its plain-C API.

This is an old post. Google has continually improved v8 and those improvements have helped Node.js in the process.

I think the hoopla over Node.js using v8 or if it shouldn't has died down and for good reason.

What about when v8 is discontinued to promote Dash?

Unlikely.

But if that happens, Google isn't the only company in the world with the knowledge and ability to maintain V8. Joyent does as well.

But let's assume something even more unlikely: Google, Joyent and the rest of the world drop V8. nodejs is an open-source project.

You might as well worry about being hit by lightning.

v8 is a very successful project for Google. It is running their browser which has quickly become one of the top 3 and is continuing to increase in users.

Even if Google did abandon it, there are plenty of people interested in it, and want to keep it running. Joyent said themselves that if needed they will fork v8 to keep it sane and right for Node.js.

My summary:

Bruno: "Node is doomed as V8 was not designed as a server-side engine. We must panic now"

Jason: "There is no need to panic now. Once we finish Node v1 we will start modifying V8 to make Node more awesome. We are not scared to fork if need be"

What alternatives exist in the server side JavaScript space (that are actively maintained and used by HN readers)?

Depending on what you want to do, Riak is a NoSQL database that uses javascript for map/reduce.

erlang_js is a competing javascript VM (embeds spidermonkey)

And I'm working on a new web platform based on Riak that allows the developer to write their apps in coffeescript and I use erlang (and parts of riak) to distribute the load around a cluster of machines each of which is running multiple javascript virtual machines. (But this is not yet released... follow @nirvanacore on twitter if you wish to keep up to date.)

Is there a public repo we can peek at / contribute to?

Not yet. I'm working on the "simplest thing that could possibly work" version, that sets out the architecture. I'm hopeful that, when its released, it will be compelling enough that people will want to jump in and help me build it out. But at this point, it would take too much explaining to get the idea across. Once the simplest thing is done, I'll be able to ship it with a simple demo/tutorial which will hopefully be setting off lightbulbs above people's heads.

In case anyone else is getting deja vu here, this is from way back in february.

There seemed to be some backlash when Mozilla started experimenting with a SpiderMonkey-based NodeJS implementation. I'm not sure why. It seems like it would be a really good thing to be able to run Node on other JavaScript engines. Having options is a good thing.

This is a real problem, if you're from the school that believes that processes can crash. But it is also an issue if you believe it is possible to overload a single process on a machine where multiple processes could better handle the load. Nodejs runs a single v8 instance on a machine, or if you're running multiple ones in parallel they don't really cooperate as they aren't really aware of each other. So, if one gets behind its hard for the others to take up the slack.

Here's a concurrent answer to this problem, that a future nodejs version might consider adopting (and is the basis of the nirvana web platform I'm building):

Distribute requests across a series of javascript virtual machines running on a collection of compute nodes. Multiple vm processes per node, and multiple nodes per cluster.

Thus, if any one V8 process dies for whatever reason, you don't lose many requests.

In fact, I believe losing even one request due to the crashing of a V8 process, would be considered a bug.

My solution to this involves using erlang at a fundamental level to distribute load, and passing the requests off to various instances of a Javascript Virtual Machines to handle the requests. The web developer writes their application in coffeescript or javascript, and the platform takes care of distribution, concurrency, etc.

The downside of this, of course, is that given that js isn't a really concurrent language, there is a bit of an impedance mismatch... but I find that this is equal to or less than the hassle of dealing with event driven code in the first place.

If you're interested in my solution, we should hit alpha soon after Riak (the underlying platform) hits 1.0 later this month. Follow me on twitter for updates @nirvanacore (that twitter account only talks about the web platform, no noise.)

Reply on news.ycombinator.com