Working on a WebC demo to show how to easily swap a web component between different rendering modes:
1. Server rendered plain HTML
2. Declarative Shadow DOM
3. JS-only (boo) Shadow DOM
Stay tuned!
4 replies
Why "boo"?
Rendering in JS can be the right thing to do in elements that require JS to fully surface the experience they deliver. Sometimes nothing is really better than something.
Whether it's advanced functionality (that not all apps need) or baseline accessibility (that all do) JS can be an important part of delivering your apps content!
@westbrook sometimes! I live on the hill that JS-based Shadow DOM was oversold though—and long before superior declarative methods were available, too. Just another quibble about defaults, I suppose!
@westbrook @zachleat I really believe it depends on the type of component.
Something like "popup calendar widget" probably doesn't make much sense being server-rendered with declarative markup, as it's functionally useless without JavaScript.
But other components might be largely based around light interactions on top of app content and data that's server-driven anyway. In those cases, going DSD-first (perhaps even avoiding shipping a client-side template at all) is a huge benefit.
@jaredwhite @zachleat Definitely in this area of thought!
Regardless of "can function" without JS, many patterns can't be accessible without JS, and if you're going to need those things you can't be sure what content to send users until the JS is for sure available. In that way, you might SSR one thing and then CSR other things, but the JS render would still happen.