8 ms·

Show HN: SkateJS – a cross framework web components based library

144 points by jpnelson 10y ago

aligajani 10y ago
Why would I use this over React, or why would I use this at all?
- girvo 10y ago
  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! [0] https://www.npmjs.com/package/react-standalone https://www.npmjs.com/package/react-standalone
  - noir_lord 10y ago
    The "completely client side" thing is the killer feature for things like Skate/Knockout components. A lot of my applications are either legacy or hybrid's, somewhat heavy JS on the client side but not SPA's, I think of them as lots of mini-SPA's (routing and such is still handled by the server), I've actually found that approach much easier to reason about and it has the benefit of clean seperation of concerns, the downside is that you have to think more carefully about synchronisation between client and server.
- jpnelson 10y ago
  That's a pretty good question. https://github.com/skatejs/skatejs#vs-react https://github.com/skatejs/skatejs#vs-react covers it in a bit of detail. 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 https://github.com/webcomponents/react-integration ).
  - iLoch 10y ago
    Do you see SkateJS being more beneficial to a React developer than say, Standalone? https://www.npmjs.com/package/react-standalone https://www.npmjs.com/package/react-standalone
    - treshugart 10y ago
      Disclaimer: I'm a contributor. 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.
- spankalee 10y ago
  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).
  - elcct 10y ago
    > You can mix and match elements written using different libraries, and migrate single elements from one library to another without breaking clients. Why someone would be doing that? I mean mix and matching libraries could be asking for unmaintainable code...
    - nilliams 10y ago
      Because the alternative is a complete rewrite, which is usually very costly.
    - spankalee 10y ago
      Sure, without Web Components is might be, but Web Components and the DOM are the interop layer. As long as your component has properties, attributes, children and events, it's an element and can work with other elements. How it's implemented internally, and what library it uses, shouldn't matter at all.
  - pavlov 10y ago
    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. Or they could just keep using what works? React's surface area (compared to something like Angular or Ember) is so small, it's not obvious to me why you'd want to do a rewrite just because it "fell out of fashion".
jondubois 10y ago
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 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...
- jpnelson 10y ago
  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.
  - treshugart 10y ago
    Someone has made this more idiomatic to the spec: https://github.com/tmpfs/trucks 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 https://github.com/w3c/webcomponents/issues/136. This is totally something that could be done with Skate, though.
franciscop 10y ago
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.
- treshugart 10y ago
  Thanks for the feedback :) 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 https://github.com/skatejs/skatejs/issues/903 to address the docs issues you pointed out. Also raised
dgelks 10y ago
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?
- treshugart 10y ago
  > 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.
  - dgelks 10y ago
    Thanks for the explanation, great job doing the v0 to v1 transition - the Polymer world is still waiting for the 2.0 release to come out

144 points by jpnelson 10y ago

aligajani 10y ago

Why would I use this over React, or why would I use this at all?

girvo 10y ago
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! [0] https://www.npmjs.com/package/react-standalone https://www.npmjs.com/package/react-standalone
- noir_lord 10y ago
  The "completely client side" thing is the killer feature for things like Skate/Knockout components. A lot of my applications are either legacy or hybrid's, somewhat heavy JS on the client side but not SPA's, I think of them as lots of mini-SPA's (routing and such is still handled by the server), I've actually found that approach much easier to reason about and it has the benefit of clean seperation of concerns, the downside is that you have to think more carefully about synchronisation between client and server.
jpnelson 10y ago
That's a pretty good question. https://github.com/skatejs/skatejs#vs-react https://github.com/skatejs/skatejs#vs-react covers it in a bit of detail. 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 https://github.com/webcomponents/react-integration ).
- iLoch 10y ago
  Do you see SkateJS being more beneficial to a React developer than say, Standalone? https://www.npmjs.com/package/react-standalone https://www.npmjs.com/package/react-standalone
  - treshugart 10y ago
    Disclaimer: I'm a contributor. 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.
spankalee 10y ago
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).
- elcct 10y ago
  > You can mix and match elements written using different libraries, and migrate single elements from one library to another without breaking clients. Why someone would be doing that? I mean mix and matching libraries could be asking for unmaintainable code...
  - nilliams 10y ago
    Because the alternative is a complete rewrite, which is usually very costly.
  - spankalee 10y ago
    Sure, without Web Components is might be, but Web Components and the DOM are the interop layer. As long as your component has properties, attributes, children and events, it's an element and can work with other elements. How it's implemented internally, and what library it uses, shouldn't matter at all.
- pavlov 10y ago
  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. Or they could just keep using what works? React's surface area (compared to something like Angular or Ember) is so small, it's not obvious to me why you'd want to do a rewrite just because it "fell out of fashion".

jondubois 10y ago

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

jpnelson 10y ago
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.
- treshugart 10y ago
  Someone has made this more idiomatic to the spec: https://github.com/tmpfs/trucks 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 https://github.com/w3c/webcomponents/issues/136. This is totally something that could be done with Skate, though.

franciscop 10y ago

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.

treshugart 10y ago
Thanks for the feedback :) 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 https://github.com/skatejs/skatejs/issues/903 to address the docs issues you pointed out. Also raised

dgelks 10y ago

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?

treshugart 10y ago
> 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.
- dgelks 10y ago
  Thanks for the explanation, great job doing the v0 to v1 transition - the Polymer world is still waiting for the 2.0 release to come out