And why they outlast all other manufacturers and have fewer issues in general. In my experience, Apple products are often actually cheaper when amortized over their lifespan.
Or just skip/migrate off of the Next.js and other JS SSR rats nets to Elixir and Phoenix LiveView - Claude and Codex are both very good with Elixir now: https://elixirisallyouneed.dev
I see this sort of maximalism a lot where people are just turned off js and say f it I'll use HTMX or LiveView or Alpine or whatever promises that you won't have to write js, and that's fine; as long as you're building generic dashboards and/or the same repetitive UI patterns. And even then you're basically writing JS just in a worse way.
I use Liveview and Elixir for 2-3 home-lab related frontend services; but when I have to do something moderately complicated I have to reach out for a darn js library and hooks and phx-commands. Try using native drag and drop or even client-side markdown rendering. This also leads to memory leaks when you can't properly detach libraries.
I just say think about your goals; these frameworks/platforms that promise to remove JS from your life or minimize it do so by sacrificing something. There's no silver bullet for building on the web.
But whenever I do talk to people who are debating amongst frameworks SvelteKit and SolidStart are the two I recommend, it's easy to host anywhere (unlike Next), you can turn off SSR, just ship static files with very minor changes (exporting a variable in Svelte for ex). They're really quick, get the job done, actively being worked on, loads of resources, discussions and thriving communities.
We'd just be overloading "lessons" as well, and even more so because it takes more work to ground the concept, given its larger semantic distance from what we're describing.
What nonsense. The "rest of the world" understands the message loud and clear: China shows up to do business. America shows up to bomb. It's a pretty reasonable choice. Anyways, people now ant a BYD, not a Chevy - because its a better car.
Very nice, Oban is great. I effectually found a similar approach with pgflow.dev (built around pgmq) - but the stateless deno "workers" are pretty unreliable and built an elixir worker (https://github.com/agoodway/pgflow) that can pick up and process jobs that were created by pgflow's supabase/typescript client. So maybe there's an opportunity also with Oban to have a TypeScript/Node client that can insert jobs that Elixir/Python Oban can pick up. Also, I wonder if another approach vs the python workers picking things up is to have elixir workers call/run python/lua, etc code or is that too limiting?
I'm happy other people are thinking about this. One of the big stories over the fast years that few know about is a number of the French colonies kicking off the shackles. Can they make it on their own or with their new Chinese and Russian "friends"? Guess we'll see.
This platform is 90% just comfortable shitlibs living in the imperial core, so can't expect much. I think BRICS is the best thing that ever happened to the global south, if only to provide a counterbalance to the western 'empire of chaos'. As a Kenyan official put it: "Every time China visits we get a hospital, every time Britain visits we get a lecture."
Interesting to hear you say that, I was thinking (but hadn't said) that using WalEx to dispatch to some workers where the agent lived would be a better solution. The worker would then update the row (or more likely insert a new one in a different table with more constraints/different columns). I would be curious to hear what advantage you see in a `claw` type/`agent` column? I can't make heads or tails of it but I regard you as knowing a lot more about Postgres than me.
reply