When claiming copyright, you should mention the date of first publication and if applicable, the last significant revision. Not the current date.

Q) what is the purpose of the copyright year?

A) to always show the current year, apparently!

Correct. A later year is actually a weaker claim to the copyright.

Tangential, but what's the state of web components at the moment? As a backend engineer, they were very appealing early on since I didn't want to deal with adding an entire framework onto a simple project. How'd that work out? It seems like the big frameworks are still kind by a mile and they provide a much easier developer experience still. Am I wrong there?

I don’t think they will go anywhere, too many different concepts and technologies have been packaged without clear goals. Some concepts like shadow DOM are useful in other contexts though, but templating and data binding is botched in my opinion.

Is there a good reason to use a shadow root for this instead of just directly setting innerText

Only when you really want to encapsulate style or ensure GUI.

This should/could be part of a generic <app-footer) Web Component which ensures all that required is required.

We use a single <app-footer> for over 15 projects, it extracts domain namens to set the correct links.

Its value showed when we needed (basic) A/B tracking on all sites, we only had to edit this one <app-footer> file

There are some issues with this code: https://gist.github.com/ceving/6e65886e04563ed9e6e42cc5f8d3f...

Safari has support for "is" attribute now?

Nope, was marked as WONTFIX: https://bugs.webkit.org/show_bug.cgi?id=182671

There was some more discussion in the webkit standards but looks like the answer is still unchanged: https://github.com/WebKit/standards-positions/issues/97

for over 10 years now Apple has stated it won't implement Customized Built In Elements ( "is" extends )

If you want to dive in deep: https://stackoverflow.com/search?q=liskov

Here is Apple debating all non Liskov believers: https://lists.w3.org/Archives/Public/public-webapps/2013OctD...

*going back over 10 years to 2013, Who said Web Components was a fad*

Probably not. But the global attribute "is" is not necessary. It is just a bit more obvious.

Is it necessary to use a web component to do what you could do with a snippet of Javascript? What is the use case for this?

Also, as a JS developer, even if you want to auto-update the end year to the current one, why would you do that on the client? To make the layout shift? Or to display (c) 2024-2038 on clients with wrong date settings?

If it's statically generated, add the year at build time. If it's server-generated and dynamic, don't do it in JS I guess? I mean, why? It has only downsides.

Could it be that this serves another purpose, perhaps showing something close to the minimum code that's required to create a web component?

Seems like it pretty much is a tiny snippet of JavaScript, it's just all professional and standardized and best-practices-y

I had a snippet in my HTML for this. But the snippet was rejected by a content security policy.

Excellent example for someone trying to wrap their arms around web components.

this code isn't what's rendered. there's something about `this.textContent - ${year}` but that's not what we're seeing in output.

Yeah, I'm very confused by this. Why is the example also showing a hard-coded 2023 in the component usage? Shouldn't the component be responsible for rendering that?

I believe it's because the `${this.textContent} - ${year}` will render it as `2023 - 2024`. The hardcoded 2023 can be whatever you want as to indicate the start of the copyright.