Standalone vs non-standalone

[Rich-Harris]

Having zero runtime dependencies is really nice – it makes the generated code easier to follow and more versatile. Optionally, though, it might be good to offer builds that reduce code duplication – for example, the observe code is the same everywhere, and there are a few DOM helpers that could live externally.

[Swatinem]

It would be nice to have a mode that outputs just the generated code for dom manipulation (create, update, teardown), so the user can choose whatever state management library they would like (eg. mobx)

Not sure how that would best interact with nested components though.

[evs-chris]

Looking at progressive enhancement, I think it would be particularly useful to have a little bit of library code that could handle walking through the existing DOM to find a valid target and get it into the correct state.

[Rich-Harris]

I've been thinking it'd be good if the compiler had an externalHelpers: true mode that build tools could opt in to (i.e. you probably wouldn't want it for a standalone widget you were shipping, but it definitely makes sense for an app).

The same could apply to methods that don't differ between components, e.g. observe and the events stuff. (Though at that point you'd need to store callbacks under this, obviously.)

Basically, what Babel does – marking which helpers are used then either injecting them or importing them depending on the externalHelpers option. Progressive enhancement stuff would almost certainly fall under that category

[Rich-Harris]

Implemented as of 1.5.0 – build tool integrations will need to be updated to take advantage of it though

[Conduitry]

It looks like the built shared.js is not included in the 1.5.0 npm package that was published. I think the file needs to be added to the "files" section of package.json.