text editing is hard

 79: Text editing with Michael … - Complementary - Apple Podcasts

Heh. Katie Langerman is a designer I worked with at CarGurus, and she's been working at GitHub, and she cohosts a design podcast... it was a little triggering - relivingsome things we're struggling with at my current job -  but they had a whole episode on "text editing". ProseMirror comes up a lot. And the issue of rich text editing are thorny for everyone. (Like if the user copies and pastes from inside a bullet item list, maybe not respecting item boundaries... what all should that even look like on paste, in terms of what structure should it assume or replace or ignore... )

AI doesn't replace best practices

 At work in our AI discussion forum someone posted this video:

https://www.youtube.com/watch?v=v4F1gFy-hqg

One thing I'm wrestling with is... how do devs/LLM-wranglers ensure we get good "value for money" in terms of the pre-prompting stuff? To a large extent, decent coding practices are built into LLM. (Admittedly, the LLMs have been more trained on toy example which might cause them to be more likely to take shortcuts.) So in theory, it might not make sense to stuff your context window with things the LLM already knows deeply. (Or maybe this is a false economy, and that the number of tokens spent compared to what can be saved is small... this is why non-deterministic programming might always have an aspect "as much an art as a science.")
 
Another topic I want to refine my thinking on is testing. The TDD (Test Driven Development) mindset makes a case for itself more strongly in this LLM world in versus what we had before - in part because of the "pain in the butt factor" of it all. In UI at least, most medium to low level tests depend on content pieces (page structure, test-ids) that aren't in place UNTIL implementation - real chicken and egg stuff, where you would have to architect fine grained structure while writing the test, which isn't really a comfortable way to work. But with an AI, that discomfort might not exist (or at least not felt by humans)
 
Finally I wonder about the "software fundamental" of unit test. Like, I LOVE that this video suggests "grey box" modularization - limiting coupling to specific points between higher level modules. To me that points to where the real value in testing is, at integration of those modules, and end to end testing. In the old world, it was difficult to get real value from unit tests, tests that were real canaries in the coal mine vs false alarms, so I was always in the camp that preferred higher level tests.
But I'm not quite sure what the answer is for the LLM world. Anecdotes suggest that sometimes LLM care about tests too much, will keep code around just because there's a test for it after a refactoring. I appreciate that at the very least LLMs have helped lower the cost of unit test creation.

React tab-based component reuse as an anti-pattern

TLDR: If you have a React form where the same set of components shows up but with different content based on "tabs" or some other selector, consider keeping a 1:1 mapping between the component and its state and hiding the inactive tabs visually, rather than depending on rendering.

React-based design systems always have a weird decision to make about controlled components (where a component's value is constantly being updated by the parent as the component notifies the parent of key press and other events) vs uncontrolled (where the component handles its own affairs, but still has to notify the parent on each change)

My opinion of React slipped a little when I realized that the functioning of a normal controlled input box or textarea utterly depended on a rendering optimization - in the simple declarative UI model, when a user types a character into an input, React rerenders the input with the new value. But of course, if (and sadly, when) React actually rerenders the input, transient state like "cursor position" is reset, since that's not part of the state the parent is managing. So normal UI features like "entering text anywhere but the very end of the current content" depends on React being smart enough to know it doesn't REALLY need to rerender that input box. 

But uncontrolled components have always been weird as well... mostly because of the legacy of html5 syntax. If you just put in the value prop with no handler, the control would be locked to that value, so design systems like Material UI lean on "defaultValue=" for uncontrolled components.

(There's a third path that is sadly underused, IMO: you don't need any handlers whatsoever for basic form components if you wrap them in a <form> tag

 const handleSubmit = (event) => {

    event.preventDefault();

    const formData = new FormData(event.currentTarget);

    const username = formData.get('username');

    // or onvert all data into a standard JavaScript object

    const allData = Object.fromEntries(formData.entries());

   };

That gets a little messier in a TypeScript world, but I think the fixes for that still beat all those handlers... let html5 and the browser do what they were design to do! And of course there are other solutions to this problem like formik)

Anyway!

At work we have a component wrapping Kendo React Richtext Editor, and the company's legacy wrapper for it is in some need of refactoring. The editor is uncontrolled, its keeping a copy of its own state, and sometimes there's drift with what the parent thinks is being displayed and what's actually being shown to the user.

That kind of problem became especially acute on a few pages that used a tab component to display the same form, but with a different set of values based on the current tab selection. If you entered data in a field, swapped tabs, then went back, often that original data would be not show properly (like maybe the parent would be aware of the updated values, but on rerender, the KendoEdit would revert back to the original values it was set with.)

These problems would go away if our tab implementation kept a separate set of form elements in the DOM, and just hid all of those for the inactive tabs, and I'm going to pitch that as a future refactoring... In this world of uncontrolled components, not having a 1:1 mapping to something in memory is a whole armory's worth of foot guns.

(It's probably temping to reuse components with something like
<input value={mainData[currentTab].content}>
since it feels more "efficient" somehow, like costly to have components in the DOM but not shown... but the more I think about it, visual hiding and 1:1 mapping of component and state seems like the safer bet)

the mythos mythos

 Following up on the "Mythos Tracking" -- 

I know there's some sentiment that like, announcing "maybe THIS level of our exclusive new AI is just TOO POWERFUL for the world" is kind of an old ploy already - and as Fireship (one of the more enjoyable ways of absorbing tech news) points out, some of the metrics and test cases... even if Mythos is quantitatively better it's not clear how big of a qualitative change it is.

But, this paper has a lot of big names attached - The “AI Vulnerability Storm”: Building a “Mythosready” Security Program - and it does make the case for how the security landscape is changing.

js 2026

Even if you're all hot and bothered to hop onto the "vibe coding maestro" train, it's good to have some idea of what's going on in Javascript in 2026.

I wonder if browsers will ever start doing Typescript natively. There's such a beauty in buildless systems, and browsers have been so good at backwards compatibility and keeping things evergreen.

rise of the gray hat bots

Ah my goodness. News of Anthropic's "Mythos" is making the rounds, finding crazy security exploits - and honestly seeming to pick some of the playful jocularity of a troll hacker. 

I guess we don't realize how much of LLM's helpfulness and good spirit comes from being trained on online technical resources with that point of view - maybe in a more-than-poetic way, LLM reflects the community spirit of OSS. But if you change that vibe at a fundamental level - you have a formidable tool. And maybe the best we can do is make sure our "gray hot" bots help us shore up our defenses before the black hats get a hold of it.  

will Web 4.0 be more like Web 1.0

Interesting article about how (especially agentic) AI Might Be Our Best Shot At Taking Back The Open Web.

There's a straight shot for me from "slapping up webpages via my university ~/public_html directory" to "put up CGI on cheap shared webservers" to "running whatever I want on a rented VPS". Actually I still think buildless/evergreen on my VPS is my secret sauce, where I'm able to put up a new service or webapp without putting down a credit card of starting a new business relationship, and AI (agentic and chatbot) plays REALLY well with that. Sky's the limit and with my Porchfest sites I've seen how simple, almost under-engineered things can scale to accommodate even super-spiky traffic days. (Which makes my disenchantment with how complexity has grown in the Enterprise even stronger.)

So my question is, what would the Geocities of this current era be? Obviously it's much much more fraught to offer space where web apps can run, but still, while I get how empowering agentic can be for people who can clearly describe what they want but have never learned to put that in deterministic coding, WHERE they put things (besides running it locally, or maybe using some cheap freebie hosting) seems like an interesting question.