3 ms·

I'm not really sure what you mean: I actually pre-render everything in templates, when in webcomponent however I use the slot attribute which also is an implem

I'm not really sure what you mean: I actually pre-render everything in templates, when in webcomponent however I use the slot attribute which also is an implemented standard now. Anyway, that's the feature to pre-render everything: https://stenciljs.com/docs/hydrate-app https://stenciljs.com/docs/hydrate-app

DaiPlusPlus 6y ago
Stencil requires you to use NodeJS - so if you want to use it with a “traditional” non-SPA ASP.NET or PHP web-application then you’re SOL.
- 1337shadow 6y ago
  Well, at least you can still pre-render inside your web-component tags - like I do in python.
- yesimahuman 6y ago
  That's not entirely true. If you pre-render your pages then there's no server-side Stencil code needed. You just need to serve those pages to the client and they will hydrate. EDIT: don't understand the downvotes, seeing as we built Stencil. Stencil can definitely be used in a more traditional server-side environment like ASP.Net or PHP
  - DaiPlusPlus 6y ago
    I didn't see any documentation on Stencil's website regarding how to pre-render Stencil components without using their NodeJS toolset. (I did not downvote you, and someone has downvoted me as well, it seems)
chrismorgan 6y ago
Shoelace is using the Shadow DOM. You fundamentally can’t prerender that yet. (Refer to my comment.) I’m a little surprised to see no mention of that in the Stencil docs.
- 1337shadow 6y ago
  Actually, you can disable shadow dom on Stencil components, which I ended up doing in my own code because it then nicely integrates with my favorite server side framework, that still does most of the work. What is it exactly that you can't pre-render ? That's not very clear to me. You can put any kind of content inside your web-component tags: <your-paragraph><p>your test</p></your-paragraph> If the browser is recent enough to support TLS 1.3 (which we all want to move on too don't we !) then it is recent enough to support web-components for sure. So, that's pretty much how I see it: browsers have to upgrade for security reasons, if we're getting features like the ability to do some components without having to load a fat frontend framework, components that integrate perfectly with my favorite server side framework, then my question is why: why should we not haz nice things ? we're getting them for free after all ! Without even webpack to make a 1MB bundle ! I'd like your help to better understand what's the bad news here ...
  - chrismorgan 6y ago
    I’m not familiar with Stencil, but it looks like the Shadow DOM switch is targeted at the component author, as something that they will need to adjust their code for, and thus I would expect that it won’t be quite as simple as just turning off shadow DOM, though it could still be straightforward, though still something you’d need to do. I’m not sure. Other aspects of Shoelace might also be designed with Shadow DOM in mind, though the couple of components I’ve glanced at the code of seem safe; but interactions between Shadow DOM and ID references (e.g. <label for>, aria-describedby) can be a little fiddly. I’m talking about the document becoming interactive and operative without or before JavaScript is loaded. Shadow DOM is not part of the HTML serialisation, so anything using Shadow DOM fails this test. Fixing this is what Declarative Shadow DOM research project is about.
    - 1337shadow 6y ago
      Confirmed that the shadow dom switch is available to the component author, so they'd have to do two builds if they wanted to use both in different projects. Agreed the shadow dom didn't seem ready for me neither, but I feel that we're getting there, and meanwhile it's hopefully optional.

DaiPlusPlus 6y ago

Stencil requires you to use NodeJS - so if you want to use it with a “traditional” non-SPA ASP.NET or PHP web-application then you’re SOL.

1337shadow 6y ago
Well, at least you can still pre-render inside your web-component tags - like I do in python.
yesimahuman 6y ago
That's not entirely true. If you pre-render your pages then there's no server-side Stencil code needed. You just need to serve those pages to the client and they will hydrate. EDIT: don't understand the downvotes, seeing as we built Stencil. Stencil can definitely be used in a more traditional server-side environment like ASP.Net or PHP
- DaiPlusPlus 6y ago
  I didn't see any documentation on Stencil's website regarding how to pre-render Stencil components without using their NodeJS toolset. (I did not downvote you, and someone has downvoted me as well, it seems)

chrismorgan 6y ago

Shoelace is using the Shadow DOM. You fundamentally can’t prerender that yet. (Refer to my comment.) I’m a little surprised to see no mention of that in the Stencil docs.

1337shadow 6y ago
Actually, you can disable shadow dom on Stencil components, which I ended up doing in my own code because it then nicely integrates with my favorite server side framework, that still does most of the work. What is it exactly that you can't pre-render ? That's not very clear to me. You can put any kind of content inside your web-component tags: <your-paragraph><p>your test</p></your-paragraph> If the browser is recent enough to support TLS 1.3 (which we all want to move on too don't we !) then it is recent enough to support web-components for sure. So, that's pretty much how I see it: browsers have to upgrade for security reasons, if we're getting features like the ability to do some components without having to load a fat frontend framework, components that integrate perfectly with my favorite server side framework, then my question is why: why should we not haz nice things ? we're getting them for free after all ! Without even webpack to make a 1MB bundle ! I'd like your help to better understand what's the bad news here ...
- chrismorgan 6y ago
  I’m not familiar with Stencil, but it looks like the Shadow DOM switch is targeted at the component author, as something that they will need to adjust their code for, and thus I would expect that it won’t be quite as simple as just turning off shadow DOM, though it could still be straightforward, though still something you’d need to do. I’m not sure. Other aspects of Shoelace might also be designed with Shadow DOM in mind, though the couple of components I’ve glanced at the code of seem safe; but interactions between Shadow DOM and ID references (e.g. <label for>, aria-describedby) can be a little fiddly. I’m talking about the document becoming interactive and operative without or before JavaScript is loaded. Shadow DOM is not part of the HTML serialisation, so anything using Shadow DOM fails this test. Fixing this is what Declarative Shadow DOM research project is about.
  - 1337shadow 6y ago
    Confirmed that the shadow dom switch is available to the component author, so they'd have to do two builds if they wanted to use both in different projects. Agreed the shadow dom didn't seem ready for me neither, but I feel that we're getting there, and meanwhile it's hopefully optional.