Consider a different, perhaps more browser-friendly architecture

[ragulka]

First, thanks a lot for this module. It has no doubt been a lot of work!

Consider this as a discussion from someone who does not fully understand the motivation or rationale behind the current architecture.

As I understand, if I want to use inter in the browser, I need to build a different version of it for each locale. If I use a single locale in my client-side app, that works just fine. But when I need to use 2 different locales at the same time, I will probably get into trouble. Why? because I need to load the FULL logic + data both times.

Wouldn't it make more sense to separate the logic from data so that loading multiple locales in the browser (say 2-3 at a time) will be a lot lighter?

[papandreou]

As I understand, if I want to use inter in the browser, I need to build a different version of it for each locale. If I use a single locale in my client-side app, that works just fine. But when I need to use 2 different locales at the same time, I will probably get into trouble. Why? because I need to load the FULL logic + data both times.

Yes, that is correct. The files in the build directory (built with buildInter --type node) are sort of an afterthought -- I figured it was an easy way to get it to work in node. What I'm actually doing in web apps is buildInter --bundle --locales en,da,nl... plus the switches for the stuff I need in that particular app. That produces a single .js file with the inter code followed by:

if (LOCALEID === 'en') {
    inter.dateFormats = ... // code that adds all the English data
}
if (LOCALEID === 'da') {
    inter.dateFormats = ... // code that adds all the Danish data
}

... which is the (huge) inter.js I'm using while developing. In production I use assetgraph-builder with the --locales to produce separate versions of all switch to bundle up all the JavaScript code and produce a single JavaScript (and HTML) file per locale the app supports. Part of that process is substituting the LOCALEID global with the correct value so that UglifyJS will constant fold 'en' === 'en' to true and 'da' === 'en' to false etc., then proceed to remove all the data that's not needed for that particular locale.

However, that process doesn't fit everyone's setups and localization strategies, and it certainly makes sense for inter to not to be tied to a specific build system when used in the browser.

Wouldn't it make more sense to separate the logic from data so that loading multiple locales in the browser (say 2-3 at a time) will be a lot lighter?

Yes, it might. I've been thinking about how to approach this for a while.

My wish list:

• There should be a single build target that works for node.js and the browser, including support for require.js
• The actual code shouldn't need to go through a build step, only the data. It's really annoying to have to run buildInter all the time while developing and testing
• The division into modules should still be fine-grained enough that you can produce a sufficiently stripped down version of the library (with only the parts you actually need) when it has to be sent over the wire or processed by a build system

I also hope to find a way to sort of declaratively point to a file that only pulls in the data for a specific locale. This is something I'm fiddling around with in relation to assetgraph-builder, which could support something like:

require(['inter/' + LOCALEID], function (interForTheCurrentLocale) {
});

... but that should probably be a secondary concern.

[ragulka]

Thanks for the thorough response! I completely agree about a single build target and separating concerns (data vs logic). The only "build" step required for the logic (main lib) would be minification then.

Have you looked at how moment.js handles this? I did take them as an example and re-wrote Numeral-js for my own purposes (you can see my fork here: https://github.com/ragulka/Numeral-js/tree/cldr. Currently, only et.js has been updated because I didn't find an easy way to extract data from CLDR (which is why I am also checking out your projects!).