In this dev log I want to talk about two projects that are entirely front-end web based. Last week I spent most of my time working on Flutter & command-line applications and over the weekend into now have enjoyed going back to the fun feedback loop of front-end web development. Hopefully you'll find some of these projects interesting or even useful.

Intrepid Ibex

This project has been so much fun to do.

I feel like it really provides next to nothing for the wider ecosystem, given that taproot.at, at-me & pds.ls exist, but the data afforded by the atmosphere is the perfect way to play around with wacky ideas.

Check out the app here or follow along with codebase below.

desertthunder.dev/ibex
browse the protocol like its 2008
https://tangled.org/desertthunder.dev/ibex

The biggest addition recently has been a blob viewer. It doesn't quite work for videos yet but pictures work! In fact, I'll use pictures to show you some of the changes because I tend to not be able to describe or ask meaningful front-end questions, beyond "is this cool?"

Three small (visual) changes here:

  1. 1.

    Direct linkable collections & records

  2. 2.

    The old Ubuntu startup sound in the audio menu (this used to link to plyr.fm)

  3. 3.

    A tiny version tag in the sticky note

Direct linking uses rest params/matching in SvelteKit's filesystem based routing system to take a url like this...

/repos/did:plc:xg2vq45muivyy3xwatcehspu/collections/app.bsky.feed.post/3moiqb54iyk2x

...to resolve the location in the window stack to show you what you're looking for. You can learn more about rest params at the official doc site.

In summary, the position in the stack after you've given a DID is unknown, so at that point we leave it to the application to determine what to render. This is done by a "window manager" state machine backed by classes to encapsulate runes. I thought calling it window manager was cute.


Here's the blob viewer in action: showing a screenshot of this leaflet site.

To reiterate: I think this best demos the sandbox-ability of our repos and records because if you want to experiment with a UI paradigm like a photo gallery, you have your own blobs and xrpc methods to develop against.

Here's the post for context, in which I basically +1 the site page feature leaflet added.


Finally I wanted to show the "Keyring" which just shows a view of your atproto identity. This is direct linkable with this structure:

/repos/{did}/identity

Before the most recent deployment, the "logged in" user owned all of the routes and collections. You don't actually login, you simply define the account that gets cached. Login exists for nonsense like this...

...a useless lock screen.

W1C

I have a bit more to say about W1C. So given everything I did with tempest and then "Ibex" above, I thought it would be cool to put all of these things in to a component library for myself mostly. The only hurdle was that Tempest is a Phoenix/LiveView application and Ibex is pure Svelte so the middle ground I found that would also give me an excuse to learn something new was web components.

The library itself is made with Lit, a web component framework. The API is really intuitive and nice to work with and it makes me realize that I quite liked the class based Component architecture React had back in the day. It just makes sense to override methods to implement behavior. My key take away from working with it has been that there are certain paradigms that are just easy to use all the way down. These components are remarkably easy to write, use, and test. The documentation site itself is a consumer of the web components. In fact, they're all inside of a wrapper Svelte component that itself is rendered in markdown routes via mdsvex.

To build this, I used my two existing projects (ibex & tempest), with some research and memories of Geocities to define themes. What I'm most proud of and eager to share is probably the most derivative portion of the project. Writing custom documentation sites isn't a novel concept or particularly interesting technically and a lot of the design motifs for the mac theme in particular come from system.css. The novelty and challenge comes from pointer capture you see in the windows because they're draggable & moveable within a container.

I also was not aware of how powerful Storybook could be for this type of work! Pictured below is the story for a marque component. Nothing here should be too shocking for anyone at all steeped in modern web dev, but for me, playing with props and running tests in my browser like this has been so cool. It's truly remarkable how much the greater JS ecosystem provides you for library authoring.

<div class="w1c-story-shell">
	<p class="w1c-story-note"><strong>Theme</strong>: Geocities (<code>geocities</code>)</p>
    <w1c-marquee direction="left" speed="12" pause-on-hover="">Welcome to the W1C Geocities component room.</w1c-marquee>
</div>

I plan to officially release this project soon. Right now I'm cooking up some examples and polishing the documentation and test suite. You can clone and play with the project right now though. You can even read the documentation on the command-line.

GitHub - desertthunder/w1c
Contribute to desertthunder/w1c development by creating an account on GitHub.
https://github.com/desertthunder/w1c