-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NoJS Mode #1513
Comments
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? |
@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 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. |
@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! |
@janl:
@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.
The text was updated successfully, but these errors were encountered: