couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 16:25:42 GMT

On Jan 31, 2013, at 17:23 , Benoit Chesneau <> wrote:

> On Thu, Jan 31, 2013 at 5:19 PM, Jan Lehnardt <> wrote:
>> On Jan 31, 2013, at 17:14 , Benoit Chesneau <> wrote:
>>> On Thu, Jan 31, 2013 at 4:35 PM, Jason Smith <> wrote:
>>>> On Thu, Jan 31, 2013 at 3:06 PM, Benoit Chesneau <
>>>>> wrote:
>>>>> Here are some notes following your *enthousiast* mail. There is not
>>>>> intention to diminish the work or things like it. It is intended to
>>>> temper
>>>>> a little this enthousiast and trying to find the right approach on the
>>>>> problems we are trying to solve.
>>>> Totally! Like I said, I would never use this code in production. It is a
>>>> highly experimental branch. I have a roadmap for this branch; but the
>> real
>>>> goal is conversation.
>>>>> On Thu, Jan 31, 2013 at 3:46 PM, Jason Smith <>
>> wrote:
>>>>>> On Thu, Jan 31, 2013 at 1:51 PM, Randall Leeds <
>>>>>>> wrote:
>>>>>>> On Thu, Jan 31, 2013 at 5:23 AM, Jason Smith <>
>>>>> wrote:
>>>>>>>> On Thu, Jan 31, 2013 at 12:55 PM, Paul Davis <
>>>>>>>>> That whole process sounds like not a lot of fun.
>>>>>>>> Right. That is kind of my point. CouchDB is a JavaScript
thing, and
>>>>>>>> nowadays people have a very well-adopted and well-understood
>>>>> JavaScript
>>>>>>>> engine on their computers. Maybe it should just use that.
>>>>>>> (Some) developers have node installed (or can install it easily).
>>>>>>> users are a totally different story. They may be able to install
>>>>>>> but we're talking about adding a runtime dependency unless we
>>>>>>> node.
>>>>>> Quite right. This branch answers half that question: what do you
>>>>>> So far, this is my list of good things I've seen:
>>>>>> 1. Better code.
>>>>>> 1a. Cut almost 3,000 lines of code
>>>>>> 1b. Exchanged SM build dependency for Node runtime dependency. This
>>>> right
>>>>>> here--this summarizes the whole exercise.
>>>>>> 2. Very encouraging degree of compatibility. Consider, the 1,500
>>>> of
>>>>>> view server JS code: none of it was ever intended for Node.js. But
>>>>> test
>>>>>> suite shows, the two are virtually identical.
>>>>>> 3. Apparently this is already easier to use than homebrew. Homebrew
>>>> pins
>>>>>> SM apparently to support Mongo (unsure if the latter is true).
>>>>>> 4. Got a lot of enthusiasm. (A lot of people tested it and emailed
>>>> ask
>>>>>> "why isn't it faster?"). This thread got a lot of feedback about
>>>>>> protocols, and async APIs, and app-building features. Why? I think
>> when
>>>>> you
>>>>>> say Node.js and CouchDB everybody says "Yes!"
>>>>> I say "maybe". nodejs is quite trendy. but also quite new and didn't
>>>> really
>>>>> prove anything right now. It is quite surpassed by a pure C thing like
>>>>> nginx/uwsgi when it's about http, and when it's about stability by
>> erlang
>>>>> or some. I also never had any need of nodejs when it was about doing
>>>> things
>>>>> with couchdb. Differerent approach I guess. Not saying the nodejs is
>>>> bad
>>>>> one. If it solves your problems or at least is easier for you to handle
>>>>> then that's perfectly fine.  One true thing is that javascript is
>> really
>>>>> user friendly and this thing is the one that count.
>>>> I agree about the "trendy" concern. That is part of the cost, for sure.
>>>> I am not sure what point you are making, about the http stack and
>>>> stability. I believe a pure-node view server can meet your performance
>> and
>>>> stability requirements.
>>>>> About the number of lines. Well you don't count all the lines in
>>>> nodejs+v8
>>>>> as well ... but the number of loc isn't really an argument I guess.
>>>>>> Imagine you have CouchDB installed and then a future node version
>>>>>>> breaks compatibility for some API used by the node-couchjs. You
>>>>>>> have to decide whether to upgrade node or try to have multiple
>>>>>>> versions so couchjs can continue to work.
>>>>>>> In short I think this is my issue: we're pushing problems down
>>>>>>> maintainers and packagers to users.
>>>>>> If you want API stability, then you'll like Node.js. The whole
>>>> principle
>>>>> of
>>>>>> the project is to be "finished" one day.
>>>>>> Node.js is less likely than Python, say, to break a simple, 300-line
>>>> repl
>>>>>> program. (My point is: not likely.) But yes, you've put your finger
>>>>> it.
>>>>>> This is a runtime dependency.
>>>>> This has nothing with the langage. Considering that a lot of big system
>>>> are
>>>>> running under python. You can also write a view server in python in one
>>>> day
>>>>> as fast as the nodejs server using libuv for example.  or other
>>>> eventloops
>>>>> that didn't wait nodejs to exist.
>>>> Awesome. Please show us a view server written in Python with libuv,
>>>> completed within one day. That will be very informative to this
>> discussion.
>>>> We can look at all the working, real-world view server implementations,
>> and
>>>> we can compare them.
>>> I wish i had time to play with that. The point is that javascript or
>> nodejs
>>> don't change anything. What are advantages of nodejs on a pure technical
>>> aspect:
>>> - v8 for javascript
>>> - libuv for everything else
>>> if you do it in python then you have python and pyuv. Doing the things
>> you
>>> did was the same. Though I don't see the point of having fibers. I think
>>> what you want here is a TCP or UNix socket to allows request to wait and
>>> handle them in a parallel way. It would also remove the number of OS
>>> processes.
>> Today, CouchDB supports JavaScript for the sole reason that it is most
>> widely distributed, developed and exercised programming language and
>> that the JS required to us CouchDB is little enough to not be scared of
>> it if your main language is another. This hasn’t changed since we started
>> this. JS also gets the most engine development of any of the languages
>> even outpacing Java, but that’s an aside.
>> There is no argument to be made that a Python or Ruby or whatever else
>> is technically similar or potentially even better. We don’t support these
>> today.
>> To be absolutely clear, if a year from now we support all of them, that
>> be super duper fantastic in my book, really and honestly.
>> But that is not a situation that we are in today, so asking how this is
>> better than a Python server is easy to answer: because Python is not JS.
>> Best
>> Jan
>> --
> I didn't say python was superior or that I wanted a python version. I
> don't. I am all for having JS in couchdb.  I was answering to jason
> argument. Javascript has nothing to do with performance or ease of code.
> And like I said the true thing is that javascript is really user-friendly
> and  has an awesome community that support it.

Cool, thanks for clarifying, I must have gotten the context wrong!


View raw message