What if the reason dynamic languages are so suitable (even necessary) for component composition / scripting is not because we actually need dynamism for that.
But because dynamism lets us work around the fact that our model(s) for composition are wrong.
On my blog: “And it seems retro in the worst way that we’re still using anything other than a scripting language for most of our code. We should be using something simple and light that can configure toolbars, handle networking callbacks, query databases, manage views, and so on.”
I am starting to see the need for a stdout that always appends a newline at the end, so println: but on the object side.
What should this be called?
Just benchmarked my PWS variant of the channel-sieve against Go’s CSP-based one.
As suspected, mine is 3-4 times faster and uses 20-30 less CPU.
Even with Go’s highly optimized goroutines + IPC channels, the multiprocessing overhead is just too high.
My “HTMX-Native” shim for connecting HTMX directly to an Objective-S store in-process now works on macOS, iOS and Android.
I love it when a plan comes together.
It looks like I won't have to patch htmx.js after all in order to get PUT/POST/DELETE to work with local WebViews. JavaScript is really very, very monkey-patchable.
It's really weird that local WebViews are so limited. On Android, nothing with a body at all. On macOS/iOS, only POST gets a body, PUT does not.
So now I have my own channel.