Set up JavaScript build

[travisbrown]

I hacked this together as an experiment this afternoon with J2CL, and it's not too bad—a few Bazel build files, some minimal implementations of java.net and java.nio stuff, and (the worst part) rewriting all instances of String.format.

You can try it out from a web console here.

I think we should at least consider publishing JavaScript artifacts from here. On the "do it" side:

• Compiling dhall-core and dhall-parser to JavaScript ended up being much smaller than I expected: J2CL / Closure gets a module that exports parsing, normalisation, and type-checking down to 240K. For comparison, the current GHCJS-built JavaScript used on dhall-lang.org is 6.6M minimised (this isn't a direct comparison, since dhall-core and dhall-parser don't provide import resolution and the GHCJS build does, but the difference was still a little surprising to me (25-30x)).

On the "no" side:

• Living without String.format is really annoying.
• I don't know if anyone would actually use something like this.

If someone can come up with a single real use case for this I'll clean up my branch and open a PR. I'll also need some help with packaging, etc.—I've essentially not used JavaScript outside of the context of Scala.js for at least a decade.

[f-f]

@travisbrown I saw your tweet and got really excited - Dhall is missing any kind of JavaScript story so far, and it's a fairly big problem IMHO (i.e. this prevents all usecases where one would like to throw Dhall on the wire between server and frontend)

So I think having a decent transpiled version would be a good start - as you noted the GHCJS is way too big to be included in frontends.

A few questions after playing with the version you hosted:

• it looks like parse/normalize/etc return string - idiomatically I'd expect them to return JS objects instead?
• would it be possible to plug import resolution at any point?

[travisbrown]

@f-f Okay, I'll go ahead and start a PR for this. To address your questions:

• Yes, we can definitely make the JavaScript API a lot nicer—I just didn't want to sink a lot of time into the experiment yesterday in case I ran into issues that made it fundamentally impractical, or in case the generated code was too big (let's say within an order of magnitude of the GHCJS output, in which case I'm not sure there'd be much of a point in continuing).
• Yes, we could definitely add import resolution, although that's probably further off (since the current dhall-imports implementation is built on http4s, which doesn't publish for Scala.js), and is likely to require more custom JavaScript. I wouldn't want to take lead on this, but I'd be happy to help.

You think 240K-ish isn't too much to be practical for frontend applications?

[f-f]

@travisbrown thanks for the great news! :tada:

I think 240k is totally fine - I wonder if we can reduce it further with minification and if the Closure output would be happy to be minified, etc.

I'd also be available to give some amount of help with this (well, I don't know anything about Scala, so I'd be only useful on the JS side)

[travisbrown]

@f-f The 240K is already the "production" output of J2CL, so while we might be able to trim it a bit through configuration and narrowing down what's included in the Bazel build, I don't think it's getting much smaller.

I don't think we'd want to use Scala for import resolution here (it's just what we're using in dhall-imports, which we're treating as a kind of reference implementation for now). My guess is that since Google Closure doesn't support anything from java.net, we'll want to write the import resolution part as JavaScript (or TypeScript / PureScript) directly.

[joneshf]

I mentioned in the Slack channel that I was thinking about starting a TypeScript implementation of Dhall. I was pointed to this project, and saw this issue. This is really neat!

What's the end game here? Do you plan to continue improving the JavaScript implementation you've started here, or is this mostly an experiment to see how far you can get? If you're planning on making this the JavaScript implementation, I don't really want to start a different one. I'm not committed to doing it either. But, don't think we both need to try our hands at it.

[travisbrown]

@joneshf I think it'd be great to have a native, not-mostly-transpiled-from-Java TypeScript implementation.

I was planning to more forward with this, but I probably wouldn't have had time to work on it for a month or two, and I have very little experience with TypeScript or modern JavaScript, so it would likely take a while. This was really just an experiment—in particular I maintain a few libraries with Scala.js builds and I was curious to see how J2CL compared to Scala.js.

Please feel free to reuse anything you could use from here. I don't really know what's usual in the JavaScript / TypeScript OSS license world but I'd be happy to discuss relicensing if needed.

[travisbrown]

(As a side note, I've been slowly working on a new parser implementation using a LALR parser generator instead of JavaCC, mostly to avoid stack-safety issues with the recursive descent approach, and also just because I think parsers are fun. The Java artifacts are much smaller than the JavaCC ones, and I'd guess with that approach the JavaScript build would be more like 180-200K than the 240K here.)

[joneshf]

Coolio. Thanks for the information! I'm still debating whether I'll actually do this, but it's good to know what you're thinking.

I think MIT/BSD are fairly common in JS. I'd probably start from scratch, though. I've not done any bigger projects in TypeScript and want this to be a learning experience :).