Another fact about to consider IMHO: Libraries can be fat in pure Elm thanks to the efficient dead-code elimination in 0.17 -- if a function is not referenced in your code, or the code you call, it will not be exported -- while the native parts of them is only left to something like closure or uglify. So, it is better to have pure elm libraries, and their raw size is only relevant if you use all the features.
On Sunday, June 19, 2016 at 10:31:22 PM UTC+2, Dan P wrote: > > I realize elm-date-extra <https://github.com/rluiten/elm-date-extra> exists, > but it's bloated, (apparently) unstable, reproduces working JS APIs, and is > not likely to be merged to core any time soon[1]. I'm considering making a > simplified fork of the former, but this rejected pull request > <https://github.com/elm-lang/core/pull/214> gives me pause. Can anyone > more familiar with the Elm ecosystem please advise? > > [1]: Not to say that it doesn't also provide useful functionality! But > core.Date is a little spartan, don't you think? > > > On Sunday, June 19, 2016 at 3:03:51 PM UTC-4, Dan P wrote: >> >> (e.g. Date.setDate() in JS) >> >> Or would a pull request not be in vain? >> >> Compare: >> http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Date >> >> >> https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date >> >> -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
