Melding Node.js into Chrome (or vice versa)

[Benvie]

I'm specifically referring to running them as a single unit, with a single message loop and implementing a single responsibility point for important context/thread issues so it can act as a single javascript host environment while providing the API's and bindings of them combined.

I keep having the itch to integrate closer and closer here. The WebKit and varied APIs brought in for browser usage are a pretty awesome yin to Node's file/stream/net/data/etc. yang and it seems realistic to make them one in the same. I've spent a good chunk of time with the internals of Node and of Chromium and CEF and I feel I have a pretty good of what's involved (while at the same time being a comparative noob as I have have a webdev professional background where which has different concerns most of the time).

Generally speaking, they're fundamentally compatible in the sense that the most sensitive/important component is V8 and the excruciatingly carefully curated environment and context(s) exposed to JavaScript. Chromium offers are lot more beyond that scope but it's also largely stuff already ignored and less useful when you get to the point where CEF is (pare it down to the stuff specifically for rendering the webview and providing bindings for JavaScript to do stuff) and this is about the same point we want for node. Using Node, we'd want probably ideally pare it back some more to remove any extra functionality that Chromium provides which node already does better, but that will be limited as Chromium needs a lot of specific stuff to support heavy native dependent tasks like GPU rendering.

The way the surrounding and supporting environment is constructed is different between the two and speaks to the different purposes they serve, while at the same time remaining fundamentally compatible because they are limited by the same fundamental requirements and limitations. You see the same object wrapping, refcounting, thread limiting, etc. as these are mostly limitations/conventions imposed from V8 on everything else. It's a safe bet that this biggest barrier to cross-implementations with other types of applications is basically non-existent here.

The most useful and likely implementation of this (as I can tell from my limited mastery of the subject) would have Node's normal processes uses as the application baseline. The lifecycle of node is built around the perspective of a programmer using it as a tool to build other tools applications, and this is much more flexible and adaptable than the angle Chromium comes from. This would also involve some curtailing of some of Chromium's extraneous activities (which I think CEF has already mostly taken care of anyway) with the ultimate goal of keeping its responsibilities tied to tending the webviews, the minimal native window the web views live on, and I/O directly needed or requested in service of webview actions.

The likely tricky parts come in handling their somewhat different usage of threading. Node doesn't really have the concept of a UI thread because it's not necessary, but I'm pretty sure that doesn't matter except that any thread checks will have to be implemented on anything from the traditionally Node side that gets the go ahead to venture from the basement into the UI .

I would imagine that the simplest route for ease of implementation and security is in not adding too much extra goodies to anything in the webview/ui context. As it stands, Chromium already does all its cross-thread communication via message passing, so a lot of mind has already been paid to being careful. It will more be able just making sure Node is set up to use those same paths.

In my mind, ideally we could also make some extra use of Proxies/WeakMaps that are now making a strong showing in recent versions of V8 to allow us to implement safe-but-still-fluent pathways between the realms to facilitate the real fun: mixing and matching capabilities from both worlds. Using node's mastery of data to fuel powerful and attractive UI's, or the massively awesome tight integration of many types of media that WebKit/Chromium provides for building dynamic and interactive set pieces, but integrated with using Node's expressive data interface in propagating amongst many users across varied interfaces.

I'm curious about learning what may be the gotchas here that I may not be thinking of. I don't think it will necessarily be easy, but it seems to be well in doable range, especially with CEF as a starting point for Chrome, being already stripped down to the necessary pieces.

[Benvie]

Oh and another thing of note is that it'd probably be preferable to follow Node's general strategy in binding and whatnot. Essentially it implements the minimum necessary APIs, wrappings, interfaces, etc. needed in C++ and hands of to JavaScript as quickly as possible (or JS2C as it were). The basic concept is that if you're doing stuff from the JavaScript context you're being protected by default from all those scary nasty things you explicitly are doing ni C/C++. (that of course being the whole point you did that, the JS is talking through that safety later). But the point is that by this level all the checks are transparently handled and specifically can't be bypassed in purpose or by mistake. Not to mention it's just easier to do most things in JS which is why we use higher level languages, and we take the small (for most things) hit to performance in exchange. If you need something to be top performing then that thing gets natively implemented and then wrapped ASAP for use from javascript.

On a more general level I see this as the usefulness of pairing Node with Chromium. Think of Chromium as a representation of a super-sized native wrap that gives you an integrated GUI, audio, video, and graphics binding. The stuff it handles largely does fall under the "needs to be as fast as possible" label and Chromium of course provides admirable performance. Then we come along with our easymode javascript bindings and skip the line to just get the reward without the pain.

The node angle can be seen from either side. From Chromium it' can be seen as bringing in a powerful and well-tested and heavily used module system allowing developers to easily build applications in a functional, building block, monoid sort of way. And it comes with a default set of modules that are pretty much best of breed for handling data aand communication, both in performance and in amazing simplicity and fluency. JavaScript's take on the server, so to speak, is well represented in Node's combination of power and ease of use. But these tools are obviously useful outside of the context Node is usually found.

From the Node point of view we can see Chromium as a best in breed all-in-one GUI, media, and human-oriented communications megamodule. All things that node doesn't even have basic stand-ins for. Looking at Node with Chromium as an available module quickly redefines the scope that it feels obvious to use it in. Node is already infinitely more useful than its most used set of webserver related tasks. JavaScript seems to naturally provide for tools that have a wide scope of use. This is true of all the dynamic languages to varying extent, and Javascript most of all. JavaScript was built from the beginning and mostly used for essentially running a program on the Human thread and that doesn't change when you take it out of the browser. Javascript is nothing if not in tune with the humans using it, because has always been its main reason for and primary mode of living in a way that isn't true of any other programming language.