After Glitch: Making a New Web Editor for Web Experiments

After the shutdown of Glitch, I would often dream about writing my own Glitch, then when I open Glitch to do it, I find out there's no Glitch to write Glitch with.

Over the past seven years, Glitch has been deeply ingrained into the way I work. I still remember being an early adopter of it in Prof. Golan Levin's class back at Carnegie Mellon. Golan would point at me whenever he tried to recommend Glitch to someone, and I'd mumble something like "it's really convenient... and you get this server thing... and it's always online...", the person to whom Glitch is being recommended would then look skeptically at the kindergarten/vapor-wave aesthetics of Glitch's website, and then at me. Indeed sometimes I contemplate myself what is it that made me use it so much.

Perhaps an important one is that everything you make on Glitch is instantly publicly online, without your doing anything to deploy it. It is online even as you type characters into the editor. I tend to make a lot of small experiments, quick projects, or mini demos that I soon forget about. If I didn't bother with the hassle of setting up a repo, cleaning up the code, and uploading it at the time, its only fate would be to sit in my hard drive and wait for the next disastrous blunder in which I completely break my laptop again. Sharing also becomes infinitely easier when projects are online by default. Even as I'm prototyping something, I can simply send the link to a friend or a mentor for feedback; or even if I'm chatting with someone on the street, I can ask them to pull up my Glitch site on their device to explain what I'm working on.

I learned server-side programming mostly on Glitch. There were other services at the time that allow you to connect databases to your site, or do some other server stuff. I used them, they worked, but I had to navigate a bunch of GUIs and hop between different tabs and windows and it was confusing and not fun. Glitch's model in comparison is as simple as it can (and should) be: you just get a linux shell and you can do whatever silly thing you want with it. You can totally spin up a server from scratch. You manage your database yourself -- it's just another file on the disk. You can do full stack without ever leaving the code editor, as if you're on localhost. But unlike localhost it is instantly and always online! My first major project with a server on Glitch was doodle-place, a virtual world inhabited by user-submitted, computationally-animated doodles. It went a bit viral and was hitting the Glitch's limits, and Golan emailed their boss and they were like "sure, I just increased your computing resources by 10x, btw congrats on your project taking off". I thought that was pretty awesome.

You can check out a video of doodle-place here: https://vimeo.com/321652912

And I haven't even started talking about real time collaboration, git integration, project showcases, remixing...

Perhaps it is one of those things that's "too good to be true". Golan warned me that Glitch is gonna shut down since day 1, and I was kinda just waiting for it to happen over the years, enjoying it while it lasts (and paying a small subscription to delay it in however small way I can). But even weeks after its shutdown, I'd still reach for the site from time to time, only to be reminded that it is no more. I urgently needed an alternative.

Firstly, all my 276 existing projects became homeless overnight, and need a place to live. Not that many of them require a server though, so in theory any static website hosting service would save the majority of them. After downloading all the projects from glitch using the python script glitch provided, I wrote a custom script to "clean up" and "prune". Some of the projects were really temporary experiments, some of them are demonstration of obsolete technologies, some of them are a small component of some bigger project that doesn't really make sense on its own, some of them are earlier iterations of some project, and of course, some require a server to work. After excluding these projects, I was left with about 50 or so projects that are self-contained, client-side and, at least somewhat, interesting. My script automatically detected links to the glitch asset CDN, and overwrote them with local relative paths.

I end up putting my glitch archive, which I call "UNGLITCH", on GitHub (source code) and netlify (hosting). You can visit it here https://unglitch.netlify.app/. I also made a landing page that curates the projects, writing a short description for each.

Now that the past is settled, it's time to worry about the future. In theory I can also put my new projects on UNGLITCH, but I felt that it should probably better stay as an archival. These projects are made with a tool now gone, and I'm presenting them in their original state. New projects deserve new solutions! Therefore, after a few messy weeks of "create new folder" on my hard drive, (and searching fruitlessly on the internet for good Glitch alternatives), I decided it's time to make my own Glitch.

Before I started, I consolidated exactly which features from Glitch I needed the most and wanted to implement first. I wanted an online editor that also safe-keeps my projects, so I can log in anywhere and have access to them, and I don't have to manage anything locally on a single computer. It logically follows that it must also have a preview feature, which lets you see the project as you're building it (otherwise you'll have to download the code and set up a local server, defeating the purpose). It should also allow realtime or instantaneous publishing, and both published projects and their source code should be viewable by everyone on the internet. Ideally, it should have git/GitHub integration, so should my webapp succumb to software rot, there's still some (hopefully) permanent safe place for the code. Finally, it should be a free universal tool for everyone, not just for my own specific projects.

What I don't prioritize include real-time collaboration (I don't like people messing up my code that much anyways), server-sides (which would complicate things alot, but definitely interested in adding it later), and remixing/community stuff (need some non-me users to give me incentive).

