DEV Community: Arbab Tahir

How We Think About Content Structure While Building JustBlogged

Arbab Tahir — Fri, 07 Aug 2026 05:39:33 +0000

How We Think About Content Structure While Building JustBlogged

Most posts about building a writing platform turn into a rundown of the tech stack. This one isn't that. Instead, I want to talk about something developers usually skip over: content UX. The invisible structure that decides whether a piece of writing actually gets read, or just gets published.

Why Developers Should Care About Content UX

We're used to thinking about UX in terms of buttons, load times, and responsive layouts. But content UX. How information is structured, paced, and formatted. Is just as much an engineering problem as it is a writing one.

If you've ever built a blog, a docs site, or any tool where users create content, you've already made content UX decisions whether you realized it or not. Every default font size, every character limit, every "are you sure you want to publish?" prompt shapes how people write, not just how they read.

For developers, this matters because bad content UX creates bad content and bad content is a support burden, a retention problem, and eventually a churn problem. A writing tool that makes structure hard will produce walls of text. A tool that makes structure easy will produce content people actually finish reading.

How Writing Tools Influence Publishing Workflows

The tool shapes the output more than most people give it credit for. A few examples of how this plays out:

Friction changes behavior. If adding a heading takes three clicks, most people won't bother even if they know their post needs one. Reduce the friction, and structure becomes the default instead of the exception.
Constraints create discipline. A title field with a soft character limit nudges writers toward punchier, clearer headlines instead of vague run-on phrases.
Defaults are opinions. Whatever formatting option is easiest to reach becomes the one people use most. If your editor defaults to plain paragraphs, that's what most drafts will look like.
Feedback loops matter. Tools that show writers a live preview, a reading-time estimate, or a readability signal change decisions in real time, not after the fact.

None of this is about forcing a rigid format on writers. It's about making the good choice the easy choice.

Small Implementation Decisions That Improve the Writing Experience

While building JustBlogged, a lot of the improvements that mattered most weren't big features. They were small, almost boring decisions:

Auto-suggesting headings as a draft grows. Once a draft crosses a certain length without a heading, we nudge the writer to break it up. Small prompt, big impact on scannability.
Keeping the title field visually separate and slightly constrained. This alone pushes people toward writing sharper, more specific titles instead of full sentences.
Inline formatting instead of a separate toolbar. Reducing the number of clicks between "having a thought" and "formatting it correctly" keeps writers in flow instead of breaking their focus.
Surfacing structure, not just content, in drafts. Showing a lightweight outline of a post's headings while writing helps authors catch when a piece is unbalanced: too much intro, not enough substance, no real conclusion.
Treating whitespace as a feature, not an afterthought. Default spacing between paragraphs and sections was tuned specifically so posts don't feel dense on first glance, which is often the real reason readers bounce.

Individually, none of these decisions is impressive. Together, they add up to a meaningfully different writing experience.

Lessons Learned From Building a Platform for Creators

A few things became clear the more we worked on this:

Writers don't want more options. They want fewer decisions. Every extra formatting choice is a moment where a writer has to stop writing and start deciding. The best tools make good structural decisions on the writer's behalf by default.
Structure is a reader-facing feature, even though it's authored by the writer. Every heading, every paragraph break, every list is really a UX decision made for someone who hasn't shown up yet.
Small nudges outperform big rules. We got much better results from gentle suggestions ("this section is getting long") than from hard constraints or rigid templates.
The best content tools disappear. The goal isn't for writers to notice the tool. It's for them to notice that writing feels easier, without necessarily knowing why.

If there's one takeaway for developers building anything content-related: the code you write doesn't just render content, it shapes what content gets created in the first place. Treat that responsibility with the same care you'd give any other core UX decision.

What's a small tooling decision you've made. In a CMS, an editor, or even a README template that ended up having an outsized effect on the quality of what people wrote? Curious to hear how others have approached this.

Building an SEO-Friendly Slug Generator for JustBlogged

Arbab Tahir — Fri, 31 Jul 2026 05:45:50 +0000

When we started building JustBlogged, we noticed a small but recurring problem.

Many creators publish great content but pay very little attention to their URLs. Some platforms generate long or unclear slugs automatically, while others require users to edit them manually.

Since JustBlogged aims to simplify publishing, we decided to build a free Slug Generator that creates clean, readable, and SEO-friendly URLs in seconds.

Why Slugs Matter

A URL is often the first thing people see before opening your content.

Compare these two examples:

/post?id=48392

vs.

/how-to-start-a-tech-blog

