DEV Community: Spartan Rich

How to Implement Spaced Repetition (SM-2) in JavaScript

Spartan Rich — Fri, 23 Oct 2026 11:32:01 +0000

I spent a weekend convinced I could write a better review scheduler than the one Piotr Wozniak published in 1987. I couldn't. What I ended up with was a cleaner understanding of SM-2, the algorithm behind SuperMemo and, for most of its life, Anki. If you're adding any kind of "review this later" feature to an app, it's the place to start.

This post walks through SM-2 in plain JavaScript, points out the parts that trip people up, and covers what I'd change before shipping it to real users.

The idea in one paragraph

Hermann Ebbinghaus measured his own forgetting in the 1880s and found that memory drops fast after you learn something, then levels off. Each time you successfully recall it, the drop gets slower. Spaced repetition takes advantage of that: review an item right before you'd forget it, and push the next review further out every time you get it right. SM-2 is a small set of rules for deciding how far out "further" is.

What each card needs to store

Every item you schedule carries three numbers:

repetitions: how many times in a row it's been recalled correctly
interval: days until the next review
easeFactor: how quickly the interval grows, starting at 2.5

Plus a due date, which you calculate from the interval.

After each review the user grades their recall from 0 to 5. In the original paper 5 means perfect recall, 3 means correct but hard, and anything below 3 counts as a failure.

The code

function sm2(card, quality) {
  let { repetitions, interval, easeFactor } = card;

  if (quality >= 3) {
    if (repetitions === 0) {
      interval = 1;
    } else if (repetitions === 1) {
      interval = 6;
    } else {
      interval = Math.round(interval * easeFactor);
    }
    repetitions += 1;
  } else {
    repetitions = 0;
    interval = 1;
  }

  easeFactor =
    easeFactor + (0.1 - (5 - quality) * (0.08 + (5 - quality) * 0.02));
  if (easeFactor < 1.3) easeFactor = 1.3;

  const due = new Date();
  due.setDate(due.getDate() + interval);

  return { repetitions, interval, easeFactor, due };
}

const fresh = { repetitions: 0, interval: 0, easeFactor: 2.5 };
let card = sm2(fresh, 4); // due tomorrow
card = sm2(card, 4);      // due in 6 days
card = sm2(card, 5);      // due in about 15 days

That's the whole algorithm. Twenty-odd lines.

The ease factor formula, decoded

The ease update looks like line noise, so plug in numbers. A grade of 5 adds 0.1. A grade of 4 adds nothing. A 3 subtracts 0.14. A 0 subtracts 0.8, though the floor of 1.3 stops it from going lower than that.

So a card you keep finding hard grows its interval slowly, around 1.3x per review at worst. A card you always nail grows faster and faster. The 1.3 floor matters more than it looks. Without it, a card you failed a few times would end up with an ease near zero and get shown to you every day forever.

Three things that bite you in production

Grades. Nobody wants six buttons. Anki settled on four (Again, Hard, Good, Easy), and most apps go even simpler. If you map "Again / Good / Easy" onto 1 / 4 / 5, the algorithm still behaves sensibly. I'd avoid letting users pick 0 through 5 directly. They'll use 3 and 5 and nothing in between.

Late reviews. SM-2 assumes people review on the due date. They don't. If a card was due 10 days ago and the user still remembers it, that's a stronger signal than an on-time success, but plain SM-2 ignores it. A common patch is to compute the next interval from the actual days elapsed instead of the scheduled interval when the answer is correct. Small change, much better behaviour for people who go on holiday.

Timezones. I set due with setDate above to keep the demo short. In a real app, store due dates as calendar days in the user's timezone, or someone in Kolkata will get tomorrow's cards at 5:30 in the morning and wonder what broke. I've shipped that bug. It's embarrassing.

Is SM-2 still worth using?

For a side project or an MVP, yes. It's predictable, it's easy to debug, and you can explain it to a user in two sentences.

It isn't state of the art anymore, though. Anki added FSRS (Free Spaced Repetition Scheduler) as an option in version 23.10. It fits a memory model to each user's actual review history instead of using fixed constants. If your app ends up with lots of review data per user, FSRS is worth a look. If you're starting from zero data, SM-2 gets you shipping this week.

The harder problem sits upstream of the scheduler

The scheduler turned out to be the easy part. The hard part was deciding what to put on the card in the first place.

Most of what I want to remember doesn't arrive as flashcards. It comes from a YouTube talk, a podcast episode, a long article, a reel someone sent me. Turning a 40-minute video into three or four reviewable ideas is real work, and most people (me included) never do it. So the videos sit in Watch Later and the scheduler has nothing to schedule.

That's the gap Recl is built around. You save videos, reels, podcasts or articles, it summarizes them, sorts them into topics, and then uses spaced repetition to bring the key points back before they fade. The scheduling logic is the same family of ideas as the code above. The difference is that the cards come from what you already consume, so you don't have to write them yourself.

A saved article turned into a short summary card in Recl's feed.

