All right #WebDev nerds, we got some 🌶️ spicy content on the blog for you today! 🤓
A writeup and code/demos all about server-rendering #WebComponents via #Node in three popular flavors: #Enhance, #Lit, and #WebC!
Also a ton of thoughts about the future of these technologies and how to promote a portable view layer of web applications in an #HTML-first world.
Take a peek and then hop in our Discord to chat more about all these groovy features!
@vanilla in article ^^ stated
"The future of web components is split components".
Which I count as antipattern.
Ability of having DOM and associated state declaratively is the future pattern.
Hydration is not just a part of SSR but also the mean of detaching/re-attaching the DOM subtree in runtime for whatever reason. For example, the app could exist on the cloud and changes the state for all its instances in multiple browsers. Or efficient memory caching management options. #webdev
@vanilla,
As of now the #webcomponent state is treated as 2nd class citizen by #w3c
. For now only state which is permitted on declarative syntax is either attributes or payload DOM. Which actually meant for visual and initial state, not the heavy-duty transactional model. If WC would be able to produce and consume the state without custom serialization, it would work on all tiers.
There is a proposal to make it a part of web stack.
Working on it as part of #DeclarativeWebApplication
@Suns @vanilla Well, antipattern is a strong word. I think there will always be plenty of cases where "components" are rendered server-side and then that's pretty much it, no major state changes or template re-renders required on the client, other than perhaps some fine-grained reactivity (aka “change this name prop" or “toggle this CSS class”).
Would I love more advanced state/data models to ride alongside the HTML payload? Sure! If that ends up spec’ed and implemented some day, works for me!
@jaredwhite @vanilla ,
> antipattern is a strong word.
the server side HTML render is not a thing as of now. ASP, PHP, JSP, you name it. I doubt w3c should focus on that part.
The web components hydration as cross-tier time snapshot is. That part need the unified approach, not the server side specific coverage. If the declarative approach works in the browser, there is no reason to not do the same in SSR. Having few tier-specific APIs is an antipattern when we are talking about web standards
The Spicy Web
Sasha Firsov
Jared White (ResistanceNet ✊)