On 12/7/2012 4:39 PM, Norbert Lindenberg wrote:
On Dec 7, 2012, at 6:18 , Benjamin Smedberg wrote:
On 12/6/2012 9:21 PM, Norbert Lindenberg wrote:
The benefit is that the ECMAScript Internationalization API lets developers
create a more consistent localized experience for their users, with the correct
date, time, and number formats, the culturally appropriate calendar, correct
currency symbols, and correct sorting. It also helps avoid latency by removing
the need to send lists back to the server for sorting.
Is it possible to self-host this functionality in JS? Would it make more sense
to just build this functionality as a JS library?
I discussed this in the paragraph that you cut off:
I think you misunderstood. I was suggesting that the functionality we
require be part of the browser and implemented in JS. That would really
only affect the "code" weight, not the "data" weight, but since C++ code
weight affects the number of initial pages in memory, that could still
be significant. And I imagine that a JS library performing those
functions might be significantly smaller than the equivalent binary code
weight.
And the other messages in this thread discuss ways that we could spread
out the download weight of the data tables after the initial
installation to reduce the costs, or even make them download-on-demand.
Does the API allow for the possibility that a sorting algorithm may not
be immediately available?
This is really basic infrastructure that for native applications is provided by
the OS and for web applications should be provided by the browser.
We still need to weigh the cost of this "basic infrastructure" against
its value or the alternatives. Having a client-side sorting algorithm is
basically a performance optimization, though a significant one on slow
networks.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform