Cesium: Externalize widget HTML

[mramato]

This has been on the to-do for a while, but we don't have an issue for it. Rather than generating HTML bindings programattically in widget code, we should just have an external html file which will be much easier to and read and maintain. We would then require in the HTML file at runtime and also process it out as part of the build.

CC @shunter

[mramato]

So I was going to look into doing this at our code sprint next week, but I'm concerned it might bite us in the future when we move to ES6 module syntax (because ES6 doesn't seem to have a way to import text/data like other module systems can). Perhaps it's possible but I just don't know about it.

@shunter or @kring any thoughts?

[kring]

Well, you're not going to send actual ES6 modules to the browser (at least not for awhile), so you're going to have a build process of some sort. Presumably whatever build process you go with can deal with importing text, right? Worst case you can hack something up to turn HTML files into JS files containing the HTML as a string, and then import those string modules in the normal way. You'll need something nearly identical for the GLSL anyway.

[mramato]

Me and @shunter were talking about this offline today and the idea was floated to have the dev server convert glsl/html to js ES6 modules on the fly. We could then switch over to SystemJS, which I believe can load ES6 modules. This would give us "build free" development.

For release, we would create something like a Build\Modules directory with transpiled UMD modules that can be used with almost any loader system. We would also produce glsl/html ES6 modules in place in the source directory so that hose that want to use ES6 modules directly could. We could also have the Modules include the built workers instead of modularized version (since they are only meant for end-users). The end result should be greatly improved compatibility with existing loaders and build systems.

Any reason you think that approach won't work?

[kring]

This would give us "build free" development.

Sort of. The dev server would be "building" the GLSL and HTML the fly. Also, SystemJS, if I understand how it works, is going to do horrific things like parse your JavaScript at load time in order to figure out what ES6 modules you're trying to use so it can go load them. In some sense, that just means you're running your build process in the browser. Maybe it'll be super fast and that'll be fine, but I doubt it. I think an actual incremental build process running ahead of time would give you much faster cycle times. And it would let you use any web server. Don't fear the build process. :)

For release, we would create something like a Build\Modules directory with transpiled UMD modules that can be used with almost any loader system.

I don't really know who would use these. Loading individual modules in a real app is a terrible idea. And if you're using RequireJS or Browserify or Webpack or probably most anything else, plugins will let you load the ES6 modules directly.

[pjcozzi]

@mramato is it worth keeping this open?

[hpinkos]

Whenever we get a chance to refactor and clean up our widgets, we should definitely use an HTML file to define the view instead of doing everything programmatically in Javascipt. It'll be a lot cleaner and will make it easier to debug. I would keep this issue open.