I felt the same way in 2024-2025. Then Sonnet 4 was released, and things started feeling different. Opus 4.5 was another step change for me. Everything feels like it's accelerating, and timelines are getting crunched. I guess in some ways I envy OP, who would "bet everything" against ASI - the truth is I don't know, and I don't think anyone knows, where this ends.
I was able to repro one issue that could have been contributing to your broken experience - there's a slight delay between, for example, clicking text in a heading and having the "#" markdown decoration appear. This is to prevent the mouse location from shifting mid-click and causing text to be selected unintentionally (obsidian does this too). But there was a bug that was causing a cascading set of failures if edits happened during that delay window, which is likely what folks who are clicking around at random points in the editor and adding text are doing. I fixed it in 0.4.2, which should be live now.
Thanks for trying it out! would you mind giving some steps that allow me to repro the issue? It's early days so i'm sure there are some rough edges, hopefully I can fix them quickly.
Thanks for the heads up - I pushed up a fix to the hightlighting issue.
I originally went with Milkdown (Prosemirror-based) for Atomic, the knowledge base project that I built Atomic Editor for. ProseMirror doesn't provide virtualization out of the box. For shorter notes and even moderately long content it's fine - but atomic supports syncing content from a diverse set of sources and I noticed that long documents were causing delays on initial page load and some lag during edits. I didn't find anything like it with native virtualization that felt right to me so I built Atomic Editor.
Could you expand on the "substantial ops burden"? Let's say you're using a managed Postgres instance as the underlying data store, how substantial is the ops burden in that case? I understand that temporal is actually a set of 4 or so microservices on top of a data store, but if you're already running a distributed system backed by k8s or something like that, it doesn't seem like it adds significant incremental ops on top of that. But I could be wrong.
Looks like this comment is touching a nerve. This community is progressing from "AI can't write code", to "Well, AI can write code but it's not really about the code". I wonder where the goalposts will be moved next?
Tauri is great! this is my first Rust-based project and it took some real getting used to. But i love that Tauri does not ship with an entire chromium browser, and i love its focus on security.
Local first means running Atomic with local models is not an afterthought. It’s a first class citizen that works just as seamlessly as running with a cloud provider - assuming you’ve done the work to provision the local models and their connections yourself.
I'm not sure I understand the question. Regardless of what provider you choose - be it cloud based or local - you have to provide setup information such as host, authentication, etc. So it "defaults" to nothing; you have to select something.
Thanks for the feedback. Yeah, I admit copywriting is not my forte. i'm a solo dev, I'm focusing most of the time and energy on the product itself. There are always 100 things I could be polishing for Atomic - social media presence, website, docs, etc. even with AI there just aren't enough hours in the day - you have to triage somehow.
It has supported local LLMs from the beginning, it was not something that was just tacked on. I don't know what else to tell you. Your assumptions are just wrong.
Did you think local-first meant how a dropdown is sorted?
OpenAI-compatible is indeed one of the provider options for Atomic. Ollama and openRouter are separate options to allow for easier selection of models from these specific providers.
I'm not sure what the dunk is supposed to be here .. Atomic supports the exact same feature set with local models as it does for OpenRouter. Is your gripe just that Openrouter is the first option in the dropdown?