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 #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

[bedeoverend]

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.

So I tried this in Chrome and it seems to work fine - mixing and matching ES6 / ES5. Perhaps transpiling our own, and no editing in IE is back on the cards?

[madeleineostoja]

Hrmm. That's weird, every time I've transpiled my own stuff and forgotten to transpile polymer deps (for eg) it throws. Will need to test more. I think it's a Babel bug?

In any case, they'd only need a buildstep for IE support (ie: for production). They can still dev and mess about without one, and if they want to ship their site, then add in a buildstep. Can just recommend bundling everything with polymer-bundler for now, h2 perf be damed. This all goes away when we move to NPM anyway.

[netdur]

@seaneking how can I help?

[madeleineostoja]

@netdur would you be confident submitting PRs for any of the action items in the first comment?

Before converting any elements we'll need to fork simpla-element-behavior into an ES6 mixin. I can probably do that later today.

Once that's done, some elements - like simpla-video, simpla-link, and simpla-notify - should be fairly trivial to upgrade to Polymer 2 and are a good place to start. Note we can strip out the buildstep and tonnes of boilerplate at the same time, since we'll be shipping ES6 code.

We've settled on migrating to WC v1 now, and doing a quick jump to NPM when Polymer 3 lands to make the browser support issue less awkward. So these can all start shipping (unversioned until we can coordinate docs and such) now.

Thanks!!

[netdur]

@seaneking yes I am, I have good experience building javascript widgets, I will wait for simpla-elements-behavior to get done first.

isn't polymer 2 absolute? because of its html import! shouldn't you jump to polymer 3?

[madeleineostoja]

Great! I'll ping you when it's ported.

And we'd love to, but Polymer 3 is still very much in preview and not ready for prod. We don't like relying on HTML imports/Bower either, but until the platform and/or tooling catches up our hands are tied.

EDIT: Even with Polymer 3, you'd still need flat dep management (like Yarn, or a buildstep), because web components are globally defined, so you can't dupe their imports. Inherent limitation of the spec.

[bedeoverend]

Have made a PR for the new element mixin in #86. @seaneking could you review?

[madeleineostoja]

An update on this - we're going to jump over to pure JS and migrate to NPM at the same time, moving all official elements to a monorepo (in particular, this monorepo). Still hashing out a few minor details before we merge that PR for the element behavior. Sorry for the wait!

[madeleineostoja]

FWIW @bedeoverend after playing with SkateJS for some of my own stuff, I am totally on board with using that for all elements, rather than waiting for Polymer 3 or going full native. Skate with a lit-html renderer (which itself wouldn't be needed for all components) is all of ~4-5kb, hardly a (shared) dep worth worrying about. The 5.1 release also reintroduced spec-compliant classes as the recommended approach (ie: static getters).

Rollup now also supports code splitting and dynamic imports, shimmed with SystemJS for older browsers. Something that could potentially solve the lazy-loaded editors issue.