Good morning my beautifuls.
Yesterday, as I was building out the Busy React client, I realized two critical flaws in my approach.
The wrong framework
1. React is all magic, which is entirely against my coding religion. This is a lesson I learned the hard way 18 years ago. Magic is ALWAYS bad. Being clever is being dangerous, and I won't do it. If code can't be read and simply understood for what it is, at a glance, without a manual, that code is not written correctly. There is a clear binary right and wrong here, there has to be.
So React is the wrong tool for the job.
Also, I like modern JavaScript, a lot. And I don't think I need a standardized JS framework when my development tool (the one I'm using to build this) is trained on the history of human coding practice.
Let the plugin system assemble the UI
2. I spent a week building out this really elegant plugin system. It's perfect. Cognitively light, straightforward, intuitive. Small, well-contained, decoupled plugins that clearly separate concerns, demonstrate consistent design and implementation principles, that extend and rework each other, and seamlessly integrate into a core system that consists of ten files that never change.
When you see how smoothly this works, and how easy it is to manage and understand, your jaw is going to drop. The beauty and simplicity of the thing is incredible.
So why am I trying to write a single monolithic UI that incorporates all of it without talking to the plugin architecture itself?
Well, that's a stupid design mistake.
Clearly.
Realizing this, I extended the plugin system to handle the UI in the core, doing the UI assembly with the same practices that govern the rest of the system.
Now, when Busy builds, it assembles the core UI structure from the core system, and modules have UIs with UI manifests that explain to the core system where they're placed, and how they're set up.
Concerns are managed a little more effectively, and it allows for differences in module organization, should anyone want to write modules for it in the future.
Think of modules like the arms, legs, and laptops, that we're giving to these LLM agents that allow them to affect things in the real world.
Follow the data through the application
Also, no more stupid unit tests.
Why does my brain keep insisting that we need unit tests? Lol
Unit tests lock down architecture, and slow down the rate of development, without actually demonstrating that your code works. Your code could be structurally correct and broken at the same time. Unit tests are untrustworthy, because they can be set to always pass by unscrupulous developers, and they don't solve the problem you're trying to solve by using them.
So this too is the wrong approach.
Instead, I'm codifying using flow tests and doing integration testing as part of my process. Follow the data in specific pieces of the application as I want to test it. Run it through scenarios that I know we've coded for, and watch the data go in, get processed, and come out on the other side. Duh.
It's been working well for me so far, but I might need to revisit my testing strategy in the future.
This is an ongoing experiment.
More soon.