
Show HN: SkateJS – a cross framework web components based library - jpnelson
https://github.com/skatejs/skatejs
======
jondubois
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
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
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.

~~~
noir_lord
This looks interesting.

I'm currently using the component support in Knockout which looks pretty
similar in function.

    
    
        ko.components.register('my-widget', {
            viewModel: require('../../components/my-widget/my-widget'),
            template: require('fs').readFileSync(__dirname + '/../../components/my-widget/my-widget.html', 'utf8')
        });
    

This then allows me to use <my-widget></my-widget> in the HTML, params can be
passed down with params="{someObject}".

It's a very different way of building applications but I like it, makes for
clean markup and seperation of concerns.

I generally like the approach but long term I'm not sure about the future of
KO, this looks like it offers very similar functionality in a more compatible
way, also I love your documentation, it's thorough and clear!.

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

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

~~~
spankalee
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).

~~~
pavlov
_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".

~~~
marknutter
> React's surface area (compared to something like Angular or Ember) is so
> small

Sure, the core React library is small. But when do people ever _just_ use the
core library? Think of all the additional libraries and components in the
React ecosystem that get used in projects. The footprint of the average React
project ends up being just as large as the footprint of the average Angular or
Ember project.

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

