>
>
>> The idea is that an imperfect (but okay) component system that get used
>> widely and pervasively is infinitely better than even a perfect one that
>> nobody uses.
>
Agreed. How many times must I cite Richard P. Gabriel's "Worse is Better"?
>> XPLC thrives toward simplicity and efficiency, so that
>> there are NO EXCUSES for someone not to make some component (in the
>> largest sense, like a DLL library) an XPLC component.
>
Ok, but how many other projects are using XPLC? /me goes to read your
advogato post.
> Here is a comment from Braden I would like to highlight:
>
>> This is directly related to the relatively low level of community
>> reuse of mozilla.org's code.
>
Mozilla code turns up in lots of places. I'd like to see "relatively
low level" quantified and compared to other open source projects of
similar relative youthfulness. I'm skeptical. I'll tangle with braden
in a separate post.
>> Developers right now have to jump
>> through some serious hoops if they want to leverage mozilla.org
>> libraries. JavaScript isn't too difficult, but it's still harder
>> than it should be.
>
Yes, it is (I speak with some authority on JS), but it's not harder than
many, many other open source projects. The Mozilla JS engines are used
by dozens of small to large companies, by my count.
For some reason, I'm still doing a lot of work on JS, but I can't do
everything. Rather than throw small stones, could you and braden help?
Or did I or norris, or others involved with the Mozilla JS engines, do
something to scare away contributors?
>> As for NSPR, XPCOM, and Necko... Well, the
>> initial investment required is high enough that many developers
>> will simply dismiss these potential solutions.
>
I cry foul. NSPR is much more mature, documented, and widely used than
XPCOM and Necko. You chose to highlight braden's wrong-headed (but not
all wrong, half-truths are like that) claims, so I'm asking you to
justify them, too. I'm ready to rumble with braden, in a followup to
his post.
/be
