Just joined the discord! I'll also expand on this here though for anybody interested.
We wanted a single library that would allow us to write an app, and either deploy it to employee computers locally (QT, so we could deploy standalone apps or plugins within art applications like Maya, Nuke, or Houdini,) or on the web. We tried JavaScript, but some developers struggled to easily jump over to something like VueJs from Python.
Anyway, what myself and a coworker came up with was just an interface. We already write a lot of PyQT apps, so let's boil that down to the essential features and widgets we use in every app. That means: button, label, text box, drop down, checkbox, radio selection, table. That was the bare minimum to start making functional apps. For layout we needed: vertical layout, horizontal layout, and spacer. With these widgets and layouts, we figured we could recreate 90% of our apps if needed.
This was all very QT inspired. We had events on the widgets that you could register callbacks on. Value getters and setters. The first version was essentially just a barebones wrapper around QT that proxied all of the real QT functionality. It was just QT, but in order to use it you needed to import a different library and things were named slightly differently, and you could only use a small handful of methods and widgets.
After that was when the magic started happening, since "worse QT" isn't a great sell.
Now that we had a very limited subset of widgets, layouts, and methods we were targeting, we could start porting to Pyscript. We wrote a basic example app with all of the widgets, and the goal was "let's figure out a way that we can run this as-is in the browser with no code changes."
We used PyScript, and just rewrote all of those widgets and layouts with the equivalent html+ css + JS. When the developer says `button = Button(label="Click me")`, all that is really doing is making a new button html element. We forwarded important JS events into our library so we could register on-click callbacks. It was all pretty straightforward, only a bit tedious. The hardest part was actually just styling both QT and the HTML elements so they looked the same.
Vertical/Horizontal layouts were just flex boxes. A spacer was just an empty div in that flex box.
On the server side, we had to craft a bit of magic so we could `from my_app import MainWindow` and then `register_window_as_route(MainWindow, "/my_app/")`. A vaguely remember some sort of introspection to see what packages were used by the app, and zip them up for pyscript to import?
And then anything that did web requests was broken. In VFX, almost everybody uses a service called ShotGrid as their database. The ShotGrid API didn't work since it used Urllib3, so we ended up doing some hacky shit to spin up a proxy url on the fastapi server that would actually run the queries and reply with a pickled response. That part was pretty ugly but it worked.
Also threading didn't work in the browser, so we had to monkey patch a few places in our code that tried to use threads
BUT! The end result was we could write basic apps and instantly run them in QT. (the library would automatically detect which "backend" was available between QT and pyscript). With no code changes, we could import that code into our fastapi server and register it on a route, and then pull up the webpage immediately and have all of the same code run in the browser client side.
The code wasn't perfect, there were some spooky corners, but I'm proud of how well it worked from a developer point of view. We could write an app, and then deploy it. We made it a point to have no code changes required wherever possible. We had web apps deployed, and had desktop versions of the same apps ready to go in case the server ever crashed. For a small team at a small company, working on internal tools, it was an incredibly easy and efficient way to work.
We wanted a single library that would allow us to write an app, and either deploy it to employee computers locally (QT, so we could deploy standalone apps or plugins within art applications like Maya, Nuke, or Houdini,) or on the web. We tried JavaScript, but some developers struggled to easily jump over to something like VueJs from Python.
Anyway, what myself and a coworker came up with was just an interface. We already write a lot of PyQT apps, so let's boil that down to the essential features and widgets we use in every app. That means: button, label, text box, drop down, checkbox, radio selection, table. That was the bare minimum to start making functional apps. For layout we needed: vertical layout, horizontal layout, and spacer. With these widgets and layouts, we figured we could recreate 90% of our apps if needed.
This was all very QT inspired. We had events on the widgets that you could register callbacks on. Value getters and setters. The first version was essentially just a barebones wrapper around QT that proxied all of the real QT functionality. It was just QT, but in order to use it you needed to import a different library and things were named slightly differently, and you could only use a small handful of methods and widgets.
After that was when the magic started happening, since "worse QT" isn't a great sell.
Now that we had a very limited subset of widgets, layouts, and methods we were targeting, we could start porting to Pyscript. We wrote a basic example app with all of the widgets, and the goal was "let's figure out a way that we can run this as-is in the browser with no code changes."
We used PyScript, and just rewrote all of those widgets and layouts with the equivalent html+ css + JS. When the developer says `button = Button(label="Click me")`, all that is really doing is making a new button html element. We forwarded important JS events into our library so we could register on-click callbacks. It was all pretty straightforward, only a bit tedious. The hardest part was actually just styling both QT and the HTML elements so they looked the same.
Vertical/Horizontal layouts were just flex boxes. A spacer was just an empty div in that flex box.
On the server side, we had to craft a bit of magic so we could `from my_app import MainWindow` and then `register_window_as_route(MainWindow, "/my_app/")`. A vaguely remember some sort of introspection to see what packages were used by the app, and zip them up for pyscript to import?
And then anything that did web requests was broken. In VFX, almost everybody uses a service called ShotGrid as their database. The ShotGrid API didn't work since it used Urllib3, so we ended up doing some hacky shit to spin up a proxy url on the fastapi server that would actually run the queries and reply with a pickled response. That part was pretty ugly but it worked.
Also threading didn't work in the browser, so we had to monkey patch a few places in our code that tried to use threads
BUT! The end result was we could write basic apps and instantly run them in QT. (the library would automatically detect which "backend" was available between QT and pyscript). With no code changes, we could import that code into our fastapi server and register it on a route, and then pull up the webpage immediately and have all of the same code run in the browser client side.
The code wasn't perfect, there were some spooky corners, but I'm proud of how well it worked from a developer point of view. We could write an app, and then deploy it. We made it a point to have no code changes required wherever possible. We had web apps deployed, and had desktop versions of the same apps ready to go in case the server ever crashed. For a small team at a small company, working on internal tools, it was an incredibly easy and efficient way to work.