compacct27

Groups were my gateway drug into abstract algebra. A friend clued me into symmetry being everywhere and Groups are how symmetry is formalized, and it’s been a crazy journey understanding all that. The frontier models can tie those abstract concepts to plain English examples and answer questions decently well, it’s never been a better time to pick up the field solo and see what it has to offer us

It’s surprising how bad the API is. Shadow DOM makes just about everything worse. Our frontend org opted out of even using Lit, so we get the raw stupidity of the whole idea.

Style encapsulation? You get that, but not fully, and good luck finding out which parts you don’t get.

State management? Back to query selectors, which btw work worse and need workarounds when reaching into the shadows. We went with DOM-as-state. I don’t want to talk about it.

Slots? After coming from a modern framework, slots are a clear step backwards. In React you can pass a component as a prop but in the shadow DOM world, you have to signify it with HTML. Multiply it by several slots and you get a lot of verbosity just to match the behavior.

Yet to mention using the platform directly means losing so much work around static verifiability. No one has to talk about this anymore, but sticking religiously to the platform by strictly using addEventListener means you can’t require event handlers to exist for any of your elements. People forget this, but the browser’s default way of letting you do anything is an enormous footgun for reliability.

Learn from our frontend org’s mistakes. Run, don’t walk, away from it.

A MUD got me into programming, just wanted to make one myself. I was too young then. Now that I’m “grown”, every five years I feel like the kids these days have so many tools to make it easier or at least more knowable.

Also, that ASCII art(or pixel art?) as the header looks serene. Any tips/rabbit holes on achieving that art style?

The issues were more behavioral for us. You can build the web component however you want, and the venn diagram of acceptable WC behavior vs React isn’t a full circle at all. Changing elements directly will mess up any VDOM-based approach, resetting state because rerendering means having a brand new WC, creating custom events in an esoteric way, it was a minefield of incompatibility beyond just “React can work with web components”

For web components to be consumable across frameworks, you still have to write it to be compatible for different frameworks. Our platform team thought they could get away with just focusing on native js, but when it came time to use in React, many behavioral approaches were incompatible. Dealing with re-renders would clear the state of the WC, losing all dropdown items. The toggle button had an infinite re-render glitch when combined with setState. We lost the ability to require event handlers, and prod had a few P0’s over unhandled click events.

The ideal was to be close to the browser, but it’s mostly blown up in our face. The approach in this post would’ve been helpful, and it’s almost worth the cross-framework compatibility, but I just wish the entire web components standard didn’t come with an unbelievable amount of these and other problems

This really gets at the issue with JavaScript in the age of AI: it’s just not a terribly statically verifiable language, and DOM work is incredibly prone to failing silently while the app itself is clearly not working. We’ve had to paper over it with TypeScript and frameworks that impose constraints just to stop several classes of bugs, and even then it doesn’t go terribly well.

The flip side is that AI is making the underlying code more like a..compilation target? At least in the sense that, yes, as this site mentions, Scheme is ugly to read and would be hell to write the old way, but with the new way..maybe we can try because it would give us what native JavaScript and the latest browser standards never could: reliability

This isn't it. After spending my morning on a code review and catching several major issues despite it being a +7kloc diff, the real question is--how do we make the tooling around code reviews better? Intentions aren't enough, they're vague and the implementation details matter. They help, though, and this is closer to the answer to code reviews: check out the intentions, get an AI-assisted overview of the architecture of the code, then dive into the more important parts of the architecture.

Maybe it's because I'm in UI dev, but intentions aren't enough at all

They have web components if you want

“Build our platform for us!”

Or less!

Integrating these web components into our React codebase has been pretty awful--more of a web components thing than a Lit thing, IMO. We have "scoped styles", except for certain important things like font sizes, so tons of little regressions everywhere when we swap in the web component in place of the old React one. DX-wise, we lost a lot, too. I assume the tooling will get better, or that we'll figure it out more, but it's mostly been a drag

Another part of what happened is that the comment section feels more succinct and insightful than the actual article. Articles have to be long form, comments get to the point. It's sort of like your comment is the LLM response I wanted all along. And now we can personalize our reading and have a more meaningful outcome.

Maybe long form content solved a need back in the day when things were printed on paper and figured out well in advance, crossing their fingers on the relevance, and with where we are now we can suss it out without all the reading-as-middleman-to-knowledge

The leverage has been flipped. We all had awful college classes teaching next to nothing, and now that you can get good grades without attending, what's left? "We lost critical thinking!" No, we were barely getting that in the first place. Now, classes need to be more valuable.

Oh my god, love these visuals. Geo data is so perfect for dataviz

Honestly it's already working great in Cursor. Even adapting one type structure to another is quickly handled.