If you're building something similar, my advice is to spend less time tuning the interval math and more time on getting content into the system with as little friction as possible. A perfect scheduler with an empty queue helps nobody.

Try it yourself

Copy the function above, make a dozen cards from something you read this week, and grade yourself honestly for two weeks. You'll get a feel for the intervals faster than from any paper. And if you'd rather the cards wrote themselves from the stuff you save, give Recl a try.

I'm Spartan Rich, and I build Recl, an AI learning app that turns saved videos, podcasts and articles into summaries and spaced-repetition reviews.

Building an AI Summarizer and Spaced-Repetition App: Lessons Learned

Spartan Rich — Thu, 22 Oct 2026 07:43:02 +0000

Product and engineering lessons from making saved videos, podcasts and articles actually stick, without the hype.

I build Recl, an app that takes the videos, reels, podcasts and articles you save, summarizes them with timestamps, sorts them into topics, and uses spaced repetition to bring the key ideas back before you forget them.

You won't find architecture diagrams here. Stacks and models change; the decisions above the code have mattered more. These are the lessons I'd pass on to anyone building AI learning tools, a few of which I learned the slow way.

1. A summary nobody can verify is a summary nobody trusts

The first instinct with an LLM summarizer is to make the output clean and confident: a tidy paragraph, five neat bullets.

But users can't tell a correct bullet from a slightly wrong one. For learning content, slightly wrong is worse than nothing, because people will remember it and repeat it.

Timestamps fixed that. When every key point links back to the moment it came from, the summary turns into an index. If something looks off, you tap it and hear the original. That choice did more for trust than any amount of prompt tuning.

So treat summaries as a way into the source, and show provenance wherever you can.

2. Nobody actually wants the summary

It's easy to think the product is the summary. Nobody wakes up wanting a summary of a podcast they've already half-listened to. They want to remember the part that mattered.

That changes what you generate. Review material needs one idea per item, so it can be recalled on its own, and it needs to be phrased so the user can check whether they really know it. It also has to be worth keeping. Most sentences in a video don't deserve a slot in someone's long-term memory.

That last requirement is the hard one. Generating more is easy. Choosing less is where the work is, and it's mostly a product problem. A better model won't solve it for you.

3. Spaced repetition was built for flashcards

Spaced repetition has decades of research behind it: review at growing intervals, and make each review an act of retrieval instead of rereading. Classic implementations assume the user wrote the cards and chose to sit down for a study session.

Saved content breaks both. The user tapped "save" while scrolling and never planned to study. A few things follow.

Reviews have to be short. If a review feels like homework, people skip it, and a skipped review counts for nothing.

The schedule has to forgive. People miss days, and a system that answers with a giant backlog teaches them to stop opening the app.

Context matters at review time too. A bare question pulled from a podcast can feel disconnected; a pointer back to the timestamp helps people re-anchor.

Keep the core of spaced repetition (growing gaps, active recall) and redesign everything around it for people who never signed up to "study."

4. Capture friction is the whole funnel

The smartest review engine in the world does nothing for content that never got saved into it.

One-tap save: Recl reads the video and pulls out the key ideas in the background.

Every extra tap between "this is interesting" and "this is saved" loses people. That's why one-tap saving mattered so much, and why Recl started on Android, the web and a Chrome extension, with iPhone coming soon. Meeting people inside the apps and browser they already use beats asking them to copy links into a new place.

Count the steps to capture and fight for every one. It's unglamorous work that pays off.

5. Organization should be automatic and legible

People want everything organized without doing the organizing. Automatic topic sorting solves that, with a catch: if the system files things in ways the user doesn't understand, they stop trusting the topics and fall back to scrolling a flat list.

Topics view: saves grouped into topics automatically.

Keeping topics legible helps. Give them plain names, and make it visible why an item landed where it did. A view of how topics relate to one another helps as well; in Recl that's the knowledge graph. Done well, it also shows users how much they've saved on one subject compared to another.

6. Q&A over personal content has to stay grounded

"Ask your saved content" sounds simple until you hit the edges. When the answer isn't in what the user saved, the right response is to say so. Filling the gap with general knowledge that looks like it came from their library is worse than no answer.

Ask: questions answered from your own saves, with links back to the sources.

Answers that point back to sources keep the feature honest. Add semantic search, so people can find things by meaning when they've forgotten the exact words, and you cover most of the "I know I saved something about this" moments.

In a personal knowledge tool, "I couldn't find that in your saves" belongs on the feature list.

7. Freemium forces clarity

A free tier makes you decide what the core loop is. For Recl it's save, understand, remember. That loop has to be useful for free, or nobody sticks around long enough to care about anything else. It's a helpful constraint.

What have you run into building in this space, especially around review scheduling? Leave your lessons in the comments.

About the author

Spartan Rich is the maker of Recl, an AI learning app that summarizes saved videos, reels, podcasts and articles with timestamps and uses spaced repetition to help you remember them. Available on Android, web and Chrome, with iPhone coming soon.