151–160 of 180 posts
I love it when I visit one of my pages and use Lighthouse to check it out and have nearly straight across 100 scores. Also, I usually have really great performance on phones as well because the pages are so light and quick to render.
I don't see the need for Lit anymore. Lately I have just been raw dogging web components without any libraries. Having a nice templating system like JSX on the server makes it a breeze. Part of using web components, for me, is that it is just javascript. There is no upgrades or deprecations to think about. Of course those things still exist on the server though, but it is easier to maintain it there.
I find that there is little practical difference between "html" tagged template literal and writing JSX. Not to mention there is a compilation step in JSX.
Earlier quoted context omitted.
Lit has always been designed partially as a prototype for where web component standards could go in the future. That's a big reason Lit is fairly conservative and un-opinionated. It doesn't try to undo or paper-over any of the DOM APIs, but add to them instead. There is a proposal in TC39 for native signals, which I think would make a huge dent towards library-less reactivity. I'm also working on a proposal for nativ…
I hope there can be ways without JS to populate templates with data - autoloaded from sources. This would tremendously increase the number of JS free web-sites. Also wish the web-components standard did not mandate the use of JS. It should be possible to define simple web-components (HTML+CS) declaratively and have this officially supported in standard and implementation
--- start quote ---
I think we're stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turning complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat.
Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you'd sent markup down the wire in order to get back to the same value that was going to be provided to you if you'd done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it's stupid. Gmail does that because that's how you can actually deliver the functionality of Gmail in a way that's both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket.
....
They're the sorts of things that you use when the semantic that you're trying to express is so far away from what HTML natively has a semantic for, that you're willing to go and be completely self served for it. Taking on for yourself accessibility, UI, UX, internationalization, localization, performance, theme ability; all of this stuff is mostly taken care of for you by HTML.
--- end quote ---
14 years later, web components depend on JS to:
- participate in forms
- solve accessibility issues (not yet, but coming through a yet another JS-only standard)
- SSR is still mostly tied to JS and specific JS frameworks (and Declarative Shadow DOM doesn't really solve the issue because it requires you to duplicate a lot of code). See also https://ionic.io/blog/the-quest-for-ssr-with-web-components-...
- CSS modules and other imports that are moved entirely into JS
etc. etc.
-----
Slight off topic. From the same talk:
--- start quote ---
Now, we can do some of that today. We can go and look at the top million pages and figure out which JavaScript library that they're using, which features are being most heavily used, we can put those things in DOM. But is that the right place for them? It's a hard thing to figure out.
--- end quote ---
I wish they spent time figuring that out. We wouldn't have to wait a few decades for https://open-ui.org to slowly make its way into the browsers.
Earlier quoted context omitted.
Web components are 14 years old, and still have the most basic issues and problems that even a 6-month-year-old framework would ashamed to have.
I await your in depth critique on the front page.
No worries, web components themselves have a very nice critique in the form of their own community report https://w3c.github.io/webcomponents-cg/2022.html listing all the issues that many people had been taking about for literal years before this report.
Earlier quoted context omitted.
> No shadow DOM Funny you should say that when the current advise for web components is to avoid Shadow DOM (almost like the plague) > no web components As in? > no template strings Why would React need template strings? React is not the only framework that doesn't use template strings for anything (Vue, Solid, Svelte come immediately to mind). And it's hard to accuse those of being behind the times when Solid is lit…
> the current advise for web components is to avoid Shadow DOM (almost like the plague) Could you provide the source for this advice?
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
--- end quote ---
And probably continued in HTML Web Components https://blog.jim-nielsen.com/2023/html-web-components/
A more technical and measured take on Shadow DOM is here: https://nolanlawson.com/2023/12/30/shadow-dom-and-the-proble...
Earlier quoted context omitted.
Shadow DOM is optional in Lit - you can just disable it on a per-component basis.
causes a bunch of things to no longer work though - slots, style encapsulation, ...
Can you use style encapsulation and slots without Shadow DOM? Why can't you? I only need the horse, not the horse, and the cart, and the driver, and all the cargo in the cart.
You can't because people pushing all this stuff forward never ever stopped to think whether this was a good idea, and never ever talked to anyone outside of their own group.
[1] I will keep quoting this report by Web Components Working Group to death:
--- start quote --
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
...
Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time.
...
Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality.
--- end quote ---
Earlier quoted context omitted.
> the current advise for web components is to avoid Shadow DOM (almost like the plague) Could you provide the source for this advice?
It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only building leaf nodes so they don't need composition with slots. As soon as they try to build any kind of container element they hit big problems.
> People coming from React-land can have a hard time reasoning about the difference between a custom element and a template render function and when best to use each
> This abuse of the component system can indeed lead to a massive explosion in nodes on a page and the performance tanks because of that
I know I certainly have that hard time deciding when I need a custom element and when a render function.
I used lit for a few small components on my blog, https://pdx.su , and have mostly ignored them since writing them two years ago. When I recently had to update them with a new feature, I was extremely pleased that the usual js experience of finding out that I was a million versions behind wasn't there.
I'm confused, there's been a new major version every two years for the past decade. (Polymer 1 in 2015, Polymer 2 in 2017, Lit 1 in 2019, Lit 2 in 2021, Lit 3 in 2023.)
As I recall inside Google it was maybe one in a thousand elements that needed any changes at all. I updated the entire internal codebase of many tens of thousands of elements in a couple weeks of part time work.
But more importantly Lit 2 and Lit 3 are interoperable, so there's not the same pressure to update. When an element or library updates from Lit 2 to Lit 3, it can do that as a point release, because its public API is the same. This really reduces the amount of upgrade toil you have to deal with.
Earlier quoted context omitted.
> You have a very large axe to grind against web components and Lit Yes, yes I do. Because Web Components are almost 15 years now, and they still struggle with the most basic of things. How's that abandoned roadmap going? https://w3c.github.io/webcomponents-cg/2022.html > No, there are no custom JavaScript rules. Templates have some rules. That is "here are regular JS functions. However, you cannot use them as regula…
As a third party I can't help but notice that the only one doing the "shitting" here, is you.