As mentioned in my previous blog post, I decided to focus on building a web app until Adobe improves their new toolkit (the UXP API) for developing Photoshop plugins, or they make it possible to sell Adobe XP plugins via their built-in marketplace.
I’ve tried many systems and toolkits for developing web apps. In fact, I described some of them in previous blog posts. The most recent one I tried is called “Velo by Wix.” It used to be called “Corvid by Wix” but…
Velo by Wix is pretty awesome. For starters, it’s a lot like Squarespace or Weebly, in that you can develop your entire website in the browser, without needing any external tools. There are all sorts of drag-and-drop blocks and UI widgets, and you can style/theme them all from one central place. They take care of hosting, updating the server software, gathering analytics, etc. However, unlike Squarespace or Weebly, Velo by Wix also lets you write both client-side and server-side JavaScript in the browser, using their browser-based IDE. It’s pretty slick. They provide an extensive set of Wix-specific JavaScript packages to do all sorts of useful things. They even provide a relational database!
I was able to build a web app very fast. But I ran into some weird problems that would not be problems if I was just developing a “normal” web app. For example, to display an arbitrary-size SVG graphic onscreen, I couldn’t just give the SVG (text) to a Wix vector graphics (SVG) widget, because those only come in a fixed size. Instead, I had to create an iframe widget and use the window-to-iframe communications protocol to send a message containing the SVG text to the iframe, which would then take that SVG and use it to change the contents of a <div> in the page. That’s definitely not normal. Normally, you’d just replace or update an existing <svg> tag on the web page in question.
I also wasn’t able to just give the app-generated SVG, as a text file, to users of the web app. It’s impossible because Velo by Wix disables the JavaScript “Blob API.” I was able to create a workaround, but it was kind of crazy: I sent the SVG text to an external server (a Cloudflare Worker) and told it to store that SVG text file in a key-value store. It used the hash of the SVG text as the key and sent that key back to my JavaScript app on Wix. I then sent a HTTP GET request to the same server, with that key, this time asking it to send back a file containing the corresponding SVG text, and with the HTTP headers set to tell the user’s computer to interpret the HTTP response body as an SVG file to download (so their “Save File As” dialog would pop up). What a crazy amount of shenanigans to do something that normally takes a few lines of client-side JavaScript!
Wix also has the lock-in problem. You can’t just take the HTML, CSS and JavaScript elsewhere. (You could take some of it, but not all. Most of Wix isn’t open source.)
I got quite frustrated with issues like those.
In the end, I decided to bite the bullet and write all my own HTML, CSS and JavaScript. At least those are all open and well-documented standards.
You can see the web apps I’ve been working on at Pattern Town. It’s a collection of pattern generators. As I write this, I’ve made only one of the generators public. Below is a screenshot showing its user interface and an example generated pattern.
Update in August 2021:
- I added two more graphics generators.
- I changed the name of Pattern Town to Graphics Town.
- I changed it into a personal project, i.e. not a project of Zigtrig Software Inc.
- I made it free to use for any purpose.
Update in May 2023:
- The graphics generators used to call a backend server to do some of the calculations, but I decided to do all those calculations client-side instead, thereby saving the cost of a backend server. (It’s not a for-profit project, so I have no need to hide that code from anyone.)
Troy McConaghy 