Exposing window.Intl directly also ties Elm more tightly to the browser/JavaScript environment, which Evan mentioned in that second linked thread that he is trying to avoid:
Elm is designed to be 100% independent of JS. It happens to compile to JS > now because that was the right thing to do, but in a decade, I expect we'll > be compiling to something more efficient. There is a small set of "native" > stuff for now, but that means supporting the entire ecosystem on a new > platform is fairly easy. > So Elm could currently use window.Intl, but that would mean its functionality would have to be replicated exactly if Elm ever compiles to a non-browser environment. Even now that would make life a bit more difficult for people using Elm code within Node applications - it's possible, but you have to do things like hook up a third-party XMLHttpRequest implementation like xhr2 <https://github.com/pwnall/node-xhr2>. If it's not too hard, it's probably better to reimplement the functionality in pure Elm so that it can be used on any platform that Elm compiles to in the future. On Saturday, 9 September 2017 10:49:31 UTC-4, Vlad GURDIGA wrote: > > Hey everybody! 👋 > > The other day I found myself writing a function to format numbers > <https://github.com/gurdiga/xo.elm/commit/eac3cb6b92823b9876053c4034de92d307812503#diff-96f92701886b3e767cf8eef9ccf8d9ceR21>. > > The first question was: What is the right way to format a number? There > should be a standard or something. 🤔 Googled a bit and found about the > Unicode CLDR Project <http://cldr.unicode.org/>. They have a huge amount > of structured data, and I surely found the data I was looking for. 🤓 > > Now, seeing all that data, I thought: Wow! Wouldn’t it be cool to have an > Elm library that’l hold all that? elm-cldr? 🎩 Oh, it’d be enormous… What > if I only need number formatting? Oh, I know: elm-cldr-numbers! > and elm-cldr-dates! and elm-cldr-localenames! and… Ooooh yeah!! 🤠> > Then I remember that the CLDR website was saying that they provide data > for apps and operating systems. Hm… shouldn’t it be there already somewhere > in the OS? 🤔 Googled a bit more and found that browsers already have that > as window.Intl > <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl> > and > MDN says it has quite good support, down to IE11. Couldn’t believe that > one, so spun up my Windows VM and pasted a snippet into IE11’s console: it > worked! 👽 > > Hm… OK… Now, it’d really be quite cool to build all those elm-cldr-* > things that I imagined, wouldn’t it make more sense to reuse what’s already > there? What would it be like to use that? OK, let’s go native! A couple > hours later I got myself Native.Intl > <https://github.com/gurdiga/xo.elm/commit/26c5046e9942433cd8f663bd04c18f1ccb6838ee>. > > 😎 > > Now, looking at all this I begun wondering what would it be like to have > it in the Elm standard library, and inevitably found Evan’s 2 threads (one > <https://groups.google.com/forum/#!topic/elm-discuss/DPuUPv72abc> and two > <https://groups.google.com/forum/#!topic/elm-dev/1JW6wknkDIo>) about the > philosophy around native in Elm, and I kind of see his point about keeping > Elm high-quality, but how about cases like this where we’re not talking > about JS libraries but about browser’s native APIs like Intl? 🤔 > > It’d probably be not that hard to get that data > <https://github.com/unicode-cldr/cldr-json> packaged into a few Elm > libraries, hopefully not-that-large each, but it’d still end up growing the > final app bundles, and probably some compilation time during the hundreds > of refreshes a day that a dev does…😳 So I’m not entirely sure it’s a > constructive idea. 😶 > > So although for my little toy-project I can just use Elm native, how about > long-term? What would make more sense? I mean these two options: > > 1. implement Elm libraries using the CLDR data > <https://github.com/unicode-cldr/cldr-json> > 2. hope that window.Intl will some day become part of Elm standard > library > > What are some pros and cons? Are there any other options people have > considered? 🤔 > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