I name this "glitch" of mine "Malfunction". Since the words have similar meanings, and I like the absurdity.

Perhaps the first real problem to solve is where to actually store the projects. I wanted to use a service that I already trust, is free, and is easily accessed programatically. GitHub and Google Drive came into mind. Initially, I was thinking of having some sort of client-side JavaScript implementation of git to talk to GitHub. But it turns out GitHub has a REST API that can commit files directly! That saved a ton of trouble. I was also delighted to discover that GitHub access tokens have evolved a lot over the years, and now they have so-called "fine-grained" tokens, which provide configurable access to configurable set of repos. I soon decided on how Malfunction would work:

The user (me) have a dedicated GitHub repo for all Malfunction projects. Each project is a subfolder in the repo. The Malfunction webapp require from the user a three-part path (username/repo/subfolder), and an access token (think of it as a form of login). Then the malfunction webapp simply use the token to push and pull to and from the repo folder on your behalf, as you use the online editor. In essence, Malfunction serves as a fancy IDE for your GitHub account, with all the heavy-lifting such as storage, version control and so on managed by GitHub itself.

One of the side-benefits of this design is that you yourself, instead of my app, own your projects (well technically it's stored on GitHub's servers, but last time I heard GitHub isn't going down anytime soon). The downside is that it kinda look sketchy, asking you to paste your access token in an input field... But be assured! The whole reason I'm doing this is that I don't want to pay for a server, and I have no interest in stealing your access token -- everything is client-side -- you can also (and I think it is advisable to) limit the token's access to a single repo. In the future, I might add real GitHub integration with those legit pop-ups.

To view other people's Malfunction project source code, you don't have to use an access token, because GitHub allows credential-less requests to public repos, just at a much lower rate per hour. Since you won't be able to save any modification anyways, it doesn't quite matter as you'll only need the initial pull.

Now that we have the backend problem solved, the rest is just about making a good IDE. And almost half of that is handled by the CodeMirror, a library for making code editors, which I have used for quite many projects (as I always come up with new programming languages). With it, you can get all the bells and whistles such as syntax highlighting, multiple cursors, hotkeys, indentation, everything you'd expect in a legit code editor.

The unexpectedly tricky part is generating a preview for a site. You would think that we're in a browser, and we have every single file needed for the site, it would be trivial to just show the site. However, that site is not part of the Malfunction site, so before you publish it, it does not exist at a URL. Therefore, we need to use the URL.createObjectURL web API for each of the resources needed, so each will have a randomly-generated "dummy" URL. The problem arises when some content tries to refer to some other content with a relative path. When you ask for "asset/images/pic.png", it in fact exist at the random URL "blob:c1de4145-0467...". In other words, we need to replace every single mention of the original URL in the page source to the randomly generated URL (impossible statically) or hijack every web API capable of making a network request (fetch, XMLHttpRequest, img.src, etc.). I'd be more than happy to be proved wrong, but I believe there's no perfect solution. The good-enough solution I came up with is to patch just the most common network request functions (e.g. fetch), and then for fallback set up a convention for declaring internal URLs, i.e. all internal URLs should be prefixed with the comment `/*__URL__*/`, e.g. `/*__URL__*/"assets/images/pic.png"`, to be eligible for automatic replacement.

Another interesting thing I learned while making the "preview on a new tab" page is that there exists a "broadcast" feature in JavaScript, which allows all browser tabs from the same origin to communicate with each other. I thought that was pretty cool.

The rest of building the IDE is mostly just busywork: managing a folder structure and saving stuff to localstorage, injecting the preview site to an iframe or a new tab, rerouting the errors and logs to a div, CSS styling, generating a sharable URL and so on.

Finally, I connect my project repo from GitHub to Netlify. If you don't have a weird GitHub username like mine that breaks GitHub pages for half of the Internet, you can also just use GitHub pages. For my Netlify setup, I added a config file so that only commits with a "[deploy]" message tag trigger a deploy on Netlify: this way I don't use up my free monthly quota when I my fingers unconsciously fire a salvo of "Cmd-S" in Malfunction editor.

Thus my "poor man's" version of Glitch is complete. You can check out my Malfunction projects here: https://malfunction.netlify.app/, or try the editor yourself: https://malfunction.netlify.app/editor/. Enjoy!