Load individual modules on demand

[natefaubion]

Rather than serving and loading a giant bundle. Depends on #127

I can rewrite the module fetch in PS, but I thought I'd go ahead and throw this out there. The expectation is that you'd serve the psci output folder. This includes a barebones require shim which loads modules on demand. Perhaps we could host more libraries in that case without having to resort to different backends.

[natefaubion]

I've rewritten the loader in PS.

[natefaubion]

I've made a few opinionated choices and improvements.

The biggest change is removing backends. Since we are loading modules on demand, we don't really need to maintain separate backends for the purposes of compiling and serving a bundle. One thing that backends accomplished was setting up shims for FFI dependencies. I've added shim resolution in it's place. In the Try.Shim module there is some basic config for shimming react. When these dependencies are required it will automatically insert CDN urls for the libraries and link them according to the shim. This means loading stuff like purescript-react or purescript-react-basic "just work".

We could add other shims like big-integer or whatever if we want to support other libraries with FFI dependencies.

The other thing backends do is setup a TryPureScript module, but these can just exist as modules in the package-set we use. This can be namespaced like TryPureScript.ReactBasic and it can export utilities for getting started, and we can link to other gists for "backends" from the main gist.

I've also fully sandboxed the iframe. Though which libraries are available is still vetted, this pulls in arbitrary JS. A fully sandboxed iframe means session information can't leak out of it it since it has a unique origin. This is done through postMessage instead of writing HTML to the iframe.

[natefaubion]

I've simplified the FFI shims. They are just loaded from unpkg and eval'ed like the PS sources, so no global script shimming is required.

I'm pretty happy with this so far. @paf31 what do you think about this? There are a few things to consider:

• This expects all compiled sources to be available individually. We could definitely just have the server serve the psci output directory. I'm not sure how you deploy it though, and whether you would want to do it through the backend server, or if you have a reverse proxy you can configure to statically serve it. Alternatively, we could precompile the package-set and bake it into gh-pages so GitHub can serve it.
• Right now this requires no changes from the backend, at the expense of dynamically resolving dependencies in the frontend. This can result in a slow initial load. These resolutions are cached though, so subsequent compiles are fast. We could potentially have the backend send all transitive module names though so we could fetch everything in parallel.
• We can optimize the initial load by going ahead and bundling the core modules into a JSON blob which is loaded at startup. This means we wouldn't need to dynamically resolve dependencies for anything in core.

[hdgarrood]

I like the approach, and especially being able to do away with backends. I think starting by serving a compiled output directory as static files sounds good. I think just getting something working should be the focus for now; we can worry about optimisation later I think. @gabejohnson would you like to have a go at taking the contents of this PR and applying them to master?

[gabejohnson]

Sure thing! I can take a look at it over the weekend.

[hdgarrood]

Resolved by #136