Lessons Learned: Too Little Too Fast
Following my last article, Reactive Anki Addons with Svelte, I learned when and when not to think in “start up mode.”
In this commit on Kyoro UI, I deleted around 1,000 lines of Svelte code to start over. As the commit message says, the frontend was becoming unmaintainable and making any sort of progress was getting nearing an asymptote. This was essentially the entire project’s frontend.
Generally, I’m a fan of speedy programming: let’s push something that works, deliver, and revisit. And always test. This exact mindset, however, led to my downfall on this project because it was too many new things at once, biting off more than I could chew, and a concious disregard for existing code quality in the name of speed.
But how could it become unmaintainable?
- If only one person was working on it? Are you really that bad at programming?
- And only in 1,000 lines?
Kyoro’s Origins Origins
I am new to Svelte, first and foremost. Coming from over year of React experience, I had to relearn and forget a bunch of stuff. What better way to learn a new language than build a cool project on it?
Kyoro’s Origins
Since Kyoro started around September 2020 it has gone through many, many internal refactors, pivots, and changes in vision (check the commit history).
The project started out as a webapp version of this kyoro, a Go command line tool that could be configured to pull Japanse sentence data from different sources. Jibiki was the main one that was settled on at that time.
Infrastructure Changes
Rollup, Jibiki, Smelte, Storybook, Tests
Originally, the project started with Rollup, and contined some fetch stuff to query Jibiki with the user’s sentences. But this isn’t really that good, because Jibiki, like many others, use JMDict and crowd-sourced Tatoeba-based sentences, which are known to not be great quality.
The initial interface library was Smelte, a Svelte implementation of Material UI
The project contained much other needless stuff, like
- Tailwind - Trying to get it working at the same time. Smelte is built in Tailwind, so it had the advantage of allowing you to use Tailwind too, in theory. The problem was making it work with Storybook. At leat one thing didn’t work: Tailwind in storybook, Tailwind in the app, webpack, rollup, or Smelte.
- Storybook - A discovered Storybook a while back, and thought hey, wouldn’t it be cool to do the whole visual-documentation thing? But I’m not documenting components, I’m building an app. Just build the component.
- Tests - Generally, I am a huge fan of testing, but I’ve found in my experience they’ve generally been unneeded in the frontends I write. I’m not writing a Jira or GitLab; the frontends typically boil down to making buttons and inputs show, to call complex backends.
Much toiling with these configuration was had, until I gave up and…
Rollup and Carbon Components
I switched off of Smelte (as it was just too ametaur) for IBM’s Carbon Components. Great looking library, and I love the corporate style. However, my builds were now taking upwards of 10 seconds with Rollup to see a change reflected–not at all acceptable for the quick save-and-see nature of Svelte and CSS development.
New solution needed. We weren’t done yet.
Snowpack
It just so happened around the time I was developing this that Svelte officially adopted Snowpack as the bunder of choice as SvelteKit was being developed, over Rollup. I once mentioned Snowpack in a talk a gave at Ensurem – it’s instantanious to see build change, and it made my development setup possible. But here is one more re-tool to have had happen.