[lomnakkus]

One place where it makes quite a big difference is in the standard library. In scala the standard library is very often just a thin shim on top of the JVM equivalent... which means that scala.js needs to shim the JVM library. It's not a huge deal in that most everyday things pretty much work out of the box, but if you're using a lot of time/date manipulation (via Joda-Time or the JDK8 java.time package) you'll have to use something else on the JS side.

[gavinking]

So, that's a good example: ceylon.time is implemented in pure Ceylon, and is totally cross-platform.

[justthistime_]

Why is reinventing the wheel considered a good thing?

javax.time is considered by some to be one of the best, most well-designed general and versatile libraries for date and time related matters out there, regardless in any language.

How would things be improved by throwing that away, and inventing something different? I think keeping the API and providing an implementation for Scala.js is a much more reasonable approach.

Designing a date/time requires very rare skills and knowledge that most people lack. A re-implementation of javax.time means all the documentation, tests and existing code can be re-used and allow correctness checks against the existing implementation.

[lomnakkus]

> Why is reinventing the wheel considered a good thing?

It's not. There just is no shim for java.time currently! Even worse, there could be licensing issues[1].

EDIT: That, and some of us are unfortunately still on JDK7 until the next Ubuntu LTS. Not that that's scala.js's fault, but it's a practical issue.

EDIT: ... and of course having a duplicate implementation of java.time (JDK + the shim-which-is-basically-a-reimplementation-in-JS) could be considered "reinventing the wheel"! :) If you have to reinvent the wheel, then doing it such that it at least behaves completely consistently across all backend platforms is preferable, IMO.

[1] https://github.com/scala-js/scala-js/issues/1618

[justthistime_]

As mentioned in the ticket, the original implementation is BSD.

Your last point is not the only thing that matters though. If the runtime already ships with packages X, there is no point in shipping your own implementation.

(Which is exactly what Scala/Scala.js does with math stuff: it reuses BigInteger from the runtime on the JVM, but ships its own implementation with Scala.js.)

[lomnakkus]

Right, but the JS and JVM runtimes have quite different behavior. And I'm willing to bet that implementing something as non-trivial as java.time again in Scala(.js) will end up causing quite a few bugs because they aren't identical.

That's why I'd rather have a single implementation for anything non-trivial and just retarget that to each backend using more low-level primitives. After all you're using a different language -- using a different date/time API shouldn't be much of a problem.

[justthistime_]

Yeah, inventing an API and implementation of a date/time/calendar library from scratch without an existing spec, implementation, tests or experience will surely be totally bug-free.

[lomnakkus]

I'm not sure why you're being sarcastic.

I'm not saying it'll be bug-free. My point is that it'll have exactly the same bugs on either platform. This may be preferable to having different bugs on different platforms.