Sunsetting the Fastwave Backend

Nearly a couple years ago in summer 2022, I set out, by God's grace, to write the waveform viewer I'd always wanted. It would be called Fastwave. It would be written in Rust¹. 3 months and 300 hours later, Fastwave was parsing VCD files emitted from all major vendor tools.

I then began work on writing the frontend in e-GUI but gave up after a couple weeks after I discovered it was quite difficult at the time to implement Miller Columns in eGUI. By this time, I had gone quite deep into the world of UI/UX - and when I say quite deep, I mean there may have even been a week where I visited dribble.com every day. Below is a mockup I designed in Sketch of what I had in mind when working on Fastwave:

I eventually got busy with preparing for digital logic interviews as I was actively looking for employment, and Fastwave fell to the wayside.

A few months later, I bumped into Franz on Discord who at the time had recently begun work on Spade Lang. Franz lamented about GTKWave's shortcomings when it came to displaying custom signal annotations. I told him about my work on the Fastwave Backend(FWB). A couple months later, Franz had built a prototype VCD viewer linked against FWB in IcedRs which you can see below.

I think I managed to convince him to switch to eGUI, and by January 2023, modern Surfer was born.

Shortly thereafter, Surfer exposed several bugs in FWB and I started receiving pull requests. The pull requests fixed some bugs, but also broke the architecture I had in mind for FWB. Furthermore, what I really wanted to do was completely re-factor FWB. A couple months later however, I realized that I still had not started the refactor, and Surfer was linking to a fork of FWB. Eventually in summer 2023, I gave Franz maintainer access to FWB and decided that a functional FWB was better than the as of yet un-realized perfect FWB.

Fast forward to Jan 2024, and a new waveform parser backend named Wellen arrived on the scene that was much more performant than FWB - it even supported FSTs. Shortly thereafter, Surfer was reworked to depend on Wellen, leaving FWB behind. It's now March 2024. With no new work being done on FWB, I'd say it has served its purpose. Perhaps it's purpose was to provide one of the foundational pieces needed to build a performant GTKWave alternative capable of handling large multi-GB waveform files. Whatever it's purpose was, I sure had fun building it!

Lessons Learned

1. You may have a really big vision, but start by breaking down that vision into subsets that are useful on their own. I wanted to create the perfect waveform viewer, but I started with a backend, and took the backend to completion, which brings me to my next point...
2. Once you've identified a self contained subset of your vision that can stand on its own, commit to it and don't look back. Perhaps you can allow yourself to quit if it becomes extremely clear that things cannot work out as planned.
3. If you've built something that stands on it's own, and no longer have time to build out other related components, consider open sourcing that thing and see if somebody picks it up.
4. If you receive lots of pull requests from a contributor that are of reasonable quality, and you don't have time to work on the code anymore, consider making that person maintainer. This has the added advantage of making the new maintainer feel more responsible for code they check-in.
5. Realize when your code is done and has served its purpose.
6. Write a blog post about lessons learned building that tool. In it you should mention... Actually, let's not get recursive here - haha!

Closing Remarks

Have you tried out Surfer yet? If not, stop reading right now and try the browser demo! Seriously, it's really good. You can click the demo file at the center of the screen to load a sample waveform.

What features do you dream of seeing in a waveform viewer? I'm curious to hear your thoughts. You can find my contact on the About page.