Re: [w3c/webcomponents] HTML Modules (#645)

@addyosmani I do think this general architecture is valuable. It can be used to import both somewhat static content but also for loading pieces of a page out-of-order and inject dynamically. So, I'm all for it for frameworks that are HTML heavy and centric.

However, for React, and I believe this is a more general trend, we're increasingly looking for ways to avoid passing static, or server responses, as HTML as the serialization format. For these use cases we might use custom byte codes like Glimmer or some other format. There's a lot of value in a richer serialization format that can include more data to pass to JS, cheap branching and conditional logic, immediate access to references to nodes etc. I'm asking myself what value HTML, as format, offers to a JS library once it's already up and running. I see soft value like familiarity, and concrete value like browser specific caching formats. However, those have to be weighed against other things.

Even if you use what seems to happen is that you end up with two modes in the JS library to deal with nodes created from HTML and nodes created from another mechanism. That adds complexity and code.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/645#issuecomment-310733139