I heard about SkateJS a long time ago. It looks like it has kept evolving. Reading the docs now, it looks very, very similar to Google's Polymer framework.
Polymer is even mentioned here https://github.com/skatejs/skatejs#vs-polymer but the comparison appears to be partially out of date - Like SkateJS, Polymer only updates the elements which changed - Even when rendering lists; it won't re-render the entire list if only one element changed.
It seems the main benefits over Polymer are customizable template languages and support for more different package managers...
I really like how every component in Polymer is essentially an HTML template with its own sub-DOM. I also like the way Polymer lets you specify dependencies in components as <link rel="import" href="..."> tags.
Polymer is like the inverse of React; React components are source files with template markup embedded inside them while Polymer components are template markup files with source code embedded inside them. I find Polymer's approach cleaner and more readable because all the source code is concentrated in one place. I don't know what the equivalent is for SkateJS...
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.
I was commenting like how this looked like Polymer and then saw this.
I like Polymer, but it's not as popular as (i think) it should be.
Html & Javascript files are only loaded inside the component, and once they are loaded they sttay in it's "dom". So it doesn't mean, everything is loaded at once.
We've been communicating with them pretty closely actually! We're aiming to use the same polyfills so that the community can share the benefits of that.
With the imports it's a slightly different paradigm – in the way that you put it, Skate is more similar to React's approach where the template is embedded in the source.
Heavy Polymer user here, I have heard about SkateJS a few times but have never really had a close look at other webcomponent libraries yet, will definitely have a look at utilising this in a side-project or hackathon style event at some point. Not having to worry about the future of html imports anymore is great!
I see you're already at v4 of the library, how often do you do breaking changes?
> 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.
First, all Web Components libraries are by default compatible with each other, so by using this instead of React you aren't locked into a non-standard framework. You can mix and match elements written using different libraries, and migrate single elements from one library to another without breaking clients.
Eventually React will fall out of fashion like every other framework before it, and teams that went all-in on it will have to do a painful rewrite. Web Components based apps will be able to incrementally migrate, element by element, to a different library.
Second, by relying on the browser to host components and run the component lifecycle and composition parts, it's pretty easy to be smaller and faster than frameworks like React.
Third, Shadow DOM fixes CSS. Scoped styles are simpler, easier to reason about, faster, have lower specificity, ID's become useful again, and it's much easier to do things like lazy load below-the-fold styles because you transform that into lazy-loading below-the-fold components (simpler than teasing apart rule soup).
The main reason is that integrating web-components into a server-side rendered language (such as PHP, Java, et al) that generates HTML is much simpler than setting a V8 context to do SSR of React components.
React is brilliant and my favourite library and architecture, but without things like react-standalone[0] integrating singular components within an existing application, especially one that isn't completely client-side, is rather painful at times!
The first example and the library itself looks too complex; I was looking for a simple webcomponent library, but I think I will just make a couple of DOM calls myself.
For instance, for the example, what does `skate.h('div'` do? I would expect it being inside the render() element to transform the component into a div. I would also expect that in `props: { name: { attribute: true } }` for name to be an attribute by default (most props have an attribute so that'd be a nice default). For instance, what does even render() do if it's just a web component library?
The definition of SkateJS, "write functional and performant web components with a very small footprint" looks different from the examples/comments I see here; it looks more like a "React in native web components" than the flat web components part itself.
Note: I have made quite a few js libraries myself so this is just feedback; normally I try to keep the complexity of the examples from dead simple to more complex ones.
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.
[+] [-] jondubois|9 years ago|reply
Polymer is even mentioned here https://github.com/skatejs/skatejs#vs-polymer but the comparison appears to be partially out of date - Like SkateJS, Polymer only updates the elements which changed - Even when rendering lists; it won't re-render the entire list if only one element changed.
It seems the main benefits over Polymer are customizable template languages and support for more different package managers...
I really like how every component in Polymer is essentially an HTML template with its own sub-DOM. I also like the way Polymer lets you specify dependencies in components as <link rel="import" href="..."> tags.
Polymer is like the inverse of React; React components are source files with template markup embedded inside them while Polymer components are template markup files with source code embedded inside them. I find Polymer's approach cleaner and more readable because all the source code is concentrated in one place. I don't know what the equivalent is for SkateJS...
[+] [-] treshugart|9 years ago|reply
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.
[+] [-] NicoJuicy|9 years ago|reply
I like Polymer, but it's not as popular as (i think) it should be.
Html & Javascript files are only loaded inside the component, and once they are loaded they sttay in it's "dom". So it doesn't mean, everything is loaded at once.
I think https://poly-mail.appspot.com/ is a nice example of a Polymer app ( email and login with Google fyi)
[+] [-] jpnelson|9 years ago|reply
With the imports it's a slightly different paradigm – in the way that you put it, Skate is more similar to React's approach where the template is embedded in the source.
[+] [-] dgelks|9 years ago|reply
[+] [-] treshugart|9 years ago|reply
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.
[+] [-] aligajani|9 years ago|reply
[+] [-] spankalee|9 years ago|reply
Eventually React will fall out of fashion like every other framework before it, and teams that went all-in on it will have to do a painful rewrite. Web Components based apps will be able to incrementally migrate, element by element, to a different library.
Second, by relying on the browser to host components and run the component lifecycle and composition parts, it's pretty easy to be smaller and faster than frameworks like React.
Third, Shadow DOM fixes CSS. Scoped styles are simpler, easier to reason about, faster, have lower specificity, ID's become useful again, and it's much easier to do things like lazy load below-the-fold styles because you transform that into lazy-loading below-the-fold components (simpler than teasing apart rule soup).
[+] [-] jpnelson|9 years ago|reply
Depending on standards will be great in the long run, as over time the need to deliver polyfills will evaporate.
In addition, writing a web component allows integration with any framework (even React! https://github.com/webcomponents/react-integration ).
[+] [-] girvo|9 years ago|reply
React is brilliant and my favourite library and architecture, but without things like react-standalone[0] integrating singular components within an existing application, especially one that isn't completely client-side, is rather painful at times!
[0] https://www.npmjs.com/package/react-standalone
[+] [-] franciscop|9 years ago|reply
For instance, for the example, what does `skate.h('div'` do? I would expect it being inside the render() element to transform the component into a div. I would also expect that in `props: { name: { attribute: true } }` for name to be an attribute by default (most props have an attribute so that'd be a nice default). For instance, what does even render() do if it's just a web component library?
The definition of SkateJS, "write functional and performant web components with a very small footprint" looks different from the examples/comments I see here; it looks more like a "React in native web components" than the flat web components part itself.
Note: I have made quite a few js libraries myself so this is just feedback; normally I try to keep the complexity of the examples from dead simple to more complex ones.
[+] [-] treshugart|9 years ago|reply
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.
Raised https://github.com/skatejs/skatejs/issues/903 to address the docs issues you pointed out. Also raised