Tools: Rustroke - WASM mini draw

What I Built ## A Long Long Time Ago ## My Experience with GitHub Copilot CLI ## Copilot CLI main advantage ## AI as a reasoning tool, not a typing tool ## Hardes Spot GitHub Copilot CLI Challenge Submission This is a submission for the GitHub Copilot CLI Challenge I built one of my dream projects — a minimalist vector drawing app — but with a twist. The goal isn’t to provide the usual “vector editor toolkit” (Bezier curves, snapping, boolean ops, perfect shapes, layers, etc.). Instead, it focuses on just two actions: That sounds simple, but it’s deceptively hard. The drawing is made of independent line segments. There’s no automatic merging, no “path building” UI, no assumption that the user is drawing clean vector shapes. The fill algorithm has to detect when those freehand strokes form a closed boundary and then flood the interior reliably. The tech behind it is the best part for me: I know: today many people don’t want to draw without AI. But sometimes you just want a fast sketch, a logo idea, or a colorful doodle — and you want full control. This tool is built exactly for that. Back when I was a Flash programmer (and also did graphic design), I loved the vector drawing workflow in the Flash IDE — especially its “lazy fill” feeling. In practice it often behaved better than many modern vector tools in situations where paths aren’t perfectly clean. Later, when Flash faded away, I worked with a painter-style program built on early SVG tech (around 2014). That’s where I hit the classic problem: filling areas formed by loosely intersecting strokes is hard. At the time I could solve it on paper, but I couldn’t implement it properly. This project is me returning to that problem — with better tooling, Rust, and a clean geometry-focused approach. The source on my github page is: rustroke github Also very handy solution to use vercel to host my app. Give instant test on other devices also after every commit. Which is happen frequently with copilot cli workflow. rustroke in action This project also came with an unexpected “environment story”. A few months ago, my workplace required me to switch from a MacBook Pro to a Windows laptop — and not a shiny new one, but a 7+ year old Dell. I still wanted to keep my UNIX-terminal-first workflow, so my first move was to install Ubuntu via WSL. After that, Windows became “Linux enough” for my daily work — while I could still run a few company-critical native apps like Teams. There’s one downside though: Ubuntu can run GUI apps through WSL, but the windowing experience clashes with Windows’ own window management. So I mostly stick to cmd as a terminal host and organize everything through split panes. On my main monitor, I keep a dedicated large panel for Copilot CLI. On the laptop display, Teams runs separately. With this setup, Copilot is always “there” — far more convenient than switching to a browser-based AI app. For me, the main advantage of Copilot CLI is that it can work directly with a folder’s context and apply changes inside the repository quickly. That makes the workflow simple: One unexpected lesson from this project was that I didn’t really use AI as a code generator — I used it as a thinking partner. I ended up with a very clear separation: This turned out to be extremely effective for this kind of project. Geometry problems are rarely about syntax errors. They are about understanding what actually happens. For example, I could describe situations like: “At this corner the algorithm should continue along the horizontal edge because the tangent changes less than the vertical one.” That is much easier to explain conceptually than by pasting 800 lines of Rust. I didn’t need to provide the full source code. Instead, I explained the behavior. We could reason about: Once the idea became clear, I translated it into a precise modification request — and Copilot CLI applied it directly to the project. So the workflow became: For algorithm-heavy software, this is surprisingly powerful. The AI wasn’t replacing development — it separated thinking from editing. And for a geometry engine, that made a huge difference. The real challenging issue was the debugging this math heavy RUST/WASM engine, which is time to time freez. So that why put the log on UI Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: wsl install ubuntu Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: wsl install ubuntu CODE_BLOCK: wsl install ubuntu COMMAND_BLOCK: # node 24 npm install -g @github/copilot copilot /login Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: # node 24 npm install -g @github/copilot copilot /login COMMAND_BLOCK: # node 24 npm install -g @github/copilot copilot /login CODE_BLOCK: copilot --allow-all-tools --allow-all-paths Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: copilot --allow-all-tools --allow-all-paths CODE_BLOCK: copilot --allow-all-tools --allow-all-paths - Draw free lines - Fill closed areas - The UI is simple HTML - The engine is Rust compiled to WASM - The core engine is view-independent, so later I can plug the same logic into other frontends and build a more serious drawing application without rewriting the geometry engine - I write a prompt about what I want changed - Copilot applies it directly in the repo - I stay in my terminal-first flow instead of context switching - ChatGPT → problem discussion - Copilot CLI → code modification - edge direction - turning angles - graph traversal rules - Discuss the visual or mathematical problem - Refine the algorithm - Write a minimal change request - Let Copilot implement it inside the repo