Re: [w3c/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

@WebReflection

> That's, today, more than 4 years ago, this is the current situation abut Custom Elements.

As far as i understand, that is mainly due to the fact that not all browser vendors agree to the whole spec (and its not only about custom elements, its about the 4 specs that enable "web components"). So every webworker reading up on this and trying to evaluate web components will read about these different opinions and a reasonable business decision is not to use web components. especially if you take the vDOM alternives into concideration its a very easy recommendation every senior developer could savely make (without spending weeks to read up on all the reasons and discussion around the topic). 

> React renders on the server too so ... yes.

please read my comments correctly. shipping static SSR content with no UX is __not__ an acceptable fallback for an __app__.

also you could do SSR with custom elements, too, that produce whatever static fallback you like and wrap around some loading scripts. the benefit of vDOM is that they already have a vDOM -> DOM transformation anyway, so SSR is not that much of a burden.

If you want to display static data, there are __many__ highly sopisticated and actively developed frameworks for various environments available that produce super clean (HTML) documents. there is no need for covering this on the client. where we need client-builtin advancements is "browser as an app platform".

> if web standards are limited to whatever is already out there and works already in any browser I guess we can all go home now and stop bothering each other. We don't need innovation here.

So aiming for a cleaner and more performant way for component-driven web is not a reason to persue custom elements, shadow DOM et al and carries no innovation? And imho this exactly is one of the main reasons people really dislike `is=""`, because it makes compromises about a streamlined DX and this compromise is made just because a minority wants to be able to support corner cases, that most developers cant relate to. (these corner cases can just as well take an "old" approach until their minimum target supports web compenents)

@OvermindDL1 

> I have css at the top that hides the body, loads the javascript synchronously (if it can load at all, I bundle all JS into a single file), then a style at the bottom of the body unhides the body. It has worked in every situation that I've been able to try so far.

that is fine, but that doesnt satisfy a constant requirement made in this discussion: there is no progressive pre-upgrade UX. that is super ok from my PoV, and i dont buy into the progressive pre-upgrade UX at all. also bundling up every script into a single file makes for a horrible UX once the app grows (take asana for example, every time i get sent an asana task link, i rly dont wanna click it).

> And this is why I am not a fan of the react style, though in some rare cases it is useful (highly dynamic pages, like a messenger...)

these rare cases are not that rare, especially if you look at SaaS solutions.

> Different use-cases. React is useful for highly dynamic pages, not just displaying content (anytime I see a site that uses react to show static content get blocked very quickly...), webcomponent fallback is for when a page needs to work in all cases, which is common in, say, government for example.

if you design web components around this premise, a large majority will stay at vDOM for "browser as an app platform" and just use web components when there some few established basic components that work highly isolated, if not just avoiding them at all.

> And yet I have to support it, and indeed I do, I have a search bar that refines a drop-down list as you type if you have javascript, if you do not then a submit will refresh the page with the typed results. It is not hard to do at all.

imho, it is a horrible UX, even worse than telling them to "please activate JS". and from my experience, while the fallback concept is easy to formulate, it is hard to implement it in a maintainable and UX preserving way.

> You've apparently not worked in government, I unfortunately have to.

i dont know what this statement adds in regard of the quoted section. no the accessability projects i worked on werent government projects. but government pages have other target requirements than pages made to offer a __great__ accessability. if i build a page that works with a screen reader that is 10 years old, that doesnt give a great experience to users with newer screen readers. accessability doesnt (or does not just) mean supporting _old_ clients.


My feeling is, that a solution cant be found, because there are no clearly defined requirements. everyone just throws in their cases and expects web components to solve them.

-- 
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/509#issuecomment-302774762