Migrate to WC v1, JS, and NPM

[madeleineostoja]

The Simpla ecosystem is currently built on v0 of the Web Components specs (and Polymer 1). We should upgrade all elements to WC v1 specs, which will allow us to:

• Make Simpla compatible with Polymer 2 projects
• Strip Polymer from render bundles and use the raw browser APIs, greatly improving first-paint performance
• Server side render content, using skatejs/ssr, fixing Support prerendering #66
• Document element authorship, and make a generalised ES6 mixin to make building elements with any framework easy peasy
• Finally move to ES6 modules and NPM

Prereqs

• Port simpla-element-behavior to ES6 mixin

Elements

• simpla-text
• simpla-img
• simpla-article
• simpla-video
• simpla-admin
• simpla-link
• simpla-collection
• simpla-notify
• simpla-markdown

Misc

• Update docs (snippets, build step for IE, etc)
• Publish elements to NPM, issue deprecation for bower, and manage in monorepo

Notes

• Elements will be shipped as ES6 classes (see discussion below), which means a) we can strip out buildsteps and boilerplate in elements themselves but b) IE support will need a buildstep from the user

• Ideally the render bundles of all elements should not need to pull in Polymer, to keep initial upgrade and render as performant as possible

• Simpla-img will need to be turned into a wrapper element, since is="" type extension is hard deprecated in v1 🙃

• Since the element behavior is now an ES6 mixin, it should be renamed and no longer rely on Polymer, but just hook up generic web component classes to Simlpla

• The richtext behavior used by simpla-text and simpla-article should probably be split off into a generalised JS module, since it's not actually tied to Simpla in any way

[madeleineostoja]

Note: Just realised that when we move to WC v1 we'll lose out-of-the-box IE11 support, because Polymer (and all other v1 wc's) don't ship transpiled element definitions.

Users will require a buildstep. That sucks on its own but is worse because they'll either have to bundle everything with Polymer CLI, which is an anti-pattern w/ h2, or transpile Bower components in-place with a postinstall hook, which is a hack and prone to failure.

Might even be worth waiting for Polymer 3 to drop, at least when everything is in JS land there are precedents users can easily follow (ie: import and code split, or transpile es modules directly)

/cc @bedeoverend

[bedeoverend]

Wel, that really sucks.

Can you just transpile with Polymer CLI? Surely you can - and just partly bundle / code split? Anti-pattern to bundle everything, but also still advised to bundle some things to avoid long request paths.

Having said that, regardless, it'd suck to have to require people to use those tools / buildstep to just get off the ground. It'd also suck to have to wait for Polymer 3, but might be the way to go. I'd prefer just wait and do that rather than spend a whole heap of time on solutions that'll eventually be superseded anyway.

Other option would be drop IE11 support for editing. We can move our view only elements to vanilla v1 or similar without any Polymer / other element deps (which'd be good to do anyway for perf), and then editing elements support the evergreens.

[madeleineostoja]

No dice, re: transpiling our own stuff and saying no IE in editing, because the ES5 shim throws if you try and register an element with an ES6 class. So you can't mix ES5 and ES6 definitions.

I've never actually used Polymer CLI, but I would be very surprised if it did any kind of easy code splitting, it wouldn't know enough about the user's views for a start. It might do transpile-only, but unless you're also moving components out of bower to dist, it's probably cleaner to just advise doing a bower postinstall hook to transpile in place. Especially since polymer CLI is a kitchen sink, like I think most of those tools are tied to serving/prod configs/etc.

Well there'll likely be very little difference in public API between polymer 2 and 3, so as far as implementation workload it's not a big deal. Just whether we want to have that awkward intermediary phase of shitty HTML build steps. Can always start on the v1 conversions, and decide whether to ship or not when we get there.

[bedeoverend]

Ah of course, forgot about the ES5 shim. Yeah I'd say we can start work on v1 conversions, that's not going to change, and have another look at best way to handle IE11 when we're getting closer.

[madeleineostoja]

Of course a final option is moving everything to a pure JS helper library like Skate now, but that's probably overkill, and we'd lose the ability (basically) to use any other helper elements