The second immediately tells both users and search engines what the page is about.

Our Approach

We wanted the generator to:

Convert text to lowercase.
Replace spaces with hyphens.
Remove unnecessary punctuation.
Produce clean, readable URLs.
Be fast enough to update instantly while typing.

A simplified version of the logic looks like this:

function slugify(text) {
  return text
    .toLowerCase()
    .trim()
    .replace(/[^\w\s-]/g, "")
    .replace(/\s+/g, "-")
    .replace(/-+/g, "-");
}

In production, there are additional edge cases to consider, such as Unicode characters, accented letters, emojis, duplicate slugs, and reserved routes.

What We Learned

Building this feature reminded us that publishing isn't just about writing.

Small details like URL structure, readability, and workflow all contribute to a better publishing experience.

Sometimes the smallest features save the most time because they're used every single day.

Try It

If you're a blogger, developer, or content creator, you can try our free Slug Generator here:

👉 https://justblogged.com/tools/slug-generator

We're continuously improving our creator tools, so we'd love to hear your feedback and ideas for what we should build next.

Building a Real-Time Word Counter in JavaScript

Arbab Tahir — Wed, 29 Jul 2026 11:04:07 +0000

Why Build One?
Whether you are building a modern CMS, an in-browser markdown editor, or a custom blogging platform, real-time text analysis is a fundamental utility. While a basic word count might seem simple at first glance, accurately handling edge cases such as non-standard whitespace, multi-line line breaks, symbols, and reading time estimates requires a firm understanding of string manipulation and performance optimization in JavaScript.

In this guide, we will build a performant, dependency-free text metrics engine from scratch.

Counting Words Accurately
The naive approach to word counting usually looks like this:

// ❌ Naive approach - fragile!
const countWordsNaive = (text) => text.split(' ').length;

This breaks instantly if the user enters multiple spaces, newlines, or leading/trailing whitespace. A robust implementation cleans the input and uses regular expressions to isolate words.

/**
 * Accurately counts words in a string.
 * @param {string} text 
 * @returns {number}
 */
function getWordCount(text) {
  const trimmed = text.trim();
  if (!trimmed) return 0;

  // Match sequences of non-whitespace characters
  const words = trimmed.match(/\S+/g);
  return words ? words.length : 0;
}

By matching non-whitespace sequences (\S+), we automatically handle tabs, multiple spaces, and line breaks without extra sanitization steps.

Character Count
Character counts usually come in two variations: total characters (including spaces) and visible characters (excluding spaces).

/**
 * Calculates character metrics.
 * @param {string} text 
 * @returns {{ total: number, noSpaces: number }}
 */
function getCharacterCounts(text) {
  return {
    total: text.length,
    noSpaces: text.replace(/\s+/g, '').length
  };
}

Sentence Detection
Detecting sentences accurately via Regex can be tricky due to abbreviations (e.g., Dr., e.g.), but for standard prose analysis, splitting on sentence-ending punctuation (., !, ?) followed by whitespace or string end provides a solid balance of accuracy and speed.

/**
 * Estimates sentence count in a text block.
 * @param {string} text 
 * @returns {number}
 */
function getSentenceCount(text) {
  const trimmed = text.trim();
  if (!trimmed) return 0;

  // Split by '.', '!', or '?' followed by space or end of string
  const sentences = trimmed.split(/[.!?]+(?:\s+|$)/).filter(Boolean);
  return sentences.length;
}

Paragraph Detection
Paragraphs are defined by structural line breaks. We must filter out empty lines caused by consecutive presses of the Enter key.

/**
 * Counts non-empty paragraphs.
 * @param {string} text 
 * @returns {number}
 */
function getParagraphCount(text) {
  if (!text.trim()) return 0;

  // Split by one or more newlines and remove whitespace-only lines
  return text
    .split(/\n+/)
    .filter(paragraph => paragraph.trim().length > 0).length;
}

Estimating Reading Time
The average adult reads approximately 200 to 250 words per minute (WPM). We can calculate estimated reading time in minutes and format it cleanly for UI consumption.

/**
 * Calculates estimated reading time in minutes.
 * @param {number} wordCount 
 * @param {number} wpm 
 * @returns {number}
 */
function calculateReadingTime(wordCount, wpm = 225) {
  if (wordCount === 0) return 0;
  return Math.ceil(wordCount / wpm);
}

Performance Considerations
Binding text parsing directly to an input event on a large <textarea> can cause UI lag if re-computations happen on every single keystroke. To maintain a butter-smooth 60fps, use debouncing or requestAnimationFrame.

