Post

Thanks! I remember the joy of stumbling across this approach myself back when implementing it: such a different, and nicer, approach than how we had to do it back in the old React app.

𝘛𝘩𝘪𝘴 𝘳𝘦𝘴𝘶𝘭𝘵𝘴 𝘪𝘯 𝘭𝘢𝘻𝘺-𝘭𝘰𝘢𝘥𝘪𝘯𝘨 𝘤𝘶𝘴𝘵𝘰𝘮 𝘦𝘭𝘦𝘮𝘦𝘯𝘵𝘴 𝘱𝘳𝘦𝘴𝘦𝘯𝘵 𝘪𝘯 𝘵𝘩𝘦 𝘋𝘖𝘔 𝘢𝘵 𝘭𝘰𝘢𝘥 𝘵𝘪𝘮𝘦, 𝘦𝘯𝘵𝘪𝘳𝘦𝘭𝘺 𝘢𝘴𝘺𝘯𝘤 𝘢𝘯𝘥 𝘪𝘯 𝘱𝘢𝘳𝘢𝘭𝘭𝘦𝘭 Yes lazy, and LATE because it can only run AFTER all DOM is parsed 𝘞𝘦 𝘢𝘭𝘴𝘰 𝘢𝘶𝘵𝘰𝘮𝘢𝘵𝘪𝘤𝘢𝘭𝘭𝘺 𝘭𝘰𝘢𝘥 𝘦𝘷𝘦𝘳𝘺 𝘸𝘦𝘣 𝘤𝘰𝘮𝘱𝘰𝘯𝘦𝘯𝘵 𝘪𝘯 𝘰𝘶𝘳 𝘚𝘚𝘙 𝘣𝘶𝘯𝘥𝘭𝘦 SSR?! then use the platform! <𝙨𝙘𝙧𝙞𝙥𝙩 𝙙𝙚𝙛𝙚𝙧/𝙖𝙨𝙮𝙣𝙘/𝙢𝙤𝙙𝙪𝙡𝙚>

David Bushell 🪿

@dbushell.com

LATE is sometimes preferable depends where/when a component might be used, using <script> for everything can clog the pipes (i don't know what they mean by SSR bundle, don't think that is shipped to the browser?)

They SSR all, so have a server-side process that scans Markdown and creates HTML Since they scan the source, might as well record what Web Components are used, and create proper <script async/defer/import src="" > tags in the <head> They complain about SPAs and then introduce a JS load SPA style

Leo McArdle 🇺🇦

@leo.mca.is

We don't scan the source in SSR, merely template it together: we'd need to add another step to detect what custom elements are being used. It ought to improve things, but it's on my "to implement and benchmark later" list: caching and progressive enhancement means I expect it to be very minor.

MDN want buttons to become interactive. You don't want to be late, you wan't to be on time, not download things too early. <script defer/async/import> does that For CSS they DO "use the platform" loading stylesheets with <link> Their JS load code ignores UNdefined Custom Elements ARE valid to use