Live data from Hacker News

How we use web components

github.blog

11–20 of 84 posts

Re: How we use web components

#11
I’ve been using webcomponents heavily in my latest project. Built out a full SPA using vanilla js. They are not without problems, but GitHub is using them perfectly. GitHub isn’t pushing them to do what they aren’t yet good at. They’re amazingly suited for consistent components, especially view oriented ones. GitHub also has in my opinion made the correct choice to make their own base element rather than using a standard library one like lit-html. A good base element has two things in my mind - styled component functions and shared util functions specific to your app. It’s amazingly easy to make a simple set of styled component base functions. Here’s the one I made for my project: https://github.com/jjcm/soci-frontend/blob/master/components... (lines 6-32 for the styled component functions). The rest of your component should be shared functions specific to your use case. Once that base class is there they’re so easy to use.

Two caveats with webcomponents however. The first is Safari will be the bane of your existence. You should dev in safari if you can. If it works there it will work in all other browsers. The second is stay away from form elements, for now. Or if you do, use an encapsulating component that inserts a slotted input into the light dom. The form registration api isn’t fully supported yet except by chrome, and even then it’s a bit rough around the edges.

Re: How we use web components

#12
post #8
post #6

How well do web components work in the context of SEO and pagespeed scores?

I’ve had mixed results. Page speed is excellent - I built out an SPA with ~60 or so components and my uncached first paint happens in about 400ms. Cached I get 250ms (this is on prod so it includes the server latency). SEO is more difficult. I’ve been using the npm package prerender to serve up the page properly for Google/Facebook/Discord bots and for crawlers, and since using that I’ve had successful parsing, but a…

I’m pretty actively following a lot of the web components community so I thought I would jump in here with some hopefully helpful information. Depending on what you mean by SEO it’s worth noting that for a while now Google and I believe Bing and a few others haven’t had any kind of requirement to pre-render content. You can just serve standard web components or any kind of SPA style front end and it will get indexed just fine, no penalties and no real issues unless you’re doing something particularly strange.

However, one of the more exciting projects in the web components space (lit.dev) now also supports proper SSR as well which is a very new thing in the world of web components. They are trying to build it in such a way that any other library can take advantage of through a common interface.

In fact there are some kind of early stage talks happening over here https://github.com/webcomponents/community-protocols where a bunch of companies like Google, Adobe, ING and others are trying to develop some open protocols on a whole bunch of topics to improve interoperability between various libraries so that no one has to buy in 100% to any one setup.

Re: How we use web components

#13
post #4

For those who have used tools like Hotwire, what has your experience been like? How does it compare to something like Vue or React?

I've just started using it on a fairly simple project so I only have first impressions. But it seems like for a UI that's not too complex it could be a big timesaver. I need to spend more time with it before I can decide where I'd draw the line and switch to a full blown SPA but it definitely expands the class of apps you can build without much JS.

State management on the front end? Is that the differentiator that forces the need for a full SPA framework? Anything else that can't be done purely with web components?

Re: How we use web components

#14
At my work web components were purposed recently for creating a ui component library of which I was skeptical. On the whole I was skeptical of web components viability and future but this post relieves some of that tension.

The other thing I was worried about was that it was planned to after writing this web component lib, to wrap these components in React. Does anyone have any experience or insights into a React wrapped web component lib?

Re: How we use web components

#15
post #4

Earlier quoted context omitted.

I've just started using it on a fairly simple project so I only have first impressions. But it seems like for a UI that's not too complex it could be a big timesaver. I need to spend more time with it before I can decide where I'd draw the line and switch to a full blown SPA but it definitely expands the class of apps you can build without much JS.

State management on the front end? Is that the differentiator that forces the need for a full SPA framework? Anything else that can't be done purely with web components?

I'm sure there are people much better qualified to answer this than me but it feels like there would be a point at which trying to manage a very complex UI with all these little HTML fragments over the wire would get unmanageable. I'm just guessing though. So far I haven't done anything that complex with it. I guess I'd also miss having Typescript for a UI with a lot of components.

You can do some client-side state management with Stimulus though.

Re: How we use web components

#16
For my sideproject (https://profilehunt.net) I have been using a somewhat similar approach. I use Github ViewComponents (https://github.com/github/view_component) for componentization of Rails views. It helps with more modular views which are easier to debug (errors usually point directly to the line in view code, unlike Rails views). I use StimulusJS (https://stimulus.hotwire.dev/) for Javascript interactivity. Stimulus is great, it allows me to write more structured reusable JS controllers without global event listeners and ids. For my project I have heavily used these two to create a Trello like board which behaves like an SPA. State and routing is still on server. I just fetch HTML on clicks and render it using Stimulus. It is usually fast enough as I only fetch small components and append them to DOM, but in case it's not I use loading animations. If you want to take a look at how it is done, this blog post (https://boringrails.com/articles/hovercards-stimulus/) explains it really well.

edit: Fixed a link and grammar.

Re: How we use web components

#17
post #9
post #3

On the topic of web components, does anyone know if AMP is still using them? I heard they switched over to Preact but I couldn't find an official announcement.

You can totally write web components with Preact: https://preactjs.com/guide/v10/web-components/ From a quick skim of their docs, it looks like AMP still uses web components. The nice part about web components is that the users of a library don't have to care about how it's implemented, so switching to preact is a transparent change.

React still doesn't play seamlessly with WC right?

Re: How we use web components

#18
Something I've never understood how to handle with vanilla web components: if there's some state that needs to be shared and kept in sync between multiple components, how do you do it?

(For comparison, in React you can pass the state down as props from a common ancestor, and in Clojure frameworks all app state is in a giant object referenced by components as needed.)

Re: How we use web components

#19

Something I've never understood how to handle with vanilla web components: if there's some state that needs to be shared and kept in sync between multiple components, how do you do it? (For comparison, in React you can pass the state down as props from a common ancestor, and in Clojure frameworks all app state is in a giant object referenced by components as needed.)

The nice thing about web components, is that this problem is orthogonal go the componentization of the components.

How do you pass the state between an input button and a label?

Whatever technique you choose to do that (including react!) you can use it with web components.

Some frameworks like react though also solve the componentization problem, so since web components are not necessary there (and weren't ready yet when react first came out), they tend to not get used to react and friends, even if they would technically work.

Re: How we use web components

#20
post #9

Earlier quoted context omitted.

You can totally write web components with Preact: https://preactjs.com/guide/v10/web-components/ From a quick skim of their docs, it looks like AMP still uses web components. The nice part about web components is that the users of a library don't have to care about how it's implemented, so switching to preact is a transparent change.

React still doesn't play seamlessly with WC right?

It seems to work okay as in you can use them: https://reactjs.org/docs/web-components.html

But it is not fully integrated with react, you have to do some work for interaction: https://www.sitepen.com/blog/wrapping-web-components-with-re...

That link is a few years old though I think the principle is the same.

Post reply on HN