DEV Community: Srinivas Gowda

Typing in a 5,000-row table took 26 seconds per key. Here's how I got it to 24 ms.

Srinivas Gowda — Mon, 02 Nov 2026 20:30:38 +0000

Sarala is a free, open-source Markdown editor where the page you write is the page you read. There's no preview pane. Click a paragraph to edit its Markdown, click away and it renders in place.

It started as a desktop app built with Tauri and SolidJS, and it now runs in the browser too.

When I brought it to the browser, I benchmarked large files for the first time. Normal documents were fine. A 20,000-line document with thousands of paragraphs typed at about 14 ms per key.

Then I tried a single huge block:

Document	Delay per key
Table, 5,000 rows	26,028 ms
List, 20,000 items	4,401 ms
Paragraph, 20,000 lines	681 ms
Code block, 20,000 lines	128 ms

That's a 26-second wait for one letter.

Why windowing didn't save me

The editor already renders only the blocks near the viewport, so long documents stay light. But it does that per block. One giant table is one block, so it's always fully rendered.

The block you're editing was also rebuilt from scratch on every keystroke: parse the Markdown, replace its innerHTML, then walk every node to restore the caret.

The clue in the profiler

My first profile didn't add up. Three keys took about 1.9 seconds, but JavaScript accounted for only around 500 ms. The rest was the browser laying out the rebuilt block again.

So a faster parser wouldn't be enough. The fix had to stop touching the DOM.

Three separate bugs

A table component measuring everything. A row-reordering overlay re-measured every row on each keystroke, and its cost climbed quickly as the table grew.

A quadratic token walk. marked.walkTokens builds its result by repeatedly concatenating arrays. On a 20,000-item list, that cost 2.6 seconds, and nothing in my code read the result. A small linear walker took opening that list from 2.8 s to 0.4 s.

Slicing the rest of the document per character. Mapping a click to a source offset called source.slice(i) and ran an unanchored regex for every character. Clicking into a 1 MB block took 7.8 seconds. Each pattern can only match at its own first character, so it now checks that first.

Editing one line at a time

The big change: a very long block now edits as plain lines while it's active. Each source line is its own <span>, so the text content stays byte-identical to the Markdown.

When you type, the browser has already put the character on screen, so I don't redraw anything. The new text is spliced from the one edited line, with a length check that falls back to reading the DOM if anything looks wrong. Structural edits like Enter or paste patch only the lines that changed. When you click away, the block renders normally.

Browsers fought back

My first version used block-level line boxes, which made layout cheap. Then tests caught ArrowUp jumping to the top of the block in Chrome and WebKit. Inline spans behaved correctly in all three engines and cost almost nothing extra.

Tests also caught the End key doing nothing from the start of a line, and a native delete across two lines removing the wrong newlines. Speed is worthless if editing is wrong, so edits that cross a line now go through the source text.

The result

Document	Before	After
Table, 5,000 rows	26,028 ms	24 ms
List, 20,000 items	4,401 ms	69 ms
Paragraph, 20,000 lines	681 ms	45 ms
Code block, 20,000 lines	128 ms	34 ms

The trade-off is real: while you edit a very long block, you see Markdown rather than the styled view, and the app tells you so. A 20,000-item list still costs more than a frame, nearly all of it inside the browser's own editing code.

What I'd pass on: measure what the browser does, not only your JavaScript. And write the correctness tests before you trust the benchmark.

A quick tour

Here's the rest of what the editor does. These screenshots are from the desktop app for macOS, Windows and Linux.

The live editor. One page for writing and reading, with no split view.

Diagrams. Mermaid and D2 render right in the page.

Math. LaTeX typeset with KaTeX as you write.

Code. Syntax highlighting for more than 100 languages, in your theme.

Tables, tasks and callouts. Edit tables cell by cell and tick tasks with a click.

AI assistant, desktop only. It runs the coding agents on your own machine, and you approve each edit as a diff.

Voice typing. Dictation runs on your device.

Command palette. Every action is one Cmd/Ctrl+K away.

Themes. Thirteen built in, or bring your own base16 scheme.

On your phone. The browser version works there too, with a formatting bar above the keyboard.

Try it

The browser version needs no install and no account, and your documents stay on your device: https://web.sarala.solancer.com

Desktop apps for macOS, Windows and Linux: https://sarala.solancer.com

The source is on GitHub: https://github.com/solancer/sarala

I'd love to hear what breaks.

Mastering AWS Cognito: The Ultimate Guide to User Attributes

Srinivas Gowda — Thu, 07 Sep 2023 22:20:30 +0000

Ah, AWS Cognito! The managed authentication provider that promises a smooth sailing journey, but occasionally feels more like you're navigating the Bermuda Triangle.

If you're a developer wading through the Cognito waters, you might relate to the urge to use your keyboard as a frisbee.

Here's a glimpse into my roller-coaster ride with AWS Cognito, and how I made it through.

Prologue: The Simple Path Often Forgotten

