Sign in Subscribe
lab notes

Lab note #072 A language with affordances for vibe coding

Wil Chung

Wil Chung

— 2 min read
Lab note #072 A language with affordances for vibe coding

This week was a little stalled. Had some daily life administrivia to take care of, but I did manage to focus on one question: what, if any difference was there to the choice of language for vibe coding?

After looking into some of the other reactive systems, React stopped being the obvious default for me. I think the people that looked into this find it obvious, but I think for most of mainstream web dev companies, they still default to React.

The current two other class of alternatives are Svelte-likes and Solid-likes. Svelte-likes take your code and just compile it to something imperative. Solid-likes are more like data-flow programming in disguise.

Surprisingly, I'm hard considering using Elm. This is surprising because:

  1. It has an orders of magnitude smaller ecosystem than any of the others.
  2. It hasn't had an update since 0.19, which was over six years ago.
  3. The only way to do FFI is through ports, which is a little cumbersome, and through web components, which one needs to be careful about states.

But this is because I think Elm has potential to be a good vibe-code target language for a variety of reasons. (I'll expand it in a post)

  1. Solid type system to keep agents in check.
  2. Tends to keep code into a single file, which helps agent caching
  3. Good mental model for humans to course correct.

I converted the buying decision app from raw HTML5 to both SolidJs and Elm as an experiment. It was surprisingly a tossup for a while. There's only one reason that I'm leaning towards SolidJs, and it's only because I have a odd requirement of being able to move stuff around at 60fps, but still aware of DOM elements. Elm unavoidably has a virtual DOM that it performs diffs on, which is O(n). There are workarounds by using only CSS, but more complex animation paths aren't possible. And another workaround is to render to canvas, but it comes with more work trying to synchronize the state of the DOM with the state of the canvas. That smell like pain.

Instead of spending more time to evaluate the amount of work it would take to support a pure functional codebase–as much as I would like it–I'm just going to decide on going with SolidJs. Besides, if it doesn't work out for whatever reason, I can always get vibe coding to convert it.

On to the other risk factors this next week.

Read more