Welcome to DevChat #16!

Here's what's we've got for today:

  • SvelteKit
  • Design is hard
  • Are Emojis text?
  • Automated Patchnotes (Part 2)

This is an archive of a DevChat newsletter. To get the next one early, and in your inbox, sign up! To read past issues, head to the archives!


If you're into front-end web development at all, you're probably familiar with the joke that new frameworks come out every 5 seconds. If you're using one of these frameworks, it's probably React.

Do you know about Svelte?

It's been rapidly gaining ground in the framework-wars, and for good reason: it's super-fast, and the developer experience is fabulous. I wish Svelte was around when I was choosing the framework for bscotch.net.

Seriously, you write code like this that just... works?

    let a = 1;
    let b = 2;

<input type="number" bind:value={a}>
<input type="number" bind:value={b}>

<p>{a} + {b} = {a + b}</p>


I was playing with it a while ago for building a new version of my personal site, and then saw this week that SvelteKit was in public beta so I dug back in. SvelteKit is a sort of one-stop-shop for all your front-end needs around Svelte (server-side-rendering, routing, etc).

I played with it yesterday and it was a joy. The Intellisense is a bit slow, but the tooling will improve as the community grows and the tech stabilizes. The tech was so fun and easy that I quickly ran out of technical problems and instead had to deal with design problems.

Design is hard

So, about those design problems. I was making these fun little Svelte components for things like social media icons, circular-cropped images, and so on. I got it all on the page with some basic styling so it didn't look like complete garbage. But then... what should it really look like?

I find the graphical design aspect of websites to be incredibly difficult. For bscotch.net I poked around tons of other websites to see what I liked and didn't like, and made a sort of mash-up of my favorites (Blizzard's site had a lot of influence in particular).

When it comes to this personal site though... it has way less stuff it needs to do. All the constraints are gone. It could look like anything.

And then it gets even worse, because websites will get loaded on both portrait mode phones and double-wide desktop monitors. So the site can look like anything, but that "anything" has to be able to adapt nicely to both of those contexts (plus everything in between). So I need two designs!

It's frustrating to have developed the skill and knowledge to be able to implement pretty much any kind of web design, but to have basically no skill in inventing the design in the first place.

Anyway, my current plan is to do a better job of adding constraints. I started this personal site project with a non-specific problem, which was that I wanted to get rid of my old site. But just wanting something else isn't a plan.

Once I come up with a coherent and specific set of goals for the new site, it'll be easier to find design references and I'll have more constraints to work with.

Are Emojis text?

Emojis are weird.

They're text after all. They must be codepoints in UTF8, right? How they display must come down to the font they're rendered in.

But most emoji aren't available in most fonts. When an app or operating system goes to find the glyph for an emoji, then, where does it look? Presumably, this is why emoji look so different depending on your phone brand and which app you're seeing them in.

But it gets even weirder than that because some emoji can be treated either as text or as emoji? But aren't they both text? The following HTML is exactly what's shown in the line right after the code snippet:

<span> vs. &#xFE0E; </span>

vs. 儭

That heart character will show up looking different even though it's the exact same character each time! Note that whether it appears different or not depends on your operating system, app, and email client. Here's what it looks like in my desktop browser:

The same heart character appears differently when followed by another character.

Here's some more info if you want to dig deeper.

Automated Patchnotes (Part 2)

Remember about 6 weeks ago when I streamed Part 1 of a series about making automated patchnotes?

Okay, so only about half of the DevChat readers were even subscribed at that point, and it seems unfair to call it a "series" with only one part, huh?

WELL FINE. I streamed Part 2 today! Now it's a real series, even if that's the last stream. I even did some programming this time (the first stream was all dev environment setup). The code is up on GitHub. There's still a lot more to do.

If I find the time I'll add some notes and upload it to YouTube, but you can already watch it on Twitch until it expires!

Hello... hello...

Is there anybody out there? The open rates are good, but maybe people are just opening these things and then deleting them! I'd love to hear from you so I know I'm not speaking into the void.

If you're on Twitter, follow me on Twitter and then say hello! Twitter definitely has its problems, but I've been finding some use by turning on alerts for things I really want to hear about and then curating the crap out of my feed. The nice thing about it is that we can have public discussions, and the short-text format helps to keep the many of you from overwhelming the one of me!

I check on in the Bscotch Community Discord quite a bit, so you can also jump into the #podcast channel over there and say hello.

If you don't use either of those things then... uh... for now I guess I'll just hope you're getting something out of this! (I'm still avoiding hooking up email replies since people might drown me in text...)

Until next time

That wraps DevChat #16!

Follow me on Twitter and GitHub for texty nerd stuff, and subscribe to the studio Twitch and YouTube for dev content in video form.

I've been having a great time hearing from readers. If you haven't said hello, please do!

Share with others by forwarding, or link directly to the archived post.

Have a great week!