Question about #5: are you also considering this to be server-side
Node.js developers?
I'll take a stab at breaking this down. Admittedly, this is much harder
than I thought it would be, so consider these numbers as order of
magnitude indicators more than anything else:
Monolingual non-library users: 5%
Monolingual library users: 57%
Multilingual library users: 25%
Library developers: 10%
Web service developers*: 3%
If Node.js developers are grouped into this category, then I would
expect this number to grow.
A word of caution that I usually throw out in API discussions: I think
it's a mistake to design an API with the intent that a library will
smooth out the interface for you. IMHO, core language features should be
usable out-of-the-box.
-N
On 11/28/2011 12:09 PM, Norbert Lindenberg wrote:
Looking at the feedback we've received on the Globalization API, it seems at
least some of it is based on divergent assumptions about the developers who are
going to use the API. Maybe we should step back and define the different
developer groups we want to serve. Here's a first cut:
1: Developers of simple monolingual applications, using ECMAScript and DOM APIs
directly without assistance from libraries. May need precise control over
formatted strings in the language of their application.
2: Developers of simple or somewhat complex monolingual applications, using
libraries such as jQuery, Dojo, YUI to wrap and enhance ECMAScript and DOM
APIs. May need precise control over formatted strings in the language of their
application.
3: Developers of complex multilingual applications, using libraries of course.
May be willing to trade off precise control over formatted strings for support
of many languages.
4: Developers of libraries. Need well-specified behavior of underlying
ECMAScript API so that they can support both groups 2 and 3.
5: Developers of web services. Similar needs to 4.
Are there any groups missing or mischaracterized? Also, can those of you who
interact a lot with developers try and attach percentages to the groups? The
ratio between groups 1 and 2, for example, could drive the decision whether we
need default locale management in the standard API or whether we can lean on
libraries to provide this functionality.
Thanks to Nicholas, who pointed out that we may have been focusing too much on "the
big boys", group 3.
Norbert
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss