Joe Pea

Like would you just ship Solid signals and templating as part of browser APIs (along with a standards proposal) and call it a day? Or would you do something else?

But what I'm really curious about is, what would you want for a browser to be like, if you owned the browser. If Solid as a whole was a web browser *and* a component library+metaframework, what would you do to the actual browser in terms of specs all other browsers could potentially adopt?

Most of the myriad of ways to do things poorly existed before WCs, and now we can wrap them into a component.

With DCEs, I think we can highly encourage patterns where those are parsed before they are rendered (effectively similar to a Solid component hydrating without FOUC).

Yeah I wouldn't say WC have a big impact on the likelihood of jank. There are a lot of factors. I agree there are lots of ways to write bad apps, and discipline/knowledge is needed to do things well.

I believe conceptually we hope things like Declarative Custom Elements reduce that barrier.

Can you post some examples? For example, can you make an example of a custom element without a subtree and with a subtree, both styled? Curious to see what the ideal usage would look like.

The nice thing about it is being able to simply write code, open it in any browser, and it works. But of course for a team that can afford tooling, they can optimize.

Additionally, following some standards such as using `new URL('./path/to/style.css', import.meta.url)`, modern bundlers can statically detect this, and embed the styles in a bundle, eliminating network fetches by converting the URLs into blob or data URLs.

Only if the app runs before styles are imported, then yeah. Otherwise one could have a loading animation be displayed while the module graph is loaded, and the entry point in that module graph hides the loader (implying all other modules have loaded).

Just peeked at style-observer. It starts to solve the problem, and at least lays out the concept. But it looks too simple to catch all the scenarios. At some point I hope to spend the time to make a concept that catches them all.

Yeah that's what I was wondering about. It's tricky to observe CSS state in JS. It involves putting MutationObservers in all trees (f.e. shadow trees), monkey patching global APIs that MutationObserver might not catch, observing animation events, creating animation frame loops for animations, etc.

I get "invite invalid". Maybe that invite had an expiration date. Invites can be given no expiration date, but that's not the default.

Some Custom Element Manifest tools provide the support too.

For example functions as DOM components that are visible only in devtools element inspector when that is opened, but not via regular DOM APIs (because they're just lexical scopes)?

Joined!

At the same time, that's why it's a lot easier to make jank than non-jank. A counter example is Android or iOS platforms where devs have far-higher-level default blocks to build with that easily lead to non-jank experiences without having to make an incredibly high number of choices.

Yeah true, but this was pointing out that the TS types wouldn't include support for function components (like JSX does).

On the other hand, if something like developit htm were standardized (with syntax updated to allow full DOM control) then it would cause TS to support functions for sure.

This is so nifty! Use this custom element to add comments, for example, to a static blog post. Readers can comment on Bluesky!

Based on the README, I don't see the advantage. The examples use this.innerHTML. Can't I use this.innerHTML with plain custom elements? Can you explain more?

AssemblyScript maps very minimally to Wasm, so the runtime in the browser is very small compared to C/C++/Rust. Makes the bindings with JS very simple too. I've compiled Custom Elements to Wasm via AssemblyScript with my asdom bindings, so the next step would be adding a format.

Yeah it basically comes down to agreeing on a data struct all languages can produce. I'd start with typed arrays from AssemblyScript which is TypeScript compilable to Wasm, and perhaps make libs for other languages to match the same structure. inevitably some libs are gonna be needed per language.

bsky.app/profile/ryan...

It has to do with web components because HTML supports those, and it means functional frameworks cannot easily adopt TemplateResult in its current form, it seems. TLDR they will ignore it. I wish it was more usable by non-custom-element frameworks like @developit.dev htm is.

If a built-in template system made it easy to use functions, then it means the output would be very easy for Solid to use for anything other than DOM output.

As I mentioned custom elements can evaporate too, if someone really wanted to. The real issue I think is that Solid function components wouldn't be very well supported with this native DOM template format, which means Solid will continue to use its own.

A framework like Solid cannot really adopt a standard that has syntax space only for custom elements for example, which is a downside of the current template proposal regardless of I myself only use custom elements.

Function components are something many people use. They definitely are not part of web standards, but people who like function components would definitely benefit from some sort of semantics being made, such that new function frameworks could easily exist with it.

Hmm, that seems like an implemention choice. The el.render() part could have a different implementation with what it does with TemplateResult such as skipping <template>

Functions are also a well established unit for code reuse, so if they could be supported, why not? A lot of people like and prefer functional components.

I would want the feature to be native to avoid having to write a new template tag just to use the built in one every time I open an HTML file or a codepen. The syntax covers standard functionality everyone uses via JS, and this makes it declarative so that reactivity is easily mappable to it.

Like maybe there doesn't need to be much semantic of how functions work. Frameworks could step in there, while users still using the native html template tag directly