DEV Community: Devananth A

Building GitLocalize: How an Obsession with "Reducing Friction" Saved 2 Minutes of Load Time

Devananth A — Tue, 17 Mar 2026 02:32:32 +0000

Welcome to my Lingo.dev hackathon journey! Over the past week, I set out to build something cool using the Lingo API. What started as a vague idea transformed into a high-performance translation pipeline. Let’s look at what I built, how I built it, and the roadblocks I slammed into along the way.

The Brainstorming Phase

When the hackathon was announced, my first thought was the path of least resistance: “I’ll just build a production-grade app and slap a layer of Lingo localization on top.” But as I thought about it, that didn't solve a real, bleeding-neck pain point. While browsing GitHub, I noticed a very real problem: many amazing open-source repositories have their READMEs written entirely in their native language (like Chinese, Spanish, or Japanese). When developers try to read them, they copy-paste the text into Google Translate.

The result? Absolute chaos. Google Translate breaks the code blocks, turns terminal commands into literal verbs, and destroys the context of the markdown formatting.

"Ideas don't come fully formed, they refine by building them." — Mark Zuckerberg

This quote resonated with me. I had a problem to solve. Lingo.dev’s API natively protects Markdown syntax. So, I decided to build a web app—mostly because I already know React—that takes a README and translates it cleanly using the Lingo API.

Idea -> App -> Chrome Extension : Reduce friction

Almost immediately after deciding to build a web app, I realized a fatal flaw.

To use my app, a developer would have to open a new tab, go to my site, copy a massive README from GitHub, paste it, translate it, and read it completely out of context. That creates a massive amount of friction.

As a senior developer once told me: “If you can reduce the friction for the user, then you have a good product. Solve something in an easy way.”

How could I reduce the friction to zero? A Chrome extension. If I could put a "Translate" button directly on the GitHub repository page, the user could translate the docs without ever leaving the site.

Building the Chrome Extension

I had never built a Chrome Extension before, so I dove headfirst into the official Chrome Developer docs (with googling and with the help from ChatGPT, of course).

I implemented the frontend of the extension, injected a slick UI button onto the GitHub DOM, and wired up the Lingo API to fire when the user clicked it.

Boom! I clicked the button... and it failed.

Or rather, it took so incredibly long that the browser basically gave up.

I quickly learned a hard lesson: doing heavy-lifting API calls and data processing directly in the frontend extension is a terrible idea.

Creating the Backend

To reduce the friction on the browser, I decided to offload the heavy lifting. I spun up a separate Node.js backend using Express and the Lingo.dev SDK to handle the actual computations.

I wired the extension to send the raw markdown to my new backend. I tested it on a few small README files, and it worked flawlessly. The markdown stayed perfectly intact, and the translation was spot on. I felt like I had already won.

And then, I decided to stress-test it on calcom/cal.com.

I clicked translate. The button went into a loading state... for roughly two minutes. I honestly thought my server crashed or the code broke somewhere. I added some performance timers and ran it again.

It took 170.05 seconds. That is nearly three minutes. You cannot make a user wait that long. It completely defeated my entire philosophy of reducing friction.

The Optimization: Beating the 170-Second Nightmare

I started debugging the bottleneck. The Cal.com README is massive—over 15,000 characters. I realized that the standard "send and wait" approach (sending one giant payload to an LLM) was choking the API.

I asked myself: Why don't we break the file apart, send the pieces in parallel, and stitch them back together?

I researched the feasibility of this approach and dug into API rate limits. Here is the high-performance architecture I ended up building:

Intelligent Chunking: Instead of splitting the text at random character counts (which breaks sentences), we split the Markdown using the delimiter \n\n (double newlines). This ensures each "chunk" is a collection of complete paragraphs, preserving semantic context.
The Bucket System: We set a limit of 5,000 characters. The backend adds paragraphs to a "bucket" until the next paragraph would exceed the limit. Then, it starts a new bucket.
The Parallelism Problem: If you send all the chunks sequentially, it takes forever. If you send them in parallel, 10 chunks take roughly 10 seconds (the time of the single longest request).
Controlled Concurrency: Pure parallelism carries a massive risk. If we fire 100 requests at once, the API thinks it's a DDoS attack and blocks us with an HTTP 429 Rate Limit error. I solved this by implementing a Semaphore pattern using p-limit. This keeps exactly 10 requests processing at any given time, keeping the pipeline full without overwhelming the server.

I pushed the new code and hit translate on Cal.com again.

