spankalee

The J6 insurrectionists committed real crimes, and it's very good that they were rounded up, but afaiu most of the evidence had to do with them provably assaulting officers, damaging property, and breaking into a government building. Not that they messaged other people when they were legally demonstrating before the Capital invasion.

The real protection for the legal protesters and observers in MN is numbers. They can't arrest and control and entire populace.

I think if you're going to argue that we shouldn't have contemporary immigration because of the harm to native Americans, then you should show what harm is caused _now_, that native Americans actually oppose immigration, and probably that you support other ways of helping them like giving them land back.

American is built on immigration, and nearly all of us are immigrants or very recent descendants of immigrants. How in the world has immigration harmed Americans?

Yes - very, very dumb people did vote for him.

If they could arrest people for what they've been doing, they would have already arrested people. And they have arrested a few here and there for "assault" (things like daring to react when being shoved by an annoyed officer), but the thing that's really pissing DHS off is that the protesters and observers are not breaking the law.

I was replying specifically to this:

> This seems like a good example of that being enough metadata to be a big problem

I was not saying it's not a problem that the feds are doing this, because that's not what I was replying to.

I don't think it's much of a problem at all. Many of the protesters and observers are not hiding their identities, so finding their phone number isn't a problem. Even with content, coordinating legal activities isn't a problem either.

I think this view is really short-sighted. Low-code tools date back to the '80s, and the more likely outcome here is that low-code and agentic tools simply merge.

There's a lot of value in having direct manipulation and visual introspection of UIs, data, and logic. Those things allow less technical people to understand what the agents are creating, and ask for help with more specific areas.

The difficulty in the past has been 1) the amount of work it takes to build good direct manipulation tools - the level of detail you need to get to is overwhelming for most teams attempting it - but LLMs themselves make this a lot easier to build, and 2) what to do when users hit the inevitable gaps in your visual system. Now LLMs fill these gaps pretty spectacularly.

Enabling the `integrity ` attribute on iframes would help: https://github.com/w3c/webappsec-subresource-integrity/issue...

But then you'd also want the frame content to use `integrity` on nested resoures.

CSP frame-src can help for now.

This is what Trump's dismantling of US power has brought us to. Our soon-to-be-former allies can't count on US nuclear deterrence to protect them, because not only is the US unreliable, but they might be the ones attacking.

We're in crazy-town because of Trump and the Republicans, with very real consequences.

Are you actually claiming the US is not criticized here?

Are you actually defending the censorship of Tiananmen Square?

Yes, afaiu at least, effects and resumable exceptions are nearly the same, and you can implement one with the other.

I'm targeting only WASM at the moment. I wish I could get into Haskell, but I just can't read it. I really can't parse what's going on with types like `Result e t (Either e t)`.

That Midori article looks great, I'll give that a closer read. I actually used to work with Bob, and am familiar with the (wonderful!) function color article.

I think my biggest question might be addressed in the Midori article: with things like bounds checks and checked casts you already have exceptions (or panics), so should you have a way to capture them anywhere on the stack? Are they recoverable in some programs? So should you have try/catch even if you try to make most errors return values?

Another set of questions I have is around reified stacks. Once you have features like generators and async functions, and can switch stacks around, you're most of the way to resumable exceptions. I don't yet fully grok how code as the resume site is supposed to deal with a resume, but maybe resumable exceptions are a reason to keep them.

Does anyone know of a great write up on exceptions vs union or either typed returns?

I'm building a new language, somewhat similar to TypeScript in some ways, and so far I have exceptions and try/catch expressions, but also Optional<T> and Result<T, E> types.

I'm familiar and used to exceptions, so I included them so at least near-fatal errors (ie, actually exceptional) could be caught at high levels in the stack. But I'm unsure if there's a strong argument that resonates with me yet that the language shouldn't have exceptions at all. Arguments that exceptions are untyped can be solved with things like checked exceptions, and I do find Go-style code to be quite verbose.

What's the best current reading on this?

AssemblyScript ships its own garbage collector and doesn't seem to making progress on supporting WASM GC.

I'm working on a TypeScript/Swift/Dart style language, and currently this hello-world is 1444 bytes:

    export let main = () => {
      console.log("Hello, World!");
    };

I'm trying to make that smaller. The binary includes the Console class, which is needed (I may be able to tree-shake the non log() methods away), but also the Error and IndexOutOfBoundsError classes which aren't needed because there are no catch() expressions.

I think it really helps to have a language designed from the ground-up to obsess over bytes for WASM. Trying to do that with a familiar high-level language with a rich standard library is tricky.

I'm working on something like this right now, targeting WASM GC. I started with functions, basic numeric types, arrays, and structs. Then added blocks, control flow, and strings. Then interfaces, mixins, classes, and extension classes. It's now something like a statically typed mashup of TypeScript, Swift, and Dart, all done in the best way I could figure out specifically for WASM GC.

