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. 

Thoughts on the first section of Yegge's "Vibe Coding"

I'm reading Gene Kim and Steve Yegge's book "Vibe Coding":

When we say vibe coding, we mean that you have AI write your code—you’re no longer typing in code by hand (like a photographer going into a darkroom to manually develop their film). Although the most visible and glamorous part is code generation, AI helps with the whole software life cycle. AI becomes your partner in brainstorming architecture, researching solutions, implementing features, crafting tests, and hardening security. Vibe coding happens whenever you’re directing rather than typing, allowing AI to shoulder the implementation while you focus on vision and verification.

I've "vibe-coded" a few medium-small things, but they were enough to impress friends who were techie but not in the loop.

Still I am more or less persuaded that the future of dev will likely be Yegge's kitchen model: 

You’re the head (or executive) chef of the kitchen, and AI represents the army of chefs who help bring your vision to life. AI serves as your sous chef (your second in command) who understands your intentions, handles intricate preparations, and executes complex techniques with precision under your guidance. But AI is also your army of station chefs and cooks, specialists who help handle various technical details.

But it's not clear to me how individual devs should ramp up to that style of production if their current day job isn't there yet. 

So some thoughts after reading the first section of the book:

• The book spends a page talking about how complex web app construction has gotten, and how many things enterprise developers need to know - "package managers (npm, Yarn), bundlers (webpack, Rollup), transpilers (Babel), task runners (gulp, Grunt), testing frameworks, CSS preprocessors, build toolchains, deployment pipelines" and then says "Because of the DevOps philosophy of 'you build it, you run it,' you also need to learn Docker, Kubernetes, AWS, and infrastructure-as-code tools like Terraform, not to mention a whole host of AWS, GCP, or Azure services." That's definitely been true for my professional life, but I'm still shocked at how little of that I need for my side projects (and I laugh at how "Server Side Rendering" was the new hotness a few years ago, when older, simpler stacks never left that.) So when I try and get into a fuller vibe coding model, I have to decide if my monolithic, buildless, evergreen stack is still the best bet (and frankly AI understands it really well) or if I should use it as an excuse to add some buzzword bingo to my resume.
• As a side note, it's still startling how bad LLMs can be if they don't have access to the right subtools. I was feeling lazy (or experimental, at least) and asked both Claude and ChatGPT to do a simple "here's a big hero splash image for a porchfest site with an embedded date, please keep the image the same but update the date" task. ChatGPT choked on it, Claude got it in at a barely acceptable level, and I realized I should have just sucked it up and done it by hand. 
• There's such a cyberpunk feel to this moment, or at least the near future. A little hard to explain if you're not familiar with the genre, but like the decision to use a "corpo" LLM vs maybe a grungy LLM you have on your own hardware... or just everyone running around with their own bespoke software. It smells like mirrorshades.
• The book has a chapter of cautionary tales, examples of LLM going way off the rails, sometimes causing damage. I ran into one of those cases of LLM shortcutting when I vibecoded a CSV to address label PDF app - Claude was all too happy to keep using hardcoded test data for the actual print pages even after I had had it switch to live data for the setup and config pages. (I only had one set of data I cared about to test, so it took me a bit to notice)
• One thing the book is a little light on discussing frankly is costs. This stuff threatens to create a real divide between the have and the have nots. I have a couple buddies (both formerly involved in guitar bands, interestingly) where tech was the path out of poverty. It seems like that could be harder if the people who can afford $20-$200/month in AI helpers are the only ones who really learn to leverage helpers at scale.
• And of course there's the other lingering fear for developers... we have to hope that the people we report to now, the PMs and POs, don't find out we're not necessary - that running AI at scale will be enough of a skill that we still have value to add. 
• There can be such a religious fevor to both the AI-believers and the AI-rejectors. A while back I grabbed this passage from Jim Holt's "When Einstein Walked with Gödel": "[Richard Rorty] also liked to cite Nietzsche’s observation that truth is a surrogate for God. Asking of someone, “Does he love the truth?” Rorty said, is like asking, “Is he saved?”" 

At any rate, I know I do need to professionalize my side project world at least a bit - when you're dealing with a hoard of junior programmers you don't quite trust, testing, first rate source control, and deployment strategies can be more important than ever...

measuring code quality in an agentic world

My buddy Scott at Red Hat shared https://redmonk.com/sogrady/2026/02/10/besieged/ in the group chat.

It's a worthwhile summary of this point in development history.

Earlier I was appreciating the zeitgeist that maybe we were near the top of the S-shaped curve of what LLM could do, things might be settling down a bit. But recently I've been catching a different spin, that specifically the model releases last November really pointed to a new level of capability - something beyond the intuitions programmers experimenting with LLM the years before would have developed.  (The future might be the dev as head chef, with a bot sous chef bossing around a small hoard of underling agents.)

Scott mentioned Red Hat is pivoting to agentic workflow: "One interesting thing our CTO said was, we will not measure AI consumption, we will measure code coverage, quality, etc. Focus on outcomes."

Now, casting a blind eye to consumption reminds me of a tale from AOL/Millennial Media, when they thought pivoting to the cloud/AWS was giving them a bunch of dev and qa servers "too cheap to meter" - an expensive lesson they had to correct course around. And of course, there's the environmental impact (energy and water consumption - not to mention the "environment" of the crazy costs of GPUs and memory). And for all the democratization of code LLM offers, the idea that you must shell out month after month on a service (or buy some ridiculously priced hardware) in order to be competitive threatens to undermine the self-starting developer paradigm that got its start when home computers became cheap in the 80s.

But as I try to figure out how I can maintain my role as mediator between Business Folk and Machines I want to think about the second part of Scott's paraphrase, "code coverage, quality, etc"

Too often (in my heretical, anti-reductionist opinion) organizations go to quantify code coverage via unit tests percent coverage. But AI is going to require a new sense of what "quality" is:

* ability for future gens of your AI hoards to pick things up and iterate on earlier work

* consistent behaviors (externally testable)

* human-friendly UX (when applicable)

* edge cases covered

* one layer of AI check looking for weirdass shortcuts AI may have taken

* security, security, security

All of these have parallels in what traditional software development has to be keeping an eye on, but with humans being not as deeply embedded in the core loops, we will need more a more sophisticated way of quantifying how well things are going.