❤️‍🩹 Why leave a good thing behind?

I've been cheating on my beloved website. This very one. I've gone and built another, only to realize that I already had everything I wanted.

What I Missed

Good Bones

I have a good file structure. It's flexible in all the right places. I feel like adding new content is a breeze.

Built right

My build setup here is SO perfect. It's very minimal. Tailwind handles the CSS, 11ty handles the HTML. I might bring in esBuild to handle the JS.

None of these portions are overstepping their bounds. In my new setup, I tried to combine all of these, and it's a nightmare!

This site is basically sensible defaults that are easy to opt-out of. It's perfect.

Why I left

I wanted to tinker with different styles! I wanted to opt out of my CSS, explore DaisyUI. That's basically it.

However, while I was tinkering with ways to reduce my pages into components, I found a couple patterns I'm really digging.

So I've looted the new site of the gems it contained, and brought them back here.

I've created multiple tailwind configs, and am keeping them at a public URL.

I've building the CSS I need, when I need it.

I've reshaped a couple things on this site, but kept lofi spirit.

🗺 Road map

1. Improve 404
2. Improve chat
3. Improve page organization
4. Figure out x-html/11ty plugin
5. Improve sidebar
6. Expose games, books, and experiments
7. Write docs and host my OSS stuff
8. Rework the posts/post pages
9. Improve head tag garbage
10. Probably remove daisy-UI themes, (maybe keep interactive parts)
11. Expose more tailwind vars (SystemColors, Interactive Colors, CurrentBackground, Dynamic Spacing, etc)

✍️ Ipads

📌 Bookmarklets!

Did you know you can run javascript with a URL?

In place of a http: or https:, you can prefix a URL with javascript: and it will evaluate the following text as JS. You'll still need to URL encode the Text, but it does provide a handy way to use JS.

Bookmarklets are a term for Bookmarks, which trigger some Javascript instead of loading a webpage.

Some bookmarklets I use.

Drag the Link into your bookmarks bar to use it yourself!

😱 Emoji OMG

Pulling an emoji from text isn't super straightforward. There's no special character for emoji in regex.

I'd like to start replacing the favicon for the page with a favicon found in the <h1> of the current section. So the first step is determining if there's an emoji in the <h1> at all. However, this task is tricker than it seems. EVERYTHING online indicates the best solution is a LONG LONG string of regex which tests the unicode data.

I'll do some research and see if I can find a better way to do determine if a character is regex.

My Findings!

The typical advice you'll find online when searching for how to determine if a character is an emoji is to use RegEx, but I've found a MUCH easier way!

Strings in js can be split into characters, and with the spread operator, it's easy!

Splitting a String into Chars

    const string = "🤖: Hello World! 👋";
    const charList = [...string]; // [ "🤖", ":", " ", "H" [[...]] , "d", "!", " ", "👋" ]

Which doesn't mean much on it's own. Frankly, it's more cumbersome to deal with. BUT! Javascript did something interesting! It didn't split up ALL the characters! As you can see from the any emoji regex example, Emojis are comprised of MANY characters! Those characters will render as a single, emoji.

So JS is put in a weird position. The EXPECTED behavior of splitting a string, is accomplished. Yet, the LENGTH of each character, is technically different! Since Emojis are just unicode data rendered in a particular way, splitting a string does something fascinating in JS.

    "🤖".length; // outputs: 2
    "👋".length; // outputs: 2
    "📌".length; // outputs: 2

What it means!

Because JS splits a string by what is rendered, not by how it's represented in data, String.length does something super fascinating! It will give back a value greater than 1 for emojis!

With this interesting tidbit, you can determine if a character in a string is an emoji! Furthermore, you are able to use the many Array Methods to deal with the characters!

    const string = "🤖: Hello World! 👋";
    const charList = [...string];
    charList.some(char => char.length > 1) // charList contains an emoji
    charList.filter(char => char.length > 1) // return an array of all of the emojis in charList
    charList.find(char => char.length > 1) // return the first emoji in charList

I hope you found this helpful! I know it's much easier for me to deal with Emojis now.

🥣 Ought Mealy

Some days the web seems woefully under-equipt. Today is one of those days. Here is where I bloviate so I can look up to see if I'm right later.

I think a large unaddressed issue with the web is mealy machines. AKA Transitioning States.

For Example, This navbar was a bit more complex than I wished it to be because there's no way to determine scroll direction. A scroll event will take a snapshot in time and say: """ Yes! There was a scroll! Here's my current position! """ Gee, thanks DOM, that's mostly useless, but alright.

To know scroll direction, you need to preserve state, and compare the new state to the previous state.

This should be built into the browser right? I'd imagine this is useful information. However, there seems to be a philosophy with the web where previous states, aren't preserved. Thus, knowing much more than X event happened, seems far more difficult than you'd wish.

I'm not sure if I have any great insight here, This seems to be something that has been worked around, but never really through. xState has inspired much of my thought on this, but it seems to be a tool, without much opinion on how it's implemented. Perhaps having a good Library to handle State transitions, would be helpful beyond just handling events. I mean the core of adios is making changes based on data changes, if I can find a nice API to work with the entire platform and its events it could be a useful tool for building websites.