This shares a lot of similarities to what I’m doing with new version of Semantic UI.

Components - https://next.semantic-ui.com/components

Templating - https://next.semantic-ui.com/templates

Signals - https://next.semantic-ui.com/reactivity

DOM - https://next.semantic-ui.com/query

API Refs - https://next.semantic-ui.com/api

Working on a new version of semantic ui for authoring ui with web components and signals based reactivity without a compilation step.

https://next.semantic-ui.com/

Has Tailwind support out of the box, just had to mod oxide to get non threaded wasm support in the browser

https://next.semantic-ui.com/examples/tailwind

This is the future of web development!

> Has Tailwind support out of the box, just had to mod oxide to get non threaded wasm support in the browser

have you checked unocss? might be more efficient.

It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.

> It’s worth noting this was written by

by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing.

Safari argued that there should be a declarative ways for this 15 years ago

> wrecklessly

<pedantic>

It's "recklessly". "reck" is a very old word meaning "to care, heed, have a mind, be concerned about"; so "reckless" means "without taking heed".

I actually thought it was directly related to "reckon" (meaning "to think or calculate"), but when I looked it up it turned out not to be the case (except much further back in the etymological tree).

</pedantic>

As I get older my brain and my fingers get more and more divorced from each other :)

My brain knows it "reckless", my fingers type "wreckless". Same happens to a few other words, too.

Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to.

My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make browser vendors’ lives easier, not web developers. That’s often excused with “web components excel at ‘leaf‘ components” when what is actually meant is “web components are bad at everything else”.

I would expect an actually good solution that fits in with the web’s architecture to come from the direction of HTMX, not web components.

> Safari argued that there should be a declarative ways for this 15 years ago

True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).

> True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).

Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.).

They did end up proposing declarative template instantiation in 2017: https://github.com/WICG/webcomponents/blob/gh-pages/proposal... but that mostly went nowhere

That looks interesting – certainly a lot simpler and closer to web developers’ needs than what ended up getting standardised.

It really is a shame Apple don’t invest more in WebKit and the web standards process. Although they’ve been doing a lot better over the past few years.

It should have been possible to declare and use simple web-components - which use a template and a CSS class - without any Javascript.

You can with DSD.

You can’t. At minimum you need to call customElements.define().

You absolutely can. It's the primary purpose of the DSD (Declarative Shadow DOM), one of the many new specifications people complain incessantly about.

  <my-component>
    <template shadowrootmode="open">
      <style>
        ::slotted(*) {
          font-weight: bold;
          font-family: sans-serif;
        }
      </style>
      <slot></slot>
    </template>
    <p>content</p>
  </my-component>

Im not sure what you're referring to, they seem pretty straightforward to me. Create a class that extends HTMLElement, implement stuff in connectedCallback and attributeChangedCallback. Return a list of attributes in static observedAttributes. Or use some extended class if you want, there are plenty and they're easy to create your own.

You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through)

Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?

I don't think it's surprising that a feature like web components would require new specs, isn't that how standard web features work?

Usually a new feature:

- doesn't require 20+ web specs

- doesn't forget and then scramble to fix the most basic expected functionality like form participation

- doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans

- hopefully doesn't take 15 years to barely do what others have been doing since time immemorial

