I don't like how SD consolidated around the A1111 repo. The features are great, and it was fantastic when SD was brand new... but the performance and compatibility is awful, the setup is tricky, and it sucked all the oxygen out of the room that other SD UIs needed to flourish.
While it has a fraction of the features found in stable-diffusion-webui, it has the best out of the box UI I've tried so far.The way it enqueues tasks and renders the generated images beats anything I've seen in the various UIs I've played with.
I also like that you can easily write plugins in Javascript, both for the UI and for server-side tweaks.
The problem is those features/extensions in A1111 are absolutely killer once you use them. I assume they have ControlNet support now but I couldn’t do what I often do without regional prompter. Adetailer is also amazing.
Easy Diffusion does much less. No ControlNet support. Only just got LoRa support (at least in the beta channel). If A1111 is "professional", Easy Diffusion is maybe "hobbyist".
I use A1111 as a tool, but if I want to goof off, I queue up a bunch of prompts in Easy Diffusion and end up with a gallery built in real time. Its smaller feature set make it great for that.
It’s open source. The only way to compete is on your merits in open source.
If you want another UI to flourish, clone both it and A111, copy and paste the bits from A111 you’d like to have in yours (with attribution) and push it up along with any features you personally want.
That does require developer time, and developers may converge on a popular implementation with good tests and lots of features as it’s easier to contribute.
The bottleneck isn’t really the community though, it’s the developers.
Its not that simple, as A1111 uses the old stability AI implementation while pretty much everything else uses HF diffusers code.
I worked trying to add torch.compile support to A1111 for a bit, fixing some graph breaks locally, but... It was too much. Some other things, like ML compilation backends, are also basically impossible.
- Compatibility with stuff from research papers and ML compilers since it is the "de facto" SD implementation.
- The codebase is cleaner more hackable, and (compared to base SAI code) more performant.
- HF continues to put lots of work into optimization and cleanup. For instance, they ensure there are no graph breaks for torch.compile, and work with other hardware vendors for thier own SD implementations.
Its super easy, in fact I think they specifically have a long prompt pipeline. Look at the implementation in pretty much any diffusers UI (like VoltaML or Invoke)
Facebook's AITemplate backend even supports long prompts now.
I don't like how SD consolidated around the A1111 repo. The features are great, and it was fantastic when SD was brand new... but the performance and compatibility is awful, the setup is tricky, and it sucked all the oxygen out of the room that other SD UIs needed to flourish.