> I see you're already at v4 of the library, how often do you do breaking changes?
It's partially a side-effect of following strict semver and using semantic-release but also that we intentionally favour breaking incrementally over big-bang releases. As a contributor, I've found that this actually makes me more aware of things I'm breaking and API changes become more intentional. We haven't - and probably never intend to - load up a feature branch with a bunch of breaking changes and release it all at once.
In 2.0.0, 3.0.0 and 4.0.0, I can count the breaking changes on one hand:
- 2.0.0: Attributes are only synced when the element is connected to the document (spec change)
- 3.0.0: Initial component render is no longer synchronous (sync to microtask)
- 4.0.0: Remove v0 spec support after v1 is in Chrome / Opera (due to spec changes)
Of those three breakages, 3.0.0 was the only real breaking change, but technically the others can be considered breaking.
Something that I'd personally like to start doing is releasing a code-shift migration with every major release.
Yeah, the comparisons need updating. I'd prefer not to have them because you're then subject to keeping your README up to date with everyone you compare to but some people have asked for them. I'm torn.
That said, yes, Polymer does only change the parts of the DOM that need updating but there's still a fundamental difference in that Skate re-renders using a virtual DOM whereas Polymer keeps track of the elements that need updating and uses observables. Observables require you specify how they should behave depending on how you expect them to be set. Even so, sometimes you have to manually trigger them to update in order for your component to update. Skate relies on the same principle React does: you update a property, you re-render. The major difference here being that Skate checks references by default in updated() (like shouldComponentUpdate()) thus only re-rendering if necessary.
As jpnelson mentioned, Skate is more React-like than Polymer-like in its API, but it's still not 1:1 due to the specs. Some things like componentWillMount() don't translate because connectedCallback() is fired after the element is connected to the document. They're all different libraries; direct comparisons are hard.
FWIW, I'm not trying to downplay other libraries, either. Polymer is a great library and a major source of inspiration, just like React is.
First and foremost, Skate is a web component library designed to give you an augmentation of the specs focusing on a functional rendering pipeline and clean property / attribute semantics. It's about a tenth the size of just React itself, doesn't require any extras and utilises both custom elements and shadow DOM out of the box.
React is nice, and if you're can't invest the time to learn something new, Standalone is definitely a good choice. That said, the time it takes to learn Standalone you could have probably learned Skate. In my opinion, right tool, right job; hammer principle etc :)
Would be interested to see what jpnelson thinks as well.
Skate augments the web component spec and employs a functional rendering pipeline. Thus, your comment about it being "React in native web components" is a good elevator pitch, but we don't want to give any false impressions. Skate is first and foremost a web component library based off of the spec that adds things like virtual DOM rendering and structured property definitions and attribute linking requiring very little boilerplate.
Someone has made this more idiomatic to the spec: https://github.com/tmpfs/trucks. FWIW, we are looking at decoupling Incremental DOM in a way where custom renderers can be created, so one could create a <template /> renderer.
It's not immediately obvious, but you could create a custom element with Skate that takes it's content and creates a new custom element definition from it, similar to how Polymer 1 worked. This approach was discussed as being implemented in custom elements v2, but is closed to see what frameworks come up with: https://github.com/w3c/webcomponents/issues/136. This is totally something that could be done with Skate, though.
It's partially a side-effect of following strict semver and using semantic-release but also that we intentionally favour breaking incrementally over big-bang releases. As a contributor, I've found that this actually makes me more aware of things I'm breaking and API changes become more intentional. We haven't - and probably never intend to - load up a feature branch with a bunch of breaking changes and release it all at once.
In 2.0.0, 3.0.0 and 4.0.0, I can count the breaking changes on one hand:
- 2.0.0: Attributes are only synced when the element is connected to the document (spec change)
- 3.0.0: Initial component render is no longer synchronous (sync to microtask)
- 4.0.0: Remove v0 spec support after v1 is in Chrome / Opera (due to spec changes)
Of those three breakages, 3.0.0 was the only real breaking change, but technically the others can be considered breaking.
Something that I'd personally like to start doing is releasing a code-shift migration with every major release.