Cljc.java-time will drop all npm/foreign-lib dependencies

Hello, this is a heads up that I am planning to drop the npm/foreign-lib dependencies (npm library ‘js-joda’ & related) from https://github.com/henryw374/cljc.java-time and would like to hear any feedback anyone has at this point.

Doing this should mean that other Clojure(Script) libraries which make any use of dates and times could now depend on cljc.java-time library because:

  1. There will be no transitive dependency headaches for users (ie excluding foreign-libs if you have a :bundle cljs build etc)
  2. End users will benefit from dead code elimination: If they are not using part of a library that uses cljc.java-time, then nothing of cljc.java-time library will be included in an advanced optimization cljs build.

IOW, cljc libraries that need to use dates (even if dates are not the main focus of that library) can depend on cljc.java-time and get a banana without a gorilla holding on to it.

… and being cross-platform and using java.time on the jvm, I hope cljc.java-time could become the de-facto platform time library for Clojure and Clojurescript.

Of course https://github.com/juxt/tick and any other end-user-focused date-time libraries that depend on cljc.java-time will benefit

How will this work?

I am creating a custom build of the js-joda source that results in a single js file that does a goog.provide() - ie something cljs compiler treats as native.

In order for the jsjoda addon libs (timezone & locales) to work they will also need custom builds.

I am assuming here that no one is using any js libraries that are using jsjoda - but if you are please shout. If people are then I could provide an option to use cljc.java-time with npm dependency instead.

The downside for me is that each release of jsjoda that people want will need a new release of this custom build. However, since jsjoda just replicates java.time and that is stable, I don’t expect that many releases.

There is a new platform library for JS in the works, ‘proposal-temporal’, but I decided it is best to focus on the custom-jsjoda approach for now since:

  1. it may be years before proposal temporal is fully ready
  2. jsjoda lib is still openly considering deferring to proposal-temporal method/objects when it is ready - ie jsjoda does the mapping to java.time so cljc.java-time doesn’t have to

I am not sure how long until the new version of cljc.java-time will be ready, but weeks rather than months hopefully.

FYI I have gratefully received some funding from Clojurists Together for this work.

6 Likes

Why is the library called java-time ? Perhaps simply cljc.time is better right ?

it’s called that because it has the same api as java.time, just with namespaces instead of classes and functions instead of methods

I just wanted to pull this out and say it made me laugh out loud (and my wife also thought it was a pretty funny image!). Thank you for brightening up my Friday!

As for the changes, they sound good. We are still using clojure.java-time at work but I have been considering switching to cljc.java-time since it is closer to plain ol’ interop in structure and we already use direct interop with Java Time in a lot of places so it would be less jarring to use (than clojure.java-time).

2 Likes

As a follow up to the post above:

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 https://github.com/tc39/proposal-temporal/issues/1079.

Further reading:

Thanks again to Clojurists Together for funding some of this effort.

The first time I heard this statement was Joe Armstrong from Erlang:

I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.

From the book Coders at Work

2 Likes

news update:

fyi - my blog from a while ago on java.time vs Temporal -
Temporal (Javascript's new Date-Time API) vs java.time (JSJoda on JS runtimes) – Henry Widd's Blog – Widd Industries which is
now a bit dated wrt ZonedDateTime

3 Likes

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.