Tend (and about Vibe Coding)

It’s been a while since I’ve coded for myself. I did push an update on [Ssstyles](https://iamschulz.github.io/ssstyles/) and [JSSynth](https://jssynth.xyz/) every now and then, but I haven’t done something new. --- # Why? I needed a habit tracker to get on top of my health again. It needed to be easy to use and sync across devices without selling my data to ad companies, which means selfhosting. The [awesome selfhosted](https://github.com/awesome-selfhosted/awesome-selfhosted) list has a few projects, but… - [Habitica](https://habitica.com/static/home) looks really nice, but it’s a bit much. I didn’t want to gamify things. - [Beaver Habits](https://beaverhabits.com/) doesn’t support personal goals. - [OpenHabitTracker](https://openhabittracker.net/) just looks really clunky. I also wanted to brush off my Vue skills. Time to do it myself, then! # Building it I started with a very minimalistic approach: HTML, CSS and Typescript with [Petite Vue](https://github.com/vuejs/petite-vue) on top for reactive components. Not only did things go out of hand quickly, with the entire content of the app being driven by user-defined input, but Petite Vue itself hasn’t been maintained in years (which is a shame - i really liked the project). So I went to the other extreme and set up [Nuxt](https://nuxt.com/). If all the content was dynamic anyway, why not go all the way. I know that Nuxt has some performance and accessibility problems, but my performance target is a bit lower when building an “app-like” project, as opposed to a traditionally content driven one. It turned out I could still reach good performance metrics, thanks to caching user content to an IndexedDB and SSR’ing the app skeleton. Wrangling Hydration issues was an ongoing problem, though. I figured I could mitigate accessibility problems as best as I can with enough testing. [Marcus’](https://marcus.io/) book [Accessible Vue](https://accessible-vue.com/) was a great help, too. I used my own CSS framework Ssstyles as the foundation and I really love having a functioning system. I did find some caveats that I [fixed](https://github.com/iamschulz/ssstyles/releases) during the development process, but most of the base styles and components worked out of the box and were a breeze to use. # Deploying I tried something new here. Tend deploys directly to Netlify, where it’s usable as a PWA. There are no accounts or tracking and everything stays on your device. That also means there’s no sync across devices. That’s why every new release also creates a new docker container with a database and a simple single-account-login. It doesn’t deploy anywhere, but it’s self-hostable. I did read a lot about backend security and learned one or two things about attack vectors. I hope it holds up! So if you have a home server, you can use the [docker setup](https://github.com/iamschulz/tend?tab=readme-ov-file#self-hosting-with-docker), or else install the [PWA](https://tend.iamschulz.com/).    # On Vibe Coding At some point midway through, my employer gave me access to Claude Code. I tried it here and I have some thoughts. I think, Claude can be a welcome help to unwelcome tasks. Figuring out what the unwelcome tasks are is the harder part. If you use it to write a some syntax you rarely use - fine (though you can just use MDN for that as well). But using it to write your entire app? That’s for people who don’t like coding. In that case: please don’t. You’ll ship code that you don’t understand, full of bugs, problems and security risks. I used Claude to write JSDocs and Tests. Those are unwelcome tasks to me and the LLM is fairly competent at documenting. Tests needed some more guidance. I found that [Context Rot](https://www.trychroma.com/research/context-rot) was a major problem. If the list of things that it needs to keep in mind gets too large, it becomes forgetful. I mean, so do I, but the things I forget are “updating the version number” or “writing a JSDoc”, not “how does the app work” and - more importantly even “what did I already try”. Claude went in circles multiple times when the context was approaching its limit, proposing fixes, testing and reverting them, when the correct solution was a simple missing `import`. Struggles continued with anything regarding accessibility. The amount of misinformation it gave me and the faulty code it wanted to write is baffling. Claude seems to love [aria](https://www.w3.org/WAI/standards-guidelines/aria/). Whenever I described a problem (e.g. “label xy is ignored by VoiceOver on MacOS”), it completely ignored the underlying issue and slapped some aria on top of it. At this point I can only discourage from trusting AI tools when coding barrier-free content. Would I use Claude again? For my job, yes. For private projects - maybe not. I did find it helpful for testing and documenting, but the price (both monetary and in resources) is still very steep with no signs of coming down.