Advent

There’s nothing quite like the clarity of losing your job on a friday that forces you to contend with the bigger question; who and what kind of future do you want to build for? For the last year, I’ve been deep in the local-first ecosystem, learning alongside peers and building the infrastructure to power local-first software. Amidst the hype of AI and agent-driven code, I’ve witnessed a quiet hum of folks demanding to take back control, of their data, of their tools and of the role software has in their everyday lives. Local-first is not just a software methodology, it is a philosophical movement. It’s about building software for people in the context of where they’re at. ...

As the saying goes there is no cloud, just someone else’s computer. Simplistic as it is, the saying captures a universally accepted reality: app data is better off hosted elsewhere living on someone else’s hardware (I’m looking at you GCP and AWS). The issue with this cloud-first sentiment is that it relegates the cloud as a panacea. Sure, giving control to the cloud frees us from the burden of bootstrapping infrastructure and managing complex ops, but it comes with its own set of tradeoffs. Chief among them? The total loss of control over our own data. Not to mention the added reliance on third-party uptime (looking right at you us-east-1). ...

The rise of the local-first movement was no anomaly. For years, browsers were no match for native environments that offered superior performance and offline capabilities. The gap was painfully obvious, native apps could store gigabytes of data and had access to a whole file system while browsers barely scraped by with megabytes. Modern browsers have since caught up over the last few years and the divide between browser and native environments has significantly blurred. There were many developments that gave rise to this, chief among which are: larger browser storage capacity, and new storage APIs. Let’s examine these. ...

In my last post, I mentioned that what makes an app local-first is its ability to keep running even when a connection falters. At first glance, this might look a lot like the offline-first movement that arose alongside the progressive enhancement wave of the mid to late 2010s. But there’s a subtle distinction. Offline-first apps focused primarily on staying functional during network interruptions but the server remained the primary data source. Data in this context is stored locally until a connection is restored, after which the locally stored data is deleted in favor of the remote store. A restored network connection progressively enhanced the experience and syncing only happened when there was new data created during the interim offline period to upload. ...

I’m frequently amused by how often local-first software gets mistaken for community initiated software. The ethos is spot on, but the confusion is revealing: cloud first has become the de facto standard for building apps. Local-first challenges this notion and subverts the dynamic between cloud and device. It puts the device at the center of operations. In this way, local-first apps remain operational despite an unstable connection unlike cloud-first ones. This of course doesn’t disregard the cloud completely. In a local-first model, the cloud shifts to the role of facilitator, ensuring data is synchronized across devices and sessions. ...

Didn’t make a lot of progress today and decided to play around with shapes instead. Here’s a heart -> https://codepen.io/shortdiv/pen/zYxGQBm?editors=1010

Geometry is the basis for drawing any shape in ThreeJS. As I covered in earlier posts, geometry in ThreeJS consists of vertices and faces, which can be defined by hand in order to create custom geometry. Of course, this task of defining your own vertices and faces is ambitious and requires a firm understanding of how math works in ThreeJS—knowledge which I currently do not have. To keep things simple, ThreeJS offers default 3D shapes known as primitives so you don’t have to grok geometry to generate common shapes like spheres and cubes. ...

Most shapes in ThreeJS and WebGL can be created using primitives many of which, you can use to create composite geometries, like this really neat christmas tree. Creating complex and unique geometries however takes effort and can be difficult to achieve by simply compositing, mutating and ”extruding” existing primitives in ThreeJS. A better approach, as I highlighted in a previous post, is to utilize the methods like Geometry in ThreeJS that give you the flexibility of defining vertices and faces for custom polyhedrons. In addition to this, ThreeJS also offers support for working with curves and smooth surfaces. ParametricGeometry is example of such a method that gives you the ability to work with parametric surfaces, or surfaces which extend the idea of parametrized curves (fancy terms for bézier curves) to vector-valued functions of two variables—from my understanding this basically means a 3D non straight surface. ...

Walking at angles When drawing in 3D and even in 2D, we rely on shapes to make up a larger geometry, which then go on to form a more complex scene. This may seem rather straightforward but to a machine the task of drawing shapes could not be more complicated. This is largely because most machines only know how to render triangles. Take the humble square. Ordinarily, a square is drawn from point to point around the perimeter of the square, so in the figure below we’d draw a square from 1 → 2 → 3 → 4. From a computer’s perspective however, drawing a square would go 1 → 2 → 4 → 3. ...

Because we’re starting from the basics, this week we’ll focus largely on shapes and rendering shapes to the screen. This task may seem trivial but I assure you there’s a lot happening to occupy a week’s worth of content. To keep things simple, we’ll create our 3D images using ThreeJS, a JS library that abstracts a lot of the complexities of WebGL so you can write graphics with the power of JavaScript! ...