# Help Wanted: avogadro-web **URL:** \ **Category:** Development\ **Created:** [August 28, 2026, 6:22pm UTC](https://discuss.avogadro.cc/t/help-wanted-avogadro-web/7508 "2026-08-28T18:22:27Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [August 28, 2026, 6:22pm UTC](https://discuss.avogadro.cc/t/help-wanted-avogadro-web/7508/1 "2026-08-28T18:22:27Z")
There have been a few requests for “avogadro on the web” for a while, but that’s been hard since the codebase is in C++ with bits of Python. Two big developments: - Emscripten + [WebAssembly](https://discuss.avogadro.cc/t/webassembly-build/7394) =\> compile C++ to the browser - Pyiodide =\> run Python in the browser The catch, I think is that we’d want to make an `avogadro-web` project fairly modular. In other words, rather than having menus and option panels running through Qt, providing these as HTML + CSS so users can tweak them, integrate them into their website / JupyterLab / teaching system, etc. In other words, I think an `avogadro-web` project would be a thin “frontend” to `avogadrolibs` much like `avogadroapp`: - load up the 3D rendering panel - load various tools - load menus - etc. And then obviously it could then be configured with different toolbars (e.g., only key tools if wanted) or menu options (e.g., only view, build and select). This means that we’ll want to migrate the tool options to generate JSON much like our plugins. That way a website gets the JSON (e.g., pick an element and bond order) and can render it in different ways with HTML and CSS rather than rely on Qt widgets through WebAssembly. So what’s a “first minimal version” look like? - 3D rendering - navigate and edit tools - open / save I’m still debating some of this design in my head so I’d appreciate thoughts - as well as interest… ---
**Author:** ![matterhorn103](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/matterhorn103/32/1751_2.png) [@matterhorn103](https://discuss.avogadro.cc/u/matterhorn103)\ **Post date:** [August 29, 2026, 9:34am UTC](https://discuss.avogadro.cc/t/help-wanted-avogadro-web/7508/2 "2026-08-29T09:34:51Z")
I feel like implementing the tools using a JSON-based API would be an unnecessary hit to performance for something that is being used constantly. Wouldn’t it be better just to generate bindings for the tools in an appropriate language that can then be used from JavaScript? Naturally anything that’s on the web will probably want to have zero use of Qt Widgets. Perhaps it’s a good opportunity to improve the separation of concerns in the project. In an ideal world `avogadrolibs` would not depend on Qt Widgets (or Qt Quick) at all and everything UI-related would be in `avogadroapp`. By my understanding the codebase leans on Qt Core a lot for general QoL stuff like `QString`, would that kind of stuff be an issue on the web? Would it not just compile to WASM using Emscripten? ---
**Author:** ![ghutchis](https://discuss.avogadro.cc/user_avatar/discuss.avogadro.cc/ghutchis/32/456_2.png) [@ghutchis](https://discuss.avogadro.cc/u/ghutchis)\ **Post date:** [August 29, 2026, 12:25pm UTC](https://discuss.avogadro.cc/t/help-wanted-avogadro-web/7508/3 "2026-08-29T12:25:07Z")
> [@matterhorn103](#): > > I feel like implementing the tools using a JSON-based API would be an unnecessary hit to performance for something that is being used constantly. Wouldn’t it be better just to generate bindings for the tools in an appropriate language that can then be used from JavaScript? I think you misunderstood. I was talking about a JSON-based API for providing the tool **options** - like picking the element or bond order for the draw tool. That way a web interface doesn’t need to use a Qt Widget for an options dialog. It can take the JSON representing the options and generate an appropriate HTML / CSS panel. > [@matterhorn103](#): > > In an ideal world `avogadrolibs` would not depend on Qt Widgets (or Qt Quick) at all That’s not going to be practical. There’s already good separation in `avogadrolibs` itself, since only `qtcore` and `qtplugins` depend on Qt. Moreover, an `avogadroweb` project would still want the same _tools_ or it wouldn’t “feel” like Avogadro. It would just want a way to avoid using Qt-based dialogs. Even many menu commands would be just fine - you wouldn’t want to duplicate code for Copy / Paste / Select All, etc.