Moving this to


I'm a NY-born Oakland resident who programs for game companies to survive. I teach Scratch to kids at our town's video game museum.

In my free time I used #Flash a lot, then #Haxe, and now a lot of modern #JavaScript. I port things as a way to preserve ideas. I have a loving wife and 2 cats.


#webgl #threejs #pasta #halloween #science #wordplay #gpl #matrix #macintosh #darkwave , uuuuh, #antifa #kielbasa #netneutrality #humanity #flan #pasta


@rezmason I'm curious how people actually port an application. Do you completely rewrite it? Or use a tool that does things to make it easier?

@abstractxan In my experience, a port is a series of text operations than turn code of one syntax to that of another— followed by operations to swap out dependencies. Some text transformations can be automatic, but often it’s a manual (but systematic) process. It helps when the original project is somewhat modular, because you can then transform one module at a time.

@abstractxan Verification of the correctness of a port is important for knowing when the job is done, but also (when possible) to identify problems partway through. When I ported Drivey in 2018, I started by hand-converting it to Haxe, an inherently typed language with a strict compiler. The compiler errors acted as an evolving checklist of remaining work to do. Only afterwards did I transpile it from Haxe to the more accessible but less strict Javascript.

@abstractxan Often, you also need to make a “shim”— a layer of code that gives the ported code familiar functionality similar to an original dependency. For instance, Verreciel was originally built in Apple’s SceneKit, and used the SCNTransaction to smoothly animate rotations and colors. The browser and three.js have animation features, but they’re nothing like SCNTransaction, so I had to shim it.

That was pretty fun actually!

@rezmason Doesn't that mean one needs to understand the ins and outs of all the dependencies?

Though this could be checked with the progress of the porting via the output. Isn't this way too manual?

FOLLOW UP So 'porting' include a lot of studying about the insides of libraries ?

@abstractxan It all comes down to luck, really. Some dependencies have common APIs that map easily to other libraries. Some libraries are available for multiple platforms, and expose identical APIs. A shim should be as small as possible. SCNTransaction is just an oddball API.

In fact, I've entertained the idea of refactoring Verreciel's UI to be declarative, like an SVG type thing, to get away from its dependency on the animation system. But a post-port refactor is complicated.

@abstractxan Once a ported codebase is refactored, the relationship between the port and three original project becomes more distant. If there port is the official remake, then that's fine, but if the original project continues, it can feel like, I dunno, code estrangement. Speciation. Whereas the original aim of a port is to be faithful to the original. 🤷‍♂️ I overthink this part often

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.