google Closure-ify js-joda and add as a :lib in this library

[henryw374]

this might be a better alternative to proposal tempora (see #11 )l: the api already matches and it is available right now.

this would involve a source transpilation of js-joda. not totally sure how feasible, but if it can be done, it shouldn't be too much work.

if it can be done, I don't see any tech blockers to this lib becoming accepted as the core time lib for the clojure ecosystem

ideally then, the locale api would use the in-built Intl api, not js-joda locale packages. tz db could be optional and DCE friendly - if you know ahead of time what zone info you want

[henryw374]

posted fuller plan for comment: https://clojureverse.org/t/cljc-java-time-will-drop-all-npm-foreign-lib-dependencies/6208

[henryw374]

Having put significant time into making js-joda amenable to Dead Code Elimination, I have decided to shelve the effort for now. The reasons for this are:

My experiments show Google Closure does not fully eliminate unused js-joda code in many cases. I guess it can’t analyze the code well enough and has to play safe. If the cljs app doesn’t use js-joda at all, then none of js-joda is included, but that’s not the extent of DCE I was hoping for.
The js-joda add-on libs (timezone and locale) would need to be completely reworked to be DCE friendly - and I’m not 100% sure that’s possible. If that couldn’t happen, end users would probably have to juggle :exclusions to choose npm or non-npm js-joda - not great.
Temporal is getting closer to reality - maybe shipped in some browsers in 2021? see tc39/proposal-temporal#1079 7.
Further reading:

js-joda PR: js-joda/js-joda#463 4
comparison of Temporal to java.time: http://widdindustries.com/ecma-temporal-vs-java-time/ 5