3 ms·

> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my t

> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my the rest of my Markdown as long as I could express them as plain HTML tags. You can also use MDX and achieve exactly the same thing. Web components the technology don't actually help here; what the author cares about is the interface between their markup and some piece of code that applies runtime functionality. Web components are an implementation detail here: whether you're referencing a React component or an Astro thing or a web component when you type a name between some angle brackets, it really doesn't matter: the point is that _some other thing_ is invoked. The downside to web components here is that they can only be run on the client, for all intents and purposes. There's no way to pass server-rendered shadow dom content on the server to the client, so even if your web component is fully non-interactive, you still need JS on the client in order to render it. That's not the case with other frameworks. I'll say that the author's point isn't wrong: web components as a way to codify interfaces between chunks of code is quite possibly the best, most durable way to accomplish that goal. BUT! On the server, web components do you no favors. They don't render, they are a cumbersome interface, and your code is already entirely written in a way that you can (hopefully!) work with. Which is to say, if you have Astro on the server, please keep using Astro! Or react, or vue, or whatever. Where web components shine is on the client, when you have a component from a third party that might not be written in your framework of choice. You don't need to know about the framework the component you're putting on the page was built with. You just use a HTML tag and it works. The mechanism of the interface is uplifted to the browser level, so you don't need two frameworks to speak each others' implementation details.

ElevenLathe 3y ago
>> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my the rest of my Markdown as long as I could express them as plain HTML tags. > You can also use MDX and achieve exactly the same thing. I would like to point out that plain HTML also has this property.
- bastawhiz 3y ago
  Sure, and you could hand-write your blog posts in a hex editor so that the binary data can just be pumped out over the wire. Markdown generates HTML. MDX generates HTML. Use the tool that brings you joy and makes your life easy. In any case, the point is that referencing another piece of code from your markup can be done in a number of ways, and the way the author chose has an upside but also a significant downside.
azangru 3y ago
> The downside to web components here is that they can only be run on the client, for all intents and purposes. There's no way to pass server-rendered shadow dom content on the server to the client, so even if your web component is fully non-interactive, you still need JS on the client in order to render it. That's not the case with other frameworks. I thought you were going to argue that there is no way that a tag like <my-component></my-component> magically acquires all its inner html on the server all by itself. That it would need some kind of tool to help it. In that, I suppose, you are right. Although that tool can be literally any server-side templating engine that will fill <my-component> with the initial html it needs to bootstrap. But server-rendered shadow dom can absolutely be passed to the client. It is called declarative shadow DOM; and it works in all major browsers other than Firefox; and Firefox is working on it right now. There's also a polyfill.
- bastawhiz 3y ago
  > Although that tool can be literally any server-side templating engine that will fill <my-component> with the initial html it needs to bootstrap. If you need to add a templating engine to generate your markup, you're really just replacing a framework with web components...and another framework. Which is half of my point: you aren't getting rid of a framework by choosing web components. > it works in all major browsers other than Firefox; and Firefox is working on it right now. There's also a polyfill. https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 "Obviously not a commitment to implement, but potentially worth reevaluation" is not "working on it right now", unfortunately. Here we are again, however, in that a completely non-interactive web component still needs JavaScript to render because you need a polyfill to take static, server-rendered HTML and put it in the shadow root. Again, it begs the question of what purpose web components are serving here anyway. The developer has to bend over backwards for both the server side and the client side and there's no meaningful reduction in code at all for either the client or the server.
mmis1000 3y ago
> There's no way to pass server-rendered shadow dom content on the server to the client, There is a proposal for that, although nobody knows whether it will survive in the long run. https://developer.chrome.com/articles/declarative-shadow-dom/ https://developer.chrome.com/articles/declarative-shadow-dom... BTW: the polyfill for this is rather easy, so you may be able to use it even browser today haven't support it now.
- superchris 3y ago
  It is supported by chromium already and Mozilla has said they'll be working on it
brainbag 3y ago
I like web components especially with the nice tooling that comes with lit, but agree that the lack of server-side rendering and hydration makes them impractical to use compared to other server side progressive enhancement libraries like Stimulus and Alpine. Server-side renderable web components would open up a lot of possibilities for better user experience for multi-page apps.

ElevenLathe 3y ago

>> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my the rest of my Markdown as long as I could express them as plain HTML tags. > You can also use MDX and achieve exactly the same thing. I would like to point out that plain HTML also has this property.

bastawhiz 3y ago
Sure, and you could hand-write your blog posts in a hex editor so that the binary data can just be pumped out over the wire. Markdown generates HTML. MDX generates HTML. Use the tool that brings you joy and makes your life easy. In any case, the point is that referencing another piece of code from your markup can be done in a number of ways, and the way the author chose has an upside but also a significant downside.

azangru 3y ago

> The downside to web components here is that they can only be run on the client, for all intents and purposes. There's no way to pass server-rendered shadow dom content on the server to the client, so even if your web component is fully non-interactive, you still need JS on the client in order to render it. That's not the case with other frameworks. I thought you were going to argue that there is no way that a tag like <my-component></my-component> magically acquires all its inner html on the server all by itself. That it would need some kind of tool to help it. In that, I suppose, you are right. Although that tool can be literally any server-side templating engine that will fill <my-component> with the initial html it needs to bootstrap. But server-rendered shadow dom can absolutely be passed to the client. It is called declarative shadow DOM; and it works in all major browsers other than Firefox; and Firefox is working on it right now. There's also a polyfill.

bastawhiz 3y ago
> Although that tool can be literally any server-side templating engine that will fill <my-component> with the initial html it needs to bootstrap. If you need to add a templating engine to generate your markup, you're really just replacing a framework with web components...and another framework. Which is half of my point: you aren't getting rid of a framework by choosing web components. > it works in all major browsers other than Firefox; and Firefox is working on it right now. There's also a polyfill. https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 https://bugzilla.mozilla.org/show_bug.cgi?id=1712140 "Obviously not a commitment to implement, but potentially worth reevaluation" is not "working on it right now", unfortunately. Here we are again, however, in that a completely non-interactive web component still needs JavaScript to render because you need a polyfill to take static, server-rendered HTML and put it in the shadow root. Again, it begs the question of what purpose web components are serving here anyway. The developer has to bend over backwards for both the server side and the client side and there's no meaningful reduction in code at all for either the client or the server.

mmis1000 3y ago

> There's no way to pass server-rendered shadow dom content on the server to the client, There is a proposal for that, although nobody knows whether it will survive in the long run. https://developer.chrome.com/articles/declarative-shadow-dom/ https://developer.chrome.com/articles/declarative-shadow-dom... BTW: the polyfill for this is rather easy, so you may be able to use it even browser today haven't support it now.

superchris 3y ago
It is supported by chromium already and Mozilla has said they'll be working on it

brainbag 3y ago

I like web components especially with the nice tooling that comes with lit, but agree that the lack of server-side rendering and hydration makes them impractical to use compared to other server side progressive enhancement libraries like Stimulus and Alpine. Server-side renderable web components would open up a lot of possibilities for better user experience for multi-page apps.