Here is a lightweight implementation using requestAnimationFrame for high-frequency DOM input:

class RealTimeTextAnalyzer {
  constructor(inputElement, callback) {
    this.inputElement = inputElement;
    this.callback = callback;
    this.ticking = false;

    this.init();
  }

  init() {
    this.inputElement.addEventListener('input', () => this.onInput());
  }

  onInput() {
    if (!this.ticking) {
      window.requestAnimationFrame(() => {
        this.analyze();
        this.ticking = false;
      });
      this.ticking = true;
    }
  }

  analyze() {
    const text = this.inputElement.value;
    const words = getWordCount(text);

    const stats = {
      words,
      characters: getCharacterCounts(text),
      sentences: getSentenceCount(text),
      paragraphs: getParagraphCount(text),
      readingTimeMin: calculateReadingTime(words)
    };

    this.callback(stats);
  }
}

Conclusion
With less than 100 lines of plain JavaScript, you can build a robust, high-performance text metrics pipeline. This logic can easily be wrapped into a React hook, Vue composable, or Web Component depending on your stack.

JustBlogged Offers a Free Word Counter For Bloggers 👇🏻

justblogged.com

Happy coding!

How Early User Feedback Changed the Way We're Building Our SaaS

Arbab Tahir — Thu, 23 Jul 2026 11:44:10 +0000

How Early User Feedback Changed the Way We're Building Our SaaS

As developers, it's easy to think the next feature is what users need.

While building JustBlogged, we discovered that wasn't the most important question.

The better question became:

"What would actually make someone leave the product they already use?"

That shifted our conversations from collecting feature requests to understanding real user problems.

We've started focusing on:

Reducing friction between writing and publishing.
Simplifying the overall experience instead of adding complexity.
Validating problems before building solutions.

One interesting lesson is that every feature has a hidden cost. Even if users never click it, they still need to recognize it, understand it, and decide whether it matters.

Keeping a product simple often requires saying "no" more than saying "yes."

We're still learning, but building in public has accelerated that learning more than any internal brainstorming session ever could.

I'm curious! What's the most valuable piece of user feedback you've received while building a product?

I Built an Open-Source Discord Bot for Developers (Code Analysis, Docs, GitHub Insights)

Arbab Tahir — Tue, 03 Feb 2026 20:01:02 +0000

I’ve been working on a Discord bot that developer communities can self-host: it analyzes code, generates docs, explains errors, and even inspects GitHub repos, all via slash commands and powered by OpenAI. I’ve open-sourced it and wanted to share what it does and how it’s built.

What it does

The bot exposes six slash commands. No need for the bot to read every message; everything is interaction-based.

/analyze-code — Paste a code snippet. You get the detected language, potential issues, refactoring ideas, and quality/security notes.
/generate-docs — Paste code and get generated documentation: what it does, parameters, return values, and usage examples.
/error-explain — Paste an error or stack trace and get a plain-language explanation plus suggested fixes.
/explain — Ask for an explanation of a concept (e.g. “async await”) at Beginner, Intermediate, or Senior level.
/github-analyze — Pass a public GitHub repo URL. You get a tech stack summary, project structure overview, and improvement suggestions.
/project-health — Same repo URL. You get recent commit activity, contributor overview, and a short “health” summary.

User activity (e.g. which commands are used) is tracked in MongoDB for a simple skill/usage view; the data stays with whoever hosts the bot.

Tech stack

Node.js + TypeScript — Typed, maintainable code.
discord.js — Slash commands and interactions; no privileged intents.
OpenAI API (gpt-3.5-turbo) — All the “understanding” and text generation.
MongoDB (Mongoose) — User and usage data for the scoring idea.

The repo includes setup guides: Discord app configuration, env vars, optional GitHub token for the repo commands, and how to run it locally or in production.

Why this structure

I wanted something that’s easy to extend: one place for command definitions, one for handlers, and separate services for GitHub, OpenAI, and user logic. New commands are just a new definition + handler + optional service. There’s an Architecture doc in the repo for contributors.

Try it or contribute

Everything is on GitHub: Discord Developer Assistant. It’s MIT licensed. The README and /docs folder cover:

Discord Developer Portal setup (which intents and permissions to enable)
Optional GitHub token for /github-analyze and /project-health
MongoDB (local or Atlas)
Build and run commands

If you run a dev community on Discord or just want to tinker with a bot that uses OpenAI and the GitHub API, feel free to clone it, open issues, or send PRs. I’d love to hear what you’d add next.