NoJS Mode

[wohali]

@janl:

I’ve hinted at this above, but I’d really like a way for users to use CouchDB productively without having to write a line of JavaScript. My main motivation is the poor performance characteristics of the Query Server (hello CGI?). But even with one that is improved, it will always faster to do any, say filtering or validation operations in native Erlang. I don’t know if we can expand Mango to cover all this, and I’m not really concerned about the specifics, as long as we get there.

Of course, for pro-users, the JS-variant will still be around.

@wohali says:

We're getting closer to this with the native Chakra work being worked on by @davisp, and the subsequent deprecation of features like list/show that are difficult without the cgi-bin model.

Also see #666.

[detroitenglish]

...I’d really like a way for users to use CouchDB productively without having to write a line of JavaScript.

It would seem strange to me for a database advertising itself as "built of the web" to divert development resources away from the fundamental programming language of the web. As I understand, the use of JavaScript in CouchDB is actively promoted as a web-centric feature.

Understandably, the performance hit from ol' SpiderMonkey must put a damper on that 'feature' for many. But considering work on Chakra is already well underway, perhaps it's best to wait for those benchmarks before deciding if a No-JS mode is worth pursuing?

[wohali]

@detroitenglish This is not about removing JS entirely from CouchDB. NoJS mode would be entirely optional, not the default. It's about ensuring enough base functionality works without JS to make it a useful option. I think there's some interesting use cases for it.

It's more about security and system performance than CouchDB performance in this case. (It's worth noting that with dirty schedulers in Erlang 19+, NIF code that is CPU or I/O intensive plays more nicely with the Erlang scheduler than a pure Erlang system does, but it's can't ever be as good as pure non-dirty-scheduled code.) Heavily memory-constrained and scheduling-critical environments like embedded and real-time systems, or an embedded CouchDB in a larger Erlang application, are candidates for this mode.

You can try to run NoJS mode today by disabling the couchjs query server in 1.x or 2.x, but certain things like the _users database's VDU are hardcoded as JS right in our source code (see #1146) so core functionality like simply adding a user breaks. Problems like that are what this ticket is tracking.

You obviously lose any JS-based design document functionality too (views, , but at least with 2.x you have Mango to give you some of that back. Other tickets are tracking enhancing CouchDB to allow things like VDUs and update functions to be written declaratively - see #1554 for example.

[detroitenglish]

@wohali Thank you for the background on this. It makes sense with your context now, even more so with the design priorities you lay out in #1534. This issue could otherwise be misinterpreted as a core contributor highlighting another core contributor's performance frustrations and consequent desire to put JS on the back-burner (and referencing issue number 6-6-6, which I find hilarious).

Seems there are a lot of tough decisions to be made right now, but imo the future looks great e.g. #1554 is a really cool concept... and one hell of a shower-thought!