Before we venture into the murky waters, here's a golden nugget of advice: Always store the Cognito Username (which is essentially the Cognito ID) whenever you create or fetch a user. This unassuming string can be your magical key to bypass a lot of headaches. With this, updating user attributes is straightforward:

async function directUpdateUsingUsername(username: string, attributes: any) {
    await cognito.adminUpdateUserAttributes({
        UserPoolId: process.env.COGNITO_USER_POOL_ID,
        Username: username,
        UserAttributes: attributes
    });
}

On the frontend, you can easily get this using getCurrentUser. Keep this in your arsenal.

1. The Basics: Updating User Attributes

Setting user attributes in Cognito without knowing it's username is like trying to convince a cat to take a bath. It's possible, but be prepared for some resistance.

import { CognitoIdentityProvider } from "@aws-sdk/client-cognito-identity-provider";

const cognito = new CognitoIdentityProvider({
    region: process.env.AWS_REGION
});

async function updateUserAttributes(username: string, attributes: any) {
    await cognito.adminUpdateUserAttributes({
        UserPoolId: process.env.COGNITO_USER_POOL_ID,
        Username: username,
        UserAttributes: attributes
    });
}

Note: Remember to handle any errors gracefully. Cognito can be... prickly.

2. Finding Nemo: Search by Email (or other standard attributes)

You may not know a user's Cognito ID, but you might have their email! Here's how you embark on your quest to find them:

async function findUserByEmail(email: string) {
    const users = await cognito.listUsers({
        UserPoolId: process.env.COGNITO_USER_POOL_ID,
        Filter: `email = "${email}"`,
        Limit: 1
    });

    if (users && users.Users && users.Users.length > 0) {
        return users.Users[0];
    }
    throw new Error("User not found!");
}

3. The Disappointment: Custom Attributes Aren't Searchable! 😭

One might think, "Oh, I have this custom:unicornAttribute. I can just search by that!" But no, Cognito thwarts us once again. Thought you could search by custom:myFavoriteColor? Cognito laughs at our naive optimism. Custom attributes are like the secret menu at your favorite cafe: they exist, but you can't just order from them directly.

4. Iterative Search: When All Else Fails...

If you're desperate to find a user by a custom attribute, there's an (inefficient) way: List all users and search them client-side. (Do this only if you're feeling brave and have and now other way)

async function findUserByCustomAttribute(attributeName: string, value: string) {
    let paginationToken;
    do {
        const result = await cognito.listUsers({
            UserPoolId: process.env.COGNITO_USER_POOL_ID,
            PaginationToken: paginationToken
        });

        for (const user of result.Users) {
            for (const attr of user.Attributes) {
                if (attr.Name === attributeName && attr.Value === value) {
                    return user;
                }
            }
        }

        paginationToken = result.PaginationToken;
    } while (paginationToken);

    throw new Error("User not found!");
}

In Conclusion:

AWS Cognito, with its quirks and idiosyncrasies, can be a beast to tame. But with a sprinkle of patience, a dash of humor, and maybe a glass of wine (or two), you can conquer it!

React useEffect Gotcha's

Srinivas Gowda — Thu, 16 Mar 2023 22:35:31 +0000

React useEffect is a powerful and commonly used hook that allows you to perform side effects in your functional components. However, it can also lead to some issues if not used correctly.

Here are some of the commonly known issues with useEffect hook.

Infinite Loops

One common issue is the use of infinite loops. If your useEffect hook is not correctly set up, it can trigger a state update that causes a re-render, which triggers the useEffect hook again. This can create an infinite loop and cause your application to crash or slow down significantly.
In this example, we have a component with a state variable count. The useEffect hook is set up to run whenever the count state variable changes. However, inside the useEffect hook, we update the count state variable, causing the effect to run again and creating an infinite loop.

import React, { useState, useEffect } from 'react';

function InfiniteLoop() {

 const [count, setCount] = useState(0);
    useEffect(() => {
     setCount(count + 1); // This will trigger the useEffect hook, causing an infinite loop
    }, [count]);

  return (
     <div>
       <h1>Count: {count}</h1>
     </div>
   );
}

To avoid infinite loops, you must ensure your useEffect hook has the correct dependencies. Dependencies are the variables or state values that the useEffect hook relies on. If any of these dependencies change, the useEffect hook will be re-triggered.

Race Conditions

Another issue with useEffect is the possibility of race conditions. If your component has multiple useEffect hooks that rely on the same data or API, they can trigger at different times and cause unpredictable behavior. To avoid race conditions, you need to make sure that your useEffect hooks are appropriately ordered and that they don't conflict with each other.
In this example, a component fetches data from an API and renders it to the page. However, the code has a race condition because the isLoading state variable is not set until after the data has been fetched. This means the component will render before the data has finished loading, leading to errors or unexpected behavior.

import React, { useState, useEffect } from 'react';

function RaceCondition() {
 const [data, setData] = useState(null);
 const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
   fetch('https://example.com/data')
   .then((response) => response.json())
   .then((jsonData) => setData(jsonData))
   .then(() => setIsLoading(false))
   }, []);

    if (isLoading) {
         return <div>Loading…</div>;
   }
    return (
   <div>
       {data.map((item) => (
           <div key={item.id}>{item.name}</div>
       ))}
   </div>
 );
}