It took 30 to 40 seconds. By utilizing controlled concurrency, I shaved over two minutes off the processing time. The speed difference was staggering.

Future Scopes

GitLocalize is live and working, but ideas keep refining. Here is what is next for the project:

Token Optimization: Currently, we send code blocks to the API. To save Lingo credits and speed up processing, I plan to use Regex to strip code blocks before translation, and merge them back into the document afterward.
PR & Issue Translation: Expanding the extension to automatically translate discussions and code reviews inside GitHub Pull Requests.
Offline Persistence: Allowing users to export and download the translated .md files directly to their machines.
Auto-Language Detection: Reading the browser's headers to auto-translate repos without the user ever clicking a button.

Check it out!

You can view the full source code and try the extension yourself here:
https://github.com/devananth/GitLocalize

Demo:

Thanks Note: A huge thank you to the organizers of the Lingo.dev hackathon. Building this forced me to dive deep into concurrent Node.js architectures and Chrome Extension manifests. It was a phenomenal learning experience. Happy shipping!

Building an Office with 900+ Lines of CSS: My Frontend Challenge Journey

Devananth A — Mon, 28 Jul 2025 05:46:18 +0000

This is a submission for Frontend Challenge: Office Edition sponsored by Axero, CSS Art: Office Culture.

Inspiration

For this CSS Art challenge, I wanted to step out of my comfort zone. While I've used CSS extensively for web apps and websites, I had never built an art piece purely with CSS. I started by diving into codepen and other inspiration sites, getting a feel for what was possible. Eventually, a rough sketch of an office atmosphere in Excalidraw became my guiding vision. My goal was to depict a typical office scene, complete with everyday elements and subtle animations.

Rough sketch:

Eventually, after starting to build, I got ideas for adding a few more elements.

Demo

Note: For the best experience, please **view in a web browser.

Live link of my CSS Art: CSS Art

Source code: Github repo

Video demo: video demo

A closer look: 19 elements in the CSS Office

Journey

My journey into CSS Art was both challenging and incredibly rewarding. Initially, seeing the intricate works on codepen was a bit overwhelming. I wondered how I could ever achieve something similar. The breakthrough came when I decided to break down the entire office atmosphere into smaller, manageable elements: a clock, an AC unit, a chair, a desk, a coffee cup, and so on.

I started building each piece one by one. Honestly, it looked quite clumsy at first! But as I began adding colors and meticulously positioning each element, the entire scene started to come together beautifully. It reminded me of Mark Zuckerberg's famous quote,

Ideas do not come fully formed; they develop as you build.

That's exactly what happened here. With each element I added, new ideas sparked – a printer, a plant, wall posters – I kept integrating them, ensuring I utilized the entire viewport effectively.

Finally, to truly bring the scene to life and add an interactive touch, I incorporated some delightful animations. These weren't just for show; they add a layer of realism and engagement:

Hovering over the coffee cup reveals subtle steam, giving it a fresh-brewed feel.
Mousing over the sticky notes makes them gently zoom, inviting a closer look.
Interacting with the lights dynamically changes their color, simulating different moods or states.
I also added other subtle animations to give a realistic touch to the printer, books.

I heavily relied on several key CSS properties and techniques:

Gradients for the window background, adding depth and light.
box-shadow to create a realistic sense of dimension and depth for various objects.
clip-path, which I used for the first time, was a game-changer for creating precise light rays.
Pseudo-elements like ::after and ::before proved invaluable for adding intricate details without cluttering the HTML.
position property made easier to fix things in thier places by adjusting top, left, bottom and right.
And, of course, Flexbox was essential for efficient layout and positioning of elements.

The first major challenge was making the entire piece aesthetically pleasing. Being quite particular about colors, I aimed for a minimal and clean palette. The next hurdle was making each element appear at least somewhat realistic with CSS alone. Overcoming these challenges taught me so much, especially the power and versatility of pseudo-elements and the practical application of clip-path.

I'm incredibly proud of this entire project. I never imagined I would write over 900 lines of pure CSS code for an art piece! It's a testament to what can be achieved with dedication and a touch of creativity.

For future projects, I'd love to explore more about animations and push the limits of realism even further with CSS.

This was a solo effort – just me, diving into the fascinating world of CSS Art!

Thank you for exploring my CSS Art: Office Edition!. This project was a big learning experience, and I'm excited to have taken part in the Axero & DEV Community Frontend Challenge.

Feel free to check out the code on GitHub and revisit the live demo here to experience the interactive elements yourself!"