Remove all React and JSX

[ongardie-sfdc]

This isn't used widely anymore, and it's a rather large dependency that should be removed. Existing code needs to be ported to d3 first, however.

[ongardie-sfdc]

Over on salesforce/runway-model-elevators#1, @joelburget wrote:

I agree with the desire to remove big dependencies, but what I don't understand is why it's necessary to bundle d3, react, or any other rendering library. I'm much, much more likely to use runway if I can use react. Anyway, I don't think it makes sense to be prescriptive, rather you should encourage users to bundle whatever libraries they need.

I'm guessing the reason for pre-bundling dependencies is to enable dynamic loading of code from github using browser-require, etc. That's a valid point in the design space, but it restricts library use, and my version of safari fails to load https://runway.systems, because let was used. Bundling with webpack / browserify is an extra step, but avoids both problems.

I guess some rendering library needs to be built-in to runway-browser for its own use: for the timeline and other such widgets. It probably makes sense to pick a reasonably good library for this, and to expose that to models for convenience.

I'm not set on d3 for this, but it's my current preference. If there's something clearly better, we should migrate runway-browser to that instead of d3. @joelburget, out of curiosity, why is React so appealing to you?

Then there's the bit about not being prescriptive: good idea. https://runway.systems is a mode of operation that I definitely want to keep, but developing locally or bundling a model along with runway-browser make sense to me too.

• Can models today use webpack/browserify to build in unsupported libraries and still be loaded on https://runway.systems? That requires a build step so it's not as easy, but that's something.
• For https://runway.systems, we could probably pull in React and other hand-picked libraries dynamically for models. It can already fetch remote JS files from the model's repo. Though not trivial to support, that would help avoid the build step above, at least for common libraries.
• For "local" use, how would you bundle together runway-browser with one or more model? I'm still new to webpack.

Supporting Safari/old browsers isn't necessarily a goal, but relevant to this discussion is: what steps do you take to get your models to run at all under Safari today?

[joelburget]

Can models today use webpack/browserify to build in unsupported libraries

Absolutely. The idea is that webpack can bundle all files leaving no external dependencies.

what steps do you take to get your models to run at all under Safari today?

I use babel (as a webpack transform) so my ES 2016 / jsx is transpiled down to js that every browser can understand (bye, let). It's magic.

For "local" use, how would you bundle together runway-browser with one or more model?

I need to think about this. I guess I need to better understand the interface between runway-browser, the model, and the view.

Unfortunately it's hard to get around bundling everything ahead of time. But I'll think about it.

By the way, I just had the thought -- have you thought about the security implications of dynamically loading models from github?

[joelburget]

why is React so appealing to you?

Because it's more general in some ways than d3, and much easier to write / understand for me, especially for nontrivial views. This isn't public yet (don't share), but I'm about to release some thoughts on React + d3.

[ongardie-sfdc]

By the way, I just had the thought -- have you thought about the security implications of dynamically loading models from github?

Models get to run Javascript, so they might try to attack your browser, show you things, or phish you. It's generally equivalent to visiting a malicious website, except that you might place more trust into the runway.systems domain. Modules from untrusted repos currently get a modal confirm dialog. Here's an example: https://runway.systems/?model=github.com/dgryski/modelchecking/master/runway/river. Is that what you had in mind?