1. 13
  1.  

  2. 7

    So, I’ve been working with some in-house legacy C/C++ extensions to Node over the last year and a half, and it’s one of the reasons I’m looking forward to getting away for it where I can.

    First, working with V8 is a pain in the ass. The documentation is not very good, and without other code to go on much of it is a mystery unless you dig through the (well-commented) source files.

    Second, there is a lot of “typical C++ bullshit”. A decent amount of templates and sometimes great pain taken to obscure what the hell is actually going on. For example, walking an object’s properties or printing out string values is actually a bit annoying. With C++14 lambdas, it might be possible to make it less ugly, but for now it’s just such a sad impedance mismatch coming over from JS land.

    Third, the entire idea of moving heavy objects across the thread boundary is troublesome. Basically, the JS VM in V8 manages its own objects through a GC. That’s fine, and expected, and all is well and good. But actually transferring objects into a background worker? Nyet. You have to do all of your marshaling/unmarshaling in the main thread, barring some poorly-documented shenanigans with isolates and everything. So, in the main thread thunk that schedules the libuv task, you need to move from the JS object to whatever struct or class instance you will use for professing, and pass it over.

    The first couple of times you do this, you’ll suddenly realize why you want to stay in the warm bosom of JS as much as possible if you can, because the alternative stinks from both a performance and implementation perspective.

    Fourth, actually deciding how things work is a bit odd. V8 lets you do some really weird things with the state of the JS VM. It’s not clear how you should handle, say, exceptions.

    It’s just bad.