One decision I made is to specifically not compile to JS. JS/Wasm interop is good enough with Wasm GC that I made the choice to focus on Wasm-only constraints and semantics and not worry about how things like the types being wrong, or how ints translate to JS, how to handle null vs undefined, etc. JS GCs collect objects and cycles across the Wasm boundary, and with the JS string built-ins you can handle strings efficiently.

I couldn't load your demo, btw.

https://fair.pm/

FAIR has a very interesting architecture, inspired by atproto, that I think has the potential to mitigate some of the supply-chain attacks we've seen recently.

In FAIR, there's no central package repository. Anyone can run one, like an atproto PDS. Packages have DIDs, routable across all repositories. There are aggregators that provide search, front-ends, etc. And like Bluesky, there are "labelers", separate from repositories and front-ends. So organizations like Socket, etc can label packages with their analysis in a first class way, visible to the whole ecosystem.

So you could set up your installer to ban packages flagged by Socket, or ones that recently published by a new DID, etc. You could run your own labeler with AI security analysis on the packages you care about. A specific community could build their own lint rules and label based on that (like e18e in the npm ecosystem.

Not perfect, but far better than centralized package managers that only get the features their owner decides to pay for.

But my only thought on this is: Eleventy is an awesome name.

And in most functional systems the one-time setup function would return the render function so the render function can close over state.

Which is pretty much what a class with fields, a constructor, and a render method give you.

React's "functional" components are simply poor approximations of classes. Instead of easy to read and reason about class fields, you put state in useState() function classes that are effectively named by their appearance order in source and who's current state you can't introspect with dev tools!

The component function mixes one-time setup (which should be a class constructor) with repeated render calls (which should be a method), so those of course have to be separated by putting the one-time work inside of a closure inside of the repeated should-have-been-a-callback function. Event listeners and other callbacks are another huge mess. Don't forget useMemo() or useCallback() (but which?).

It's actually quite mad.

And the differences between classical and prototypal inheritance basically don't even pop up under normal class usage in JS: just use class fields, don't mess with the prototype chain, and don't dynamically add or delete properties - all things that are how classical inheritance works - and things just work like you expect.

Most WordPress sites could just be static, but WordPress has a nice editor interface, so they're not - unless you use a SSG plugin. Building that into the core workflow (which I believe Astro supports) and giving users a nice hosted editor that produces a static site would be welcome innovation.

Some fonts are close enough that I don't know if I'd choose one over the other consistently, and I'd be curious to see a percentage score of how much I like a particular font.

Two more OS-level windowing features I'd like to see in browsers:

- OS X like Expose that shows a preview of all tabs for a window. That would help me find a tab visually.

- A command to override the meaning of fullscreen to take over the whole tab, rather than be truly fullscreen. That would let me use other window management features with maximum video size within the window.

Our decorators aren't required - you can use the static properties block. If you think the DX is better with decorators... that's why we support them!

And we support TypeScript's "experimental" decorators and standard TC39 decorators, which are supported in TypeScript, Babel, esbuild, and recently SWC and probably more.

Regarding state: Lit makes it easier to write web components. How you architect those web components and where they store their state is up to you. You can stick to attributes and DOM if that's what you want. Some component sets out there make heavy use of data-only elements: something of a DSL in the DOM, like XML.

It just turns out that most developer and most apps have an easier time of presenting state in JS, since JS has much richer facilities for that.

That's an ok choice in some cases, but the web clearly moved on from that to be able to have richer interaction, and in a lot of cases, much easier development.

Even so, Lit is widely used to build very complex apps (Beaker, as you know, Photoshop, Reddit, Home Assistant, Microsoft App Store, SpaceX things, ...).

Property bindings are just as ergonomic as attributes with the .foo= syntax, and tag name declaration has rarely come up as a big friction point, especially with the declarative @customElement() decorator. The rest is indeed like a faster less proprietary React in many ways.

So I've been thinking of updating my site and habits to center around running my own ATProto PDS and publishing my blog posts there, with my blog just being my web front end to my PDS. Then I could use that same PDS for Bluesky, photos, etc. and self-host a wide variety of things with an interoperable social layer.