Nanocomponent

[timwis]

Hey, cool project! I wanted to make you aware of another project with similar potential: Nanocomponent. It was spawned by choo, a 4kb javascript framework that aims to minimize framework lock-in by operating on raw DOM nodes. Views are just pure functions that return an HTML element tree. Since every framework out there ultimately produces and rearranges DOM nodes, the thought is that it's a pretty future-proof standard.

The choo community went a step further recently with nanocomponent to provide local state, encapsulate libraries that manipulate their own DOM, and a few other nifty things. It's a pretty lightweight wrapper, and the nanocomponent-adapters library shows how you can use nanocomponents in other frameworks like react and vue.

I also realized yesterday that you can use it to wrap components from other frameworks like react (see this example).

Thought you'd be interested!

[TheLarkInn]

Thank you so much. I pinged @yoshuawuyts today on twitter and also lets ping @bcomnes as well!!!! Very very interested to have you involved in this and get some great feedback, suggestions, support etc.

[yoshuawuyts]

Read up on the discussion a lil bit. This seems like a neat way for people to share components. But to be honest, probably the biggest bottleneck for Choo to support it would be tooling - it'd be nice if there was a generic parser for this that everyone shares; I wouldn't have time to write one in the foreseeable future. I'm imagining Choo isn't the only framework that would have trouble allocating resources for this.

That said, like @timwis pointed out - we already support multiple frameworks. The benefit of our approach is probably that it's just javascript™, and all it returns is DOM nodes. And by using nanocomponent-adapters these components can work pretty much in all frameworks.

I'm not sure what approach is better. They're definitely different. Curious to see where this goes.

[EisenbergEffect]

Agree with @yoshuawuyts. Aurelia is also based on DOM, and we have ways to seamlessly integrate with almost any other component library. We would also have trouble allocating resources to a big effort, but would benefit greatly from a shared format and set of utility libraries and tools for parsing and editor integration.

[bcomnes]

I need to catch up on a bunch of component model spec things. Adding to my TOREAD list.

[bcomnes]

cc @ungoldman kind of related to https://github.com/ungoldman/ideas/issues/15

[TheLarkInn]

Sure @yoshuawuyts and @EisenbergEffect and that makes sense it's probably not the highest priority (not a problem).

My thoughts are that most likely, as @developit and myself continue to work on the Vue=>Preact version, the pieces can all be extracted out to a common surface API.

@yyx990803 mentioned in another thread ( #1 ) there are already some common pieces that could be utilized so I'm going to take a look at that!