If you're using web components (or just custom elements without web components) and want to do server-side rendering, definitely check out Enhance: enhance.dev/. That way you can have all the benefits of custom elements and web components, and still have the SEO and performance benefits of SSR. For simpler pages, you might not even need any client-side JS at all and can still use custom elements and slots to render your HTML.
Yeah and they even have a WebAssembly version that lets you integrate it into any server-side language with WASM support, so it's not limited to JS on the server.
Interesting take - to each their own. There are certain aspects of how they recommend managing state and passing it to components that I didn't like that much from a DX standpoint, but you don't have to use it in that way if you don't want. At the end of the day it's mainly just a tool for SSR, so that you can use the same custom HTML elements as on the client without having to do double the work by writing your server components with some other technology. There are also other tools out there for server-side rendering custom elements for those who want an alternative to Enhance. The important thing is that unless your app is behind a login, and you know that your users will all have a fast internet connection, server-side rendering is important for optimal SEO and UX. If it weren't for that then I would just advocate for using custom elements and web components directly without any other tools.
I wouldn't know what the benefit is to prerender web components and even less custom elements?
I think the most uses for web components will have a personalized output, like a user name, the content of a shopping cart. That is not relevant to score higher on search engines.
For the user experience I would think devices are fast enough to render a limited set of start data. You are not going to parse thousands of lines of json in a web component?
I think it wrong to see web components as an equivalent of React or Vue. Web components are not meant to generate full pages. They should be used when the combination of HTML, CSS and javascript becomes cumbersome.
Well designed Custom Elements do not require pre-rendering because the content is pure markup and JS is only added for interactivity. Ideally, SSR for a web component would simply involve populating slots from a database query, like any other server generated HTML. This is most beneficial for above-the-fold content. Beyond that, constructing complex elements offscreen is no big deal, especially if you preload components that will be used on additional views.
That said, I still think Enhance is a neat concept and a great example of how these new standards are driving the development of new frameworks.
@xwero there are a lot of benefits of a component-based architecture for building web apps—take for example a reusable Card component or Image component that might be reused many times to render the initial HTML for a page. If in your use cases you don't need any components until the user interacts with something on the client, great—and I would agree you don't need something like Enhance in that case. Enhance is very focused on progressive enhancement and the phrase they use is "HTML-first"—they really try to maximize what you can do with HTML and CSS in the initial HTML returned by the server, only introducing actual client-side web components where they're actually needed (in fact they have examples of selectively loading JS so you might not even have JS at all in some pages of your app, or others where it's just vanilla JS and it's not necessary to bring in any of Enhance's client-side libraries). I suppose you could think of it a bit like if you had server-side "components" in a language like PHP that you used to build the HTML of your page, but instead of using PHP you're using JS and syntax that matches the custom elements spec so you have nice consistency between server and client code.
Behind the scenes, the basic technique they take advantage of is the fact that you can put child elements inside of a custom element, and the visible result will be the same as if you did <my-component></my-component> and have JS code in the MyComponent class setting its innerHTML. So that's what it does to achieve server-side rendering, and then if you need to change the HTML on the client in response to some event, that's when it becomes a true web component (otherwise it just stays as a custom element with plain HTML).
You don't need web components to have a component based architecture. It has been done for years with classes as a hooks.
Progressive enhancement is a term I first seen after ajax was introduced in internet explorer 6.
HTML-first is a term that was invented to make frontend developers aware that using React or Vue for every website is not a good idea, in my opinion.
Components that can be used on the server and in the browser are called isomorphic components. I think is a solution in search of a problem because the tasks of the environments are different. On the server the main goal is to push the data out as fast as possible, and in the browser it is all about showing the data as fast as possible.
I'm sorry to burst your bubble but Enhance brings nothing new to the table.
I am still struggling when to use web components. I don't see a lot of difference between <my-component></my-component> and <div class="my-component"></div>. I even think the class way is more versatile.
Web components have encapsulation for CSS and javascript, but you don't need it if you target the right classes.
The only benefit I see is that they don't need a runtime like React or Vue, so they load less javascript if you do it correct.
I think web components have their place, but it our task to use them wisely.
Well it's great then that we have so many technologies to choose from—I was never saying that Enhance was something everyone needed or everyone should use :-) I did want to correct the record though and say it does bring something new to the table for a large number of use cases. That's not something I'm going to be able to explain just in comments on a blog post, but I would just like to point out that I also remember when the term "progressive enhancement" was first talked about, and so do the creators of Enhance. The creators of it are a very mature team who have seen things develop from the early days of vanilla JS to jQuery and then all the other libraries and frameworks, trying various libraries and seeing their pros and cons (I also did this), and then creating Enhance after a lot of careful thought and consideration to fill a gap that hadn't already been filled by other approaches. I have no affiliation with the Enhance team, and TBH I've only worked on some very simple side projects with it because at my job we use React... But as someone who has been around and studied different approaches to frontend development for many years, I do think their philosophy makes sense for a lot of websites—not all of course (no silver bullets and all that)—and I have seen its benefits by playing around with it.
So based on what I have seen and compared it with, I think you are making an unfair assessment when you say it brings "nothing new to the table". That may well be true for the apps you have built, and it also might not be your cup of tea even if you were using it for a site that's an ideal use case for it. So you're entitled to your opinion but it's an opinion and not a fact that's true for everyone.
I might have been too snarky with my comment. The thing I fear the most is that frameworks that go all in on web components are going to give another blow to the already tainted perception of web components. For me web components are not a React or Vue replacement, that is why I mentioned we should use web components wisely.
I agree that smart people put together the framework. But they are selling you their vision like any other framework. If you see a benefit in that vision, use it.
BTW, it's possible that in the future, the web components spec might have more direct support to facilitate web component use cases that benefit from server-side rendering - for example, see this proposal (which is also interesting for other reasons): github.com/WICG/webcomponents/blob...
While I don't imagine that the W3C would ever expand its scope to have official specifications for server-side technology, I think it's certainly in the realm of possibility that eventually they could have some official recommendations (not a spec but a well-documented pattern) that tools like Enhance, Lit (the server-side part), etc. could implement in a more standards-based way.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you're using web components (or just custom elements without web components) and want to do server-side rendering, definitely check out Enhance: enhance.dev/. That way you can have all the benefits of custom elements and web components, and still have the SEO and performance benefits of SSR. For simpler pages, you might not even need any client-side JS at all and can still use custom elements and slots to render your HTML.
Awesome! Thanks for sharing! This looks very slick, I will definitely be giving it a test drive.
Yeah and they even have a WebAssembly version that lets you integrate it into any server-side language with WASM support, so it's not limited to JS on the server.
It is a very opinionated solution, I like my backend code a lot more malleable.
Also all the HTML I seen in the documentation is a javascript (template) string. This is something I avoid using web components.
So it is not my cup of tea.
Interesting take - to each their own. There are certain aspects of how they recommend managing state and passing it to components that I didn't like that much from a DX standpoint, but you don't have to use it in that way if you don't want. At the end of the day it's mainly just a tool for SSR, so that you can use the same custom HTML elements as on the client without having to do double the work by writing your server components with some other technology. There are also other tools out there for server-side rendering custom elements for those who want an alternative to Enhance. The important thing is that unless your app is behind a login, and you know that your users will all have a fast internet connection, server-side rendering is important for optimal SEO and UX. If it weren't for that then I would just advocate for using custom elements and web components directly without any other tools.
I wouldn't know what the benefit is to prerender web components and even less custom elements?
I think the most uses for web components will have a personalized output, like a user name, the content of a shopping cart. That is not relevant to score higher on search engines.
For the user experience I would think devices are fast enough to render a limited set of start data. You are not going to parse thousands of lines of json in a web component?
I think it wrong to see web components as an equivalent of React or Vue. Web components are not meant to generate full pages. They should be used when the combination of HTML, CSS and javascript becomes cumbersome.
Well designed Custom Elements do not require pre-rendering because the content is pure markup and JS is only added for interactivity. Ideally, SSR for a web component would simply involve populating slots from a database query, like any other server generated HTML. This is most beneficial for above-the-fold content. Beyond that, constructing complex elements offscreen is no big deal, especially if you preload components that will be used on additional views.
That said, I still think Enhance is a neat concept and a great example of how these new standards are driving the development of new frameworks.
@xwero there are a lot of benefits of a component-based architecture for building web apps—take for example a reusable Card component or Image component that might be reused many times to render the initial HTML for a page. If in your use cases you don't need any components until the user interacts with something on the client, great—and I would agree you don't need something like Enhance in that case. Enhance is very focused on progressive enhancement and the phrase they use is "HTML-first"—they really try to maximize what you can do with HTML and CSS in the initial HTML returned by the server, only introducing actual client-side web components where they're actually needed (in fact they have examples of selectively loading JS so you might not even have JS at all in some pages of your app, or others where it's just vanilla JS and it's not necessary to bring in any of Enhance's client-side libraries). I suppose you could think of it a bit like if you had server-side "components" in a language like PHP that you used to build the HTML of your page, but instead of using PHP you're using JS and syntax that matches the custom elements spec so you have nice consistency between server and client code.
Behind the scenes, the basic technique they take advantage of is the fact that you can put child elements inside of a custom element, and the visible result will be the same as if you did
<my-component></my-component>and have JS code in theMyComponentclass setting its innerHTML. So that's what it does to achieve server-side rendering, and then if you need to change the HTML on the client in response to some event, that's when it becomes a true web component (otherwise it just stays as a custom element with plain HTML).This video is a good introduction for anyone interested to learn more:
youtube.com/watch?v=RaDYBFC2lHY
You don't need web components to have a component based architecture. It has been done for years with classes as a hooks.
Progressive enhancement is a term I first seen after ajax was introduced in internet explorer 6.
HTML-first is a term that was invented to make frontend developers aware that using React or Vue for every website is not a good idea, in my opinion.
Components that can be used on the server and in the browser are called isomorphic components. I think is a solution in search of a problem because the tasks of the environments are different. On the server the main goal is to push the data out as fast as possible, and in the browser it is all about showing the data as fast as possible.
I'm sorry to burst your bubble but Enhance brings nothing new to the table.
I am still struggling when to use web components. I don't see a lot of difference between
<my-component></my-component>and<div class="my-component"></div>. I even think the class way is more versatile.Web components have encapsulation for CSS and javascript, but you don't need it if you target the right classes.
The only benefit I see is that they don't need a runtime like React or Vue, so they load less javascript if you do it correct.
I think web components have their place, but it our task to use them wisely.
Well it's great then that we have so many technologies to choose from—I was never saying that Enhance was something everyone needed or everyone should use :-) I did want to correct the record though and say it does bring something new to the table for a large number of use cases. That's not something I'm going to be able to explain just in comments on a blog post, but I would just like to point out that I also remember when the term "progressive enhancement" was first talked about, and so do the creators of Enhance. The creators of it are a very mature team who have seen things develop from the early days of vanilla JS to jQuery and then all the other libraries and frameworks, trying various libraries and seeing their pros and cons (I also did this), and then creating Enhance after a lot of careful thought and consideration to fill a gap that hadn't already been filled by other approaches. I have no affiliation with the Enhance team, and TBH I've only worked on some very simple side projects with it because at my job we use React... But as someone who has been around and studied different approaches to frontend development for many years, I do think their philosophy makes sense for a lot of websites—not all of course (no silver bullets and all that)—and I have seen its benefits by playing around with it.
So based on what I have seen and compared it with, I think you are making an unfair assessment when you say it brings "nothing new to the table". That may well be true for the apps you have built, and it also might not be your cup of tea even if you were using it for a site that's an ideal use case for it. So you're entitled to your opinion but it's an opinion and not a fact that's true for everyone.
I might have been too snarky with my comment. The thing I fear the most is that frameworks that go all in on web components are going to give another blow to the already tainted perception of web components. For me web components are not a React or Vue replacement, that is why I mentioned we should use web components wisely.
I agree that smart people put together the framework. But they are selling you their vision like any other framework. If you see a benefit in that vision, use it.
BTW, it's possible that in the future, the web components spec might have more direct support to facilitate web component use cases that benefit from server-side rendering - for example, see this proposal (which is also interesting for other reasons):
github.com/WICG/webcomponents/blob...
While I don't imagine that the W3C would ever expand its scope to have official specifications for server-side technology, I think it's certainly in the realm of possibility that eventually they could have some official recommendations (not a spec but a well-documented pattern) that tools like Enhance, Lit (the server-side part), etc. could implement in a more standards-based way.