Let’s take this example:

    <!DOCTYPE html>
    <title>Example</title>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                }
                ::slotted(img) {
                    border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <img
            src="https://placedog.net/512/342?random"
            width="512"
            height="342"
            alt="A dog"
        >
        <p>Check out this cool dog!</p>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if you want it to be explicit, this could be done with markup not imperative code. But no, it doesn’t work without the pointless JavaScript ritual.

Now, I’ve noticed that since the text is a caption for the image, I should actually use <figure> and <figcaption>. So let’s do that:

    <!DOCTYPE html>
    <title>Example</title>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                }
                ::slotted(img) {
                    border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <figure>
            <img
                src="https://placedog.net/512/342?random"
                width="512"
                height="342"
                alt="A dog"
            >
            <figcaption>Check out this cool dog!</figcaption>
        </figure>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

Wait a sec! The nice round corners on the image have turned into ugly square ones. Why is that?

It’s because web components can’t style anything other than their direct children. You can style the <img> when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an <img> in a <figure> to associate it with a <figcaption>.

What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one:

    <!DOCTYPE html>
    <title>Example</title>
    <style>
        img {
            border-radius: var(--border-radius);
        }
    </style>
    <cool-dog>
        <template shadowrootmode="open">
            <style>
                :host {
                    display: block;
                    font-family: system-ui;
                    margin: auto;
                    width: fit-content;
                    --border-radius: 1em;
                }
            </style>
            <slot></slot>
        </template>
        <figure>
            <img
                src="https://placedog.net/512/342?random"
                width="512"
                height="342"
                alt="A dog"
            >
            <figcaption>Check out this cool dog!</figcaption>
        </figure>
    </cool-dog>
    <script>
        customElements.define(
            "cool-dog",
            class extends HTMLElement {},
        );
    </script>

Now let’s say I want to put a second <cool-dog> element on the page. What does that look like? You define the template once and then just use <cool-dog> a bunch of times? That would be the obvious thing to do, right? Since it’s a template?

Nope. Every instance of the web component needs its own <template>. The best you can do is write some JavaScript to copy the template into each one.

The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.

> First off, what’s with the pointless JavaScript? There’s no need for imperative code here.

Exactly, I'm not sure why you've included the JS. The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively. To quote web.dev "This gives us the benefits of Shadow DOM's encapsulation and slot projection in static HTML. No JavaScript is needed to produce the entire tree, including the Shadow Root." [1]

[1] https://web.dev/articles/declarative-shadow-dom#how_to_build....

> The whole point of the Declarative Shadow DOM is to create shadow roots declaratively, rather than imperatively.

It's a pipe dream that doesn't work in practice. Because on its own declarative shadow dom is useless.

You clearly have an axe to grind, and I'm not particularly interested in proselytizing. If you don't find the Declarative Shadow DOM useful, that's fine!

The example I was responding to was using the Declarative Shadow DOM. My comment was intended to point out the simple fact that the imperative component definition the author was complaining about is superfluous, meaning you can safely remove that entire script from the example.

I'm so fascinated by the few people online who show up to anything web component related just to flame and complain. It's always the same things too.

DSD is useful for SSRing web components, which allows them to render and work without JS. But honestly, I don't get the obsession with doing stuff without JS, it's part of the html/css/js trifecta.

What were these 20 new specs?

After multiple specs had already been pushed through, they finally decided to write down a list of what is still needed.

22 items: https://w3c.github.io/webcomponents-cg/2022.html

In those things like ARIA are not a single spec. It's now close to five different proposals and a huge ARIA Object Model proposal.

Similar thing with Form Associated Controls: it's not one spec. It's a bunch of specs fixing idiotic issues like this: https://github.com/WICG/webcomponents/issues/814

Note: easily half of these only exist because of web components and for web components. Literally nothing else has these issues.

Right but what were these required specs for the existing implementation?

I couldn't parse your question

The main problem with this approach is that there’s a normal distribution of quality of contribution for OS but the community of OS users only benefits from the highest quality contribution. This is normally best achieved by the continuous contribution of the original author(s) who created or maintain the project, as they were the ones capable of designing a project complete and correct enough to achieve traction.

Most projects will actually deteriorate in overall quality if they accept average level contributors work, and certainly face harsh consequences if they accept below average contributions. Highly competent contributors demand higher salaries for their work which can’t be met by the limited funds available to OS, hence most high quality work comes from company sponsored OS or from people who have other means of financing their lifestyle outside of open source.

Thanks for the input. The potential decline in work quality is definitely an issue. We believe this can be mitigated by designing a system where:

1) The maintainer has the final say as to what gets merged. Hence those that submit subpar solutions won't be compensated.

2) As this system grows and more data is acquired, we can implement a reputation system based on a contributor's quality of submissions.