Misuse of Cleanup Functions

A common issue with useEffect is the misuse of cleanup functions. A cleanup function is a function that runs when the component unmounts or when the dependencies change. Cleanup functions can lead to memory leaks and other issues if not correctly used.
In this example, a component sets a timer to update a state variable after 5 seconds. However, the cleanup function is misused because it is set up to clear the timeout on every re-render, even though it only needs to run once when the component is unmounted. This can lead to unnecessary work being done and potential bugs in the code.

import React, { useState, useEffect } from "react";

function CleanupFunction() {
  const [isVisible, setIsVisible] = useState(false);
  useEffect(() => {
    const timerId = setTimeout(() => {
      setIsVisible(true);
    }, 5000);
    // Misuse of cleanup function: this will clear the timeout on every re-render
    return () => {
      clearTimeout(timerId);
    };
  }, []);
  return <div>{isVisible ? <h1>Visible!</h1> : <h1>Not visible yet…</h1>}</div>;
}

To avoid cleanup function issues, ensure that your useEffect hook returns a cleanup function if necessary. The cleanup function should remove any event listeners, timers, or other resources created in the useEffect hook. This will prevent memory leaks and ensure your component is appropriately cleaned.
In summary, useEffect is a powerful hook that can help you manage side effects in your React components. However, to avoid issues like infinite loops, race conditions, and cleanup function problems, you must ensure that your useEffect hooks are adequately set up with the correct dependencies, ordering, and cleanup functions.

A digital platform that connects those in need to those who can help during COVID 19

Srinivas Gowda — Wed, 29 Apr 2020 20:49:32 +0000

In the light of recent events and the decision to extend the lockdown, I and my colleague Karthik wanted to build a platform to help the people affected by the pandemic, someplace where their grievances could be voiced to volunteers who could help.

This started as an idea over zoom catchups, post our daily office standup meetings, but soon we decided to give it a go and started conceptualizing the idea with one of our friends, Atul who was willing to help with the design.

It took us a month of our spare time, mostly over the weekends to put together the first version of the web app, that's when we realized we will need sponsorships from companies to get the project running. Thankfully, we received free credit grants from companies like Twilio, Digital Ocean, and MongoDB to get started. These grants were quite generous and got us this far to launch it for public use.

We built a full stack solution using NodeJS, MongoDB & VueJS. Integrated it with Mailgun for Email alerts and Twilio for SMS and Whatsapp alerts.
Adding to this we also developed a Whatsapp bot that helps people post aid requests with location and contact details and for volunteers and NGO organizations to check for any aid requests from zip code and location.

Furthermore, we went ahead and open-sourced the platform on Github to help other regions of the world to address the crisis.
We have launched this for India and will launch for the USA too.

What is Happening

COVID 19 has let to disruption across economic strata. Millions in underprivileged regions face penury and deprivation as economic activity grinds to a halt due to lockdown. The movement restrictions will prove economically devastating for India's poor, who live in its vast rural areas. The United Nations' 2019 Multidimensional Poverty Index (MPI), a holistic measure of poverty that looks at deprivation through the lens of nutrition, health indicators, schooling, sanitation, and access to essential amenities puts the number of poor in India at 36 million.
The government announced a $22.50bn relief package to help the poor to cope with the loss of income during the lockdown. These were supposed to be emergency measures but sadly India's system: weak, are not able to deliver these benefits to the needy in time.These were supposed to be emergency measures but sadly India's system: weak, are not able to deliver these benefits to the needy in time

The current scenario

Paytm, Lifeboy, PharmEasy, Razorpay, Zomato, SAFA, #IndiaFightsCoronaVirus, COVID-19 fundraisers on crowdfunding platforms, Google Pay, Goonj/CMRF, Prime Minister's Relief Fund and many more are doing their part by contributing in one way or another. Still, there are so many heartbreaking cases we come across every day and so many more stay untold & undiscovered. Even with all these initiatives, it's impossible to locate and help in a population of 136 billion. People and animals continue to suffer.

Our Solution

Demo Link

https://www.quarantineaid.in

Category Submission: COVID-19 Communications
Signed the Twilio challenge agreement from: https://github.com/solancer

Link to Code

Frontend: https://github.com/quarantineaid/quarantineaid-frontend
Backend: https://github.com/quarantineaid/quarantineaid-backend

Tech Stack

Backend: Node.js web server using Express + MongoDB + DigitalOcean Spaces + Redis

Frontend: VueJS + Vuex + OpenStreet Maps + SASS

Integration: Programmable SMS Twilio API + Twilio API for WhatsApp

Deployed with DigitalOcean. You can check out the live application here or the live API here https://www.quarantineaid.in