February 11, 2024

Leetpush extension popup

(Github Link)

Background and Motivation

If you’re unfamiliar with Leetcode, here’s an elucidating quote from my 7/23 post on leetcode-problem-categorization:

Leetcode is a popular platform for studying DSA (Data Structures and Algorithms), especially for coding/technical interviews, competitive programming, and education in general. It offers a growing list of problems (~2,750 as of July 2023), which can be solved directly in the browser, typically in 10-50 lines of code.

I’ve solved quite a few Leetcode problems over the past few years, and Leetcode has (at times) become a part of my daily routine. Immediately after solving problems, I always push my solutions to my leetcode-solutions repo on github. I like to say that I do this because it makes them easily accessible for future reference, but I really do it because it makes my contribution graph look like a Christmas tree1.

There are two ways2 to copy code from the leetcode website to github, and both involve way more clicks and keystrokes than I’d prefer.

Enter Leetpush.


This project is not technically challenging. Its primary difficulty lies in the logistics of tying together APIs, namely:

I used Svelte3 (a web framework) for the main popup, as its intended functionality is pretty dynamic, and would be exceedingly annoying to try to handle that in vanilla JS.

The Chrome Extension

This is the first time I’ve written a Chrome Extension; it was simpler4 than I thought.

A hello-world is just a matter of writing a manifest.json file with a hand-full of lines, e.g. (from google’s tutorial)

  "manifest_version": 3,
  "name": "Hello Extensions",
  "description": "Base Level Extension",
  "version": "1.0",
  "action": {
    "default_popup": "hello.html",
    "default_icon": "hello_extensions.png"

From there, it’s just a matter of adding “permissions”, which give your script access to the Chrome Extension API, which is pretty straight-forward given rudimentary knowledge of JavaScript and asynchronous execution.

<   }
>   },
>   "permissions": [
>     "activeTab",
>     "storage",
>     "scripting"
>   ]

The Soy-Dev Web-Dev Philosophy

Web APIs, Libraries, Frameworks and IDEs fit together quite nicely, and they all are heavily tied around one main idea: all problems are solved with more JavaScript5.

This is a double-edged sword.



It’s hard to say to what degree the above cons are avoidable, especially with the inherent complexity of the web, and the speed of innovation and change in technology, but it’s interesting to consider these flaws, their relationship to those in non-web tools, and their impact on software development and performance.

  1. As superficial as it is, I’ve found that keeping a green-streak on my contribution graph has been very effective in motivating daily coding, even beyond Leetcode (and other toy problems/exercises). “The hardest part is getting started” holds for many aspects of programming, and this routine fosters the habit of making frequent (and atomic) progress, shrinking the difficulty of starting large tasks. ↩︎

  2. (1) copy it into a file, commit that file, push; (2) copy it into the github website, commit from there. ↩︎

  3. Svelte was chosen over the alternatives because I’ve been contributing (more accurately: fixing bugs) to anki recently, and Svelte is the framework used for some of anki’s front-end. I’d like to try to better understand it so I can contribute in less-trivial ways. ↩︎

  4. The API is simple to use, not necessarily simple under the hood. ↩︎

  5. “More JavaScript”, as in “more boilerplate”, “more dependencies”, etc. ↩︎

  6. My use of “easy” and “simple” follows Rich Hickey’s definitions from “Simple Made Easy”, namely: Simple: “One fold/braid” (opposite of complex); Easy: “Near, at hand”. ↩︎