It's been a really fun side project.

I do think there is a market for something like this - optimizing an existing language for WASM, or ephemeral networked code delivery in general, can be really hard. And a statically typed, WASM-oriented, very familiar high-level language, that can give very good static errors, and quickly run in a secure sandbox might be a good target for LLM-generated code.

Why should taxes "end"?

You still get minimal DOM updates crossing shadow boundaries. This is true fact.

React's vdom without shadow DOM passes props to components, which all return one big vdom tree, and then there's one big reconciliation. React used with shadow DOM evaluates smaller vdom trees per shadow root, and does more, but smaller reconciliations. It's the same O(n) work.

But in reality it's often much _better_ with shadow roots because the common WC base classes like Lit's ReactiveElement all do change detection on a per-property basis. So you only regenerate vdom trees for components with changed props, and with slots that doesn't include children. So if children of a component change, but props don't, the component doesn't need to re-render. You can do something similar by hand with memo, but that doesn't handle children separately. The compiler will, of course, fix everything.

Every other reactivity system works fine across shadow boundaries. Even the super-fine grained ones like Solid. The only issue with signals-based libraries like Solid is that they pass signals around instead of values, so to get true no-re-rendering behavior with web components you have to do that to, which means picking a signals library, which means less interoperability. The TC39 signals proposal points to a future where you can do that interoperably too.

> There is no DOM primitive that allows for interoperable composition with fine-grained reactivity. Your framework offers fine-grained reactivity (Virtual DOM for React/Preact, signals for Angular, runes for Svelte, etc.) and any component that contains another component has to coordinate with it.

This just isn't true - composition and reactivity are completely orthogonal concerns.

Any reactivity system can manage DOM outside of the component, including nodes that are projected into slots. The component's internal DOM is managed by the component using whatever reactivity system it desires.

There are major applications built this way. They make have a React outer shell using vdom and Lit custom elements using lit-html for their shadow contents.

On top of those basics you can also have cross-shadow interoperable fine-grained reactivity with primitives like signals. You can pass signals around, down the tree, across subtrees, and have different reactivity systems use those signals to update the DOM.

There's really no way to decouple slots for shadow roots.

For slots to work you need a container for the slots that the slotted elements do not belong to, and whose slots are separated from other slot containers. Otherwise you can't make an unambiguous relationship between element and slot. This is why a shadow root is a separate tree.

That's styling itself sure, but it's not self-evidently self-contained. Does every component emit those styles? Are they in the page stylesheet? How do they get loaded?

Counterpoint: Shadow DOM is great. People should be using it more. It's the only DOM primitive that allows for interoperable composition. Without it you're at the mercy of frameworks for being able to compose container components out of internal structure and external children.

I'm a big web components guy, but calling these web components is a massive stretch of the word component.

The word "component" has to mean something ultimately, and to me the defining feature of a web component is that it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS, etc. Web components shouldn't require an external framework or external CSS (except for customization by the user) - those things should be implementation details depended on directly by the component.

This here is just CSS using tag names for selectors. The element is doing nothing on its own.

Which is fine! It's just not web components.

edit: Also, don't do this:

    <link-button>
      <a href="">Learn more</a>
    </link-button>

That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. Too many HTML elements can slow the page to a crawl.

Use classes:

    <a class="button" href="">Learn more</a>

They're meant for this, lighter weight, and highly optimized.

A gen AI tool doesn't spontaneously open up and say "Hey, Maccabi Tel Aviv fans are hooligans". The intent is usually from the user. It's quite possible that the officer prompted the AI while in Word with something like "Help me write a reason we should ban these fans".

What?

Your other posts have capital letters for technical abbreviations and "Sparkfun", but not for "I" and the first letter of sentences.

Sorry, from a bystander this looks like a straight-up lie, and why lie about such a small thing? It brings into question the truth of your other statements. Just say you like the style if that's the truth.

> FDA banned any flavored cartridges, which doesn't include disposables

Wait, what? Where's the sense in that?

Wait, so you would personally say things like "Black people are a hate group", except that you need to stay employed?

That is exactly what I mean about making bigotry shameful again. You should worry about losing your job, and your friends and family, for that.

If you stay quiet about your hateful views, then others are more likely too, and maybe some day we can eventually, slowly, move past all of you.

Tangential, but: MainStage the best deal in the entire pro audio industry.

As a keyboard player who mainly plays (and owns) classic electro-mechanical keyboards like Hammonds, Rhodes, Clavinets, and Wurlitzers, Apple's emulators that they brought from Logic are really top-notch - often better than what you get with dedicated hardware.

$30 is an insane price for what it delivers. I just wish it were available for iPad, and I'd use it more for gigging.