This seems wildly subjective. Can you give some examples of how Omarchy is worse?
I find using macOS to be generally frustrating and cumbersome to use and I'm regularly confused when people say it's unequivocally the better choice for all things.
1,307 karma · joined December 14, 2022
This seems wildly subjective. Can you give some examples of how Omarchy is worse?
I find using macOS to be generally frustrating and cumbersome to use and I'm regularly confused when people say it's unequivocally the better choice for all things.
I tell Claude to use the existing tmux CLI to send-keys, capture-pane, etc. and it works flawlessly. Literally just "never use the Bash tool, run all commands in tmux sessions" and it knows what to do from there.
Use JS to patch over things the browser doesn't implement and let it handle the rest.
JS is fine to use too as needed. Generally, it's not needed. Small snippets to pop open modals or flyouts of whatever covers a huge number of use cases.
This implies or assumes that sending the template again is a problem. In practice, it's not. HTML compresses well and the difference between the compressed JSON and HTML response is often on the order of hundreds of bytes. That assumes equivalent data content which, as I've said above, is often not the case. JSON payloads tend to be larger and we need more of them to render the same UI.
Your comment then falls under my "superstition" label.
My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything.
You should always run benchmarks for your use case but the majority of web projects are not Figma or AutoCAD and benefit drastically from simpler approaches. A single compressed HTML response will beat a cascade of JSON ones every time.
I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire.
Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses somehow better than HTML because HTML compresses incredibly well.
Most arguments about network concerns making SPAs a better choice are either propaganda or superstition that doesn't pan out in practice.
Does having access to Chromium internals give you any super powers over connecting over the Chrome Devtools Protocol?
I do my best to run as little in the browser as possible. Everything is an order of magnitude simpler and faster to build if you do the bulk of things on a server in a language of your choice and render to the browser as necessary.
Use whatever you like.
The results aren't necessarily better than other search engines in general but the personalization is so incredibly valuable.
Oh and having it auto rewrite Reddit results to Old Reddit helps a lot too.
Bun has replaced a massive number of tools and dependencies from our stack and really counteracted the tooling explosion that we were forced into with node.
It'd be incredible to get to a point where we can have natural conversations and the AI is running tools in the background and keeping tabs on things.
Isn't that handled by whatever Tool API you're using? There's usually a `function_call_output` or `tool_result` message type. I haven't had a need for a separate protocol just to send responses.
Also currently on the front page. It's mainly that this tool hits the trifecta of having privileged access, untrusted inputs, and ability to exfiltrate. Most tools only do 1-2 of those so attacks need to be more sophisticated to coordinate that.
I don't think your XY phrasing fully describes the GitHub MCP exploit and curious if you think that's somehow a "token scoping" issue.
Really trivial to have the LLM first filter it down to the sections it cares about and then condense those sections though.
Wrap that process in a small tool and give that to the LLM along with a `fetch` tool that handles credentials based on URLs and agent capabilities explode pretty rapidly.
So conditions in Common Lisp? I do love the endless cycle of renaming old ideas
How often do you have to do that though? I was under the impression that Clojure was a bit like CL in that old code will keep working basically forever. Unless there are new features you need, you just leave most libs alone to do their job.
Since when? Maybe we have different definitions of "encapsulation" but this clause seems nonsensical to me. FP is huge on encapsulation
I'm really hoping we have very different definitions of "frontend"