Xanthar is a graphic designer who is creating graphics for a medical imaging company. He’s created a plugin that pulls in x-rays he receives, adds a layer of vector graphics over them and then exports the artboard to SVG in an HTML page on the local intranet.
He has automated some of it but when the doctor wants to see the export they have to open a browser, copy a link from the plugin and paste that link into the browser.
Xanthar found the new web view API and is able to open the exported HTML page right in XD.
Lily is a botanist, computer scientist and teacher from India that is using XD to create artificial flowers in vector format from her growth branching algorithm.
She released her first plugin one month ago and her students are starting to use it but have been emailing her on how to use it. She decides to write instructions for her users in Word and exports it to HTML. She put the instructions online but the internet goes down multiple times a day so she wants to include the web page with her plugin.
She finds out about the web view and when her users click on the help icon the help page loads right in her plugin.
I think this would also ease some of the development pressure on the Adobe team. My understanding is since UXP is not built on something like Electron (basically just a web browser), but is instead using web technologies to define the user interface, being rendered using proprietary code, it’s going to be very hard to make sure the UXP runtime is in sync with the latest web technologies.
A lot of plugins currently written on CEP make use of these modern technologies to create high-quality user interfaces and innovative features. If the plugin authors are limited to a fairly small scope of HTML, I think their ability to innovate and help push Adobe products to new limits would be severely limited.
We understand there is a high demand for this feature and we discussed this internally. However, due to performance and security reasons, this won’t be implemented in the near future. Moving to UXP from CEP was because of this core reason to begin with.
1.5 years later… i assume this is still Adobe’s position?
Asking because we build CEP extensions that rely on iframes to connect to our backend enterprise app… and are concerned with this UXP limitation.
As an alternative, if we build a desktop standalone app (for example in Electron), will there be a way to establish a 2-way communication bridge from our app to our UXP plugin, as a replacement for an in-UXP iframe?
The latter is already possible, and lots of plugins make use of it in one way or another. Basically, your helper app needs to start up a local websocket server, and UXP plugins can then connect to that. Once connected, you can send information back and forth quite rapidly.
We are looking at bringing some initial webview support to UXP, but it will first be limited to modal dialogs, and we still have a lot of security issues to iron out. (Webviews in our host applications are non-trivial.) There are a whole host of issues for supporting webviews in panels (keyboard focus is a big one!), and we’re also working through that. Furthermore, webviews do incur a fairly heavy memory and performance hit, especially if used in multiple panels.
It’s also worth nothing that a lot of plugins that used webviews in CEP also mixed that with Node.js – the latter is something UXP has no plans to support. If you need Node.js in your plugin, a helper app is the way to go.
Also coming this year is also a launchApplication API so that you can launch your helper app should it not be running. This should improve the user experience of helper apps greatly.