Re: Feedback on custom elements and virtual DOM

Sorry for the delay.

The developers at the conference were mainly Java, Scala, Python, etc
devs, so with that caveat in mind...

People liked that you could integrate them easily into a web application.
You add a `<mycustom-element></mycustom-element>` tag into the
document body and your custom element class was up and running.
Less technical people like designers could use custom elements without
a lot of hand holding.
They liked the attribute changes triggering events, the idea of that
possibly being your element's API seemed to be well received.
I think the component based development flow made more sense to them
then just manipulating random divs.

The package we used in the web components part of the workshop used
the ES6 module loader to load in the element modules, template and
styles.
I think part of the "ease of use" positive feedback was actually from
that, no script tags etc.

Now these are not people that are experts in Ember/Angular or React so
maybe if they were they would have been less impressed.

The only aspect of web components we touched was custom elements...
If you could provide the same experience with DOM MutationObserver
then I can see why there might be some doubts...
Making Custom Elements into sugar over DOM MutationObserver might be
enough for some developers.

The only area that I'm not so sure about is ShadowDOM, that could be a
very powerful and useful feature but I'm afraid we didn't have time to
dive into it.

No one had a problem with using the ES6 module loader instead of HTML
Imports, or with not using Templates.

I have nothing concrete in mind when I talked about melding the
virtual DOM and Custom Elements.
I think the important benefit of React is allowing Immediate mode
rendering vs Retained mode rendering.
Most of the time spent on components is on maintenance and I don't
think Custom Elements help out there.
They encourage the retained, mutable state/two-way binding pattern
that libraries like KO, Angular and Ember use.
Even competing libraries are starting to pay attention
https://twitter.com/vojtajina/status/482940326366040064

I doubt any elaboration on turning view components into pure functions
would be as good as this blog post

http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome

"rerender the entire app whenever a change is made. That way, it's
really easy to keep everything in sync."

React allows you to stop worrying about the previous DOM state, while
Web Components still require you to deal with that complexity.
I'm not sure what boost in productivity Web Components offer over
something like React.

There are a lot of good points made in that blog.

"Observables+DOM elements is a leaky abstraction, and as a user I
shouldn't need an intimate knowledge of how the UI is kept in sync
with my data."

"components and their behaviors are intimately dependant and should be
encapsulated like so."

Surely HTML can only ever be a sugar over the real business logic
which will be contained in JS. We need a Turing complete language to
build complex applications.

"Aren't you tired of having to query the DOM tree and manually manage
the structure to create UIs? Web Components doesn't solve this at all,
it just tries to encapsulate the work. The problem is that building
apps is building components, so you inevitably are forced back into
the manual DOM management to create your app-specific components (like
how you constantly have to create directives in Angular). You also
need to jump into JavaScript to configure and wire up any Web
Components you used. It's a very messy abstraction, and fools you into
desiring a pure HTML-based declarative way to write apps".

The components I have built using Custom Elements had this property, I
was still removing and adding event listeners and dealing with the
previous DOM state.
It was nice to work directly in a DOM elements but that's not an
amazing win in my mind, it's a minor plus.
To build complex apps you will still use something like
Polymer/Angular/Ember or React.
There is no guidance about data flow between different Web Components.
They seem underpowered and complex...

None of these concerns will stop Web Components from being
standardized, implemented in browsers and used by developers.
A standard will have mind share purely because it's a standard but it
doesn't seem like a significant step forward.

On Wed, Jul 2, 2014 at 4:18 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> On Jul 2, 2014, at 3:57 AM, Brian Di Palma <offler@gmail.com> wrote:
>> I gave a workshop on ES6 and Web Components at a small conference in
>> London and there was positive feedback on Custom Elements.
>> People liked them, felt the component approach was a good way to model
>> web applications. Then again React has similar concepts.
>
> We tend to hear "people like the idea" a lot about web components but the devil is in the details in our industry.  Could you elaborate more on which aspects of web components or custom elements developers liked?
>
>> Programming with the DOM as the local `this` pointer is nice and went down well.
>> I wish we could meld the virtual DOM idea with Custom Elements as that
>> would be the best of both worlds.
>
> Could you elaborate more on what you mean by melding virtual DOM idea with custom elements?  Are you thinking of equating virtual DOM in React with shadow DOM?  Or are you talking about something else?
>
>> Turning view components into a set of pure functions is a fantastic
>> way of dealing with mutable state.
>
> Could you elaborate on what you mean by this?
>
> - R. Niwa
>

Received on Saturday, 19 July 2014 22:24:18 UTC