Choosing a front-end framework

This week has been spent learning Svelte and continuing work on the Bedrock Public Library. It’s going to be a bit briefer than usual because I broke my elbow while skateboarding and I’m having a hard time typing.

JavaScript front-end frameworks

The final piece of the puzzle for the Bedrock Public Library was finding a front-end framework that I could use to implement the BPL website. I’ve worked with these kinds of frameworks in the past, but they lie pretty far outside of my regular genre of programming.

I looked into Vue, Svelte, and Alpine (and maybe one or two others that I forgot the names of), and I ended up going with Svelte. It looks like it has the right balance of magic and simplicity for me, and it’s supposedly also very performant. I was wanting to avoid anything with a build step in order to keep everything simple on the server side, but that’s where most of the performance gains come from so there’s no reason to avoid it.

I’ve been going through the Svelte tutorial (svelte.dev/tutorial) and having a blast. The whole reactivity system is so easy and so much fun to use (it’s probably pretty standard at this point, but it feels like magic to me). Here’s a really basic example of a self-contained component in Svelte: the count variable is wrapped with the $state marker to make it ‘reactive’, and the HTML will automatically update to react to any change in the value. That’s pretty much all you have to do, the rest is all just vanilla HTML/CSS/JS with templating.

<script>
  let count = $state(0);
</script>

<button onclick={count+=1}>
  Clicked {count} {count === 1 ? 'time' : 'times'}
</button>

Working with databases

I’ve also been continuing with the design of the web API that the front-end will tap into, and with the schema of the database that the API pulls data from. It’s really satisfying to build up concepts in database tables and lay down constraints to make them work exactly how you want them to.

For the design of the web API, I’ve been reading the book API Design Patterns by JJ Geewax. I’ve designed web APIs in the past but not with any formal training, and I wanted to have some kind of solid foundation of rules to build from that I didn’t have to distil myself from a mosaic of random blog posts. I’ve only read the first third so far, and it’s already been really helpful.

Thanks

Alright, that’s enough typing for my poor arm. Thanks for all of your support, I’ll catch you next week with more progress.