podman-compose is "mostly" compatible. I "plain" podman at work, but there we just have a bunch of shell scripts that spin up/down/build containers. For regular dev work, it's fine.
For personal stuff, I've been experimenting with podman's Kubernetes files: https://docs.podman.io/en/latest/markdown/podman-kube.1.html. Which, IMO, "feel" like docker-compose the most. You can run services via "podman kube play ..." and install them via quadlet install too.
podman-compose has gotten much better. I used it for a work project a few months ago, and it ran fine. That said, I know there are some random little things podman-compose doesn't support, so be careful.
It's slightly more verbose than docker-compose, but podman supports it natively and you can actually wrap your app containers into a single "pod" for easier management.
Interesting that ports can be written so quickly with AI. But that aside, I have to ask...why? You want a super performant bundler/runtime/package manager written in rust with TS support, Deno has this already.
I lean towards vanilla javascript and webcomponents myself, and eschew large frameworks in favor of lighter, or in some cases, no framework at all.
That said, this and many other webcomponent articles mischaracterize usage cases of webcomponents:
1. Being "Framework-free"
Frameworks can mean anything from something massive like NextJS, all the way to something very lightweight like enhance.dev or something more UI-focused like shoelace. To suggest being completely free of any kind of framework might give some benefits, depending on what kind of framework you're free of. But there's still some main benefits of frameworks, such as enforcing consistent conventions and patterns across a codebase. To be fair, the article does mention frameworks have a place further down the article, and gets close to articulating one of the main benefits of frameworks:
"If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction."
In a team, any pattern is better than no pattern. Frameworks are a great way of enforcing a pattern. An absence of a pattern with or without webcomponents will create friction, or just general spaghetti code.
2. Webcomponents and the shadow DOM go together
For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM. While the idea of encapsulating styles sounds safer, it does mean parts of your page render after your main page, which can lead to DOM elements "flashing" unstyled content. To me, this janky UX negates any benefit of being able to encapsulate styles. Besides, if you're at a point where styles are leaking onto eachother, your project has other issues to solve. The Shadow DOM does have its use, but IMO it's overstated:
Neat, and neat to see the burn framework getting used. I tried this on latest Chromium, but my system froze until my OS killed Chromium. My VPN connection died right after downloading the model too. (it doesn't have a bandwidth cap either, so I'm not sure what's happening)
Yeah that'd be really something. If you could just pay the cost up-front, rather than worry about how much every newer request cost, that really changes the game. There's still many other issues to worry about, like security. But as the author points out, we might be much closer than we think.
Artifactory works fairly well. Although admittedly, when a user grabs a new dependency, they're downloading from the npmjs registry like anyone else.
Really, the killer combo would be to have some kind of LLM-based tool that would scan someone's artifactory. Something smart enough to notice that code changed, and there's code for accessing a crypto-wallet, etc. This would be too expensive for npmjs to host for free, but I could see this happen to hosted artifactory dependencies.