Roundabouts always make think about the two parts of problem optimization, determining your objective function then optimizing. Many classical failure states for real world problems seem to involve having an OF that is incorrect then prematurely optimizing. Think of the rich guy who wants “love at all costs” and then pursues women with expensive gifts and fancy restaurants. You may achieve your aim but perhaps you won’t get what you want.

I think the same is true of roundabouts. One part of the experience that seems almost never to be mentioned is the experience for a passenger when encountering a series of roundabouts. Let’s say you had some bad oysters and are resting your head in the back of the car on a pillow and praying you can make it home before you upchuck your dinner. Perhaps some road engineer decided to put 5 or so roundabouts consecutively to “optimize traffic flow” then somewhere around spin number 3 you lose your stomach on the backseat. Perhaps the trip was not “optimal” for you.

The Design of Design was one of the primary inspirations for my open source project Semantic UI.

"[Progressive truthfulness] is perhaps a better way to build models of physical objects...Start with a model that is fully detailed but only resembles what is wanted. Then, one adjusts one attribute after another, bringing the result ever closer to the mental vision of the new creation, or to the real properties of a real-world object

...Starting with exemplars that themselves have consistency of style ensures that such consistency is the designer's to lose."

Frederick Brooks - The Design of Design

I also run a customizable start page http://myfav.es

its cost $100/month for 10 years to run but i keep it up because a lot of schools use it to help set up their shared computers and i couldn’t ever have the heart to shut it down.

Once you set it up you can also run it entirely offline using app manifests from myfav.es/fast if you don’t like the idea of your new tab experience being slowed down by web requests.

Why so expensive?

Certainly not because of maintenance costs since he's still running PHP 5.5

I detest this meme where supposedly every hour you have is translatable to money.

It isn't as if you can sell every hour of your time whenever you feel like it. If it were that way, you'd be able to say: "I pay $1500+ for going to the toilet each month":

> A software engineer who makes $100,000 a year, working 40 hours a week for 52 weeks, makes about $50/hour.

So let's say 1 hour of toilet time per day on average, so: 30 * 50 = 1500.

What nonsense.

> I detest this meme where supposedly every hour you have is translatable to money.

> It isn't as if you can sell every hour of your time whenever you feel like it.

Yes, but a public good has costs whether or not you want to acknowledge them.

On top of that who on earth would price their free time at same as they do their job? My free time is 2-4x the job

> "I pay $1500+ for going to the toilet each month"

It's a little less (I don't need that long), but most importantly, my boss is paying for most of that.

Don't shit where you eat? Instead, shit where you work?

Makes sense ;)

I think the saying is "Boss makes a dollar, I make a dime. That's why I poop on company time."

I very much doubt they where talking about this, and where instead referring to their hosting costs.

Do browsers even support app manifests anymore? I thought they'd abandoned them in favor of service workers.

Is this not the exact same feature-set the browser's built-in 'start pages' already provide?

how much do you make out of it?

Nice vignette, thanks for sharing this.

I find this website to be a fairly amusing example of how marketing co-opts real, generally easily expressible ideas to be an amalgamation of highly targeted jargon and pointed funnels for personal information collection.

Generally any well intentioned person who worked on an idea like this would be delighted to share what their product does specifically and clearly - unashamed screenshots of interesting visualizations (maybe half cooked), telling descriptions of specific numbers being crunched and their utility as predictive indicators of project success, verified with statistical certainty.

Sadly this kind of naive, honest approach is very regularly usurped by the machiavellian machinery of the professional art of convincing others to buy things, which is narrative focused and story driven with very little concrete substance.

Not blaming the author here, I understand the motivations at work and sympathize with them, but still sometimes find myself dumbfounded by the results.

I think the confusing thing here is the use of the term “design token” to mean variables/constants used for css theming.

I think they need this jargon to make it seem like something more novel than the well established practice of storing css constants as theming variables—something OSS UI component libs, or even wordpress, has been doing pretty well for a long time.