I Tried to Build My Own Markdown Editor (and Reality Hit Hard)

David Rdz-Reveles — Thu, 19 Feb 2026 04:21:39 +0000

When I started daylog back in 2024, AI wasn’t as smart as it is today. There was no “just ask the model to generate half your editor” shortcut. So I had to do most of the heavy lifting myself. And that’s when I discovered something:

Making a text editor with colors and styles is way harder than it looks.

The naive beginning

daylog is a simple note-taking web app that supports Markdown. At least, that's still the idea.

At the beginning, I thought: “How hard can it be to build a Markdown editor with syntax highlight?” Spoiler #1: very hard (for me at least).

There are basically three ways to approach this:

Use an existing library.
Use a plain textarea + preview window.
Build a fully custom editor that highlights while typing.

I didn’t want to depend on an existing library at first. I wanted control. So I started with option 2: a textarea and a preview panel.

It worked. And actually, it worked really well for my needs.

I took inspiration from the GitHub Issues and PRs editor. Simple textarea. Small toolbar. Preview below. Clean and functional.

But after using my own app for a few months, something bothered me. It felt… cheap. So I wanted more visual feedback. I wanted to instantly see bold text, headings, lists, task items, not just raw Markdown symbols. So I decided to level up.

“I’ll just build my own Markdown editor.”

Yeah. About that...

Problem #1 – The textarea wall

HTML textarea does not support partial styling.

You can change the color of everything.
But you cannot color only bold text or headings.

So I tried hacks.

Overlay a div on top of the textarea.
Hide the real content.
Use contenteditable instead.

This is the moment where things started getting messy.

Problem #2 – The cursor nightmare

Syncing the cursor between a fake highlighted layer and the real textarea is pain.

Selecting text? Broken.
Applying formatting? Misaligned.
Typing fast? Cursor jumps.

With contenteditable, now you’re manually managing selection ranges. Moving the caret. Rebuilding text nodes. Trying not to break everything.

Yes, it’s possible. But maintaining it long-term? That’s a different story.

Problem #3 – Performance reality check

Short notes? Fine.

Large documents with thousands of lines?
Running regex parsing on every keystroke? Not fine.

Input lag started appearing.

And nobody wants to type something and see the result one second later. That’s unacceptable for a writing tool. Sure, “notes” aren’t supposed to be huge. But why limit users?

At some point I had to ask myself: Am I building a note app… or am I building a code editor?

The realization

After a month of struggling, late nights, and too much coffee, I had a moment of clarity: My goal was never to build a text editor engine.

My goal was to build daylog.

So I dropped the “build everything myself” mindset and started searching for a solid Markdown editor. Spoiler #2: that wasn’t easy either.

Monaco: too powerful for its own good

I remembered Monaco, the core editor behind Visual Studio Code. Sounds perfect, right?

Well…

Easy to integrate at first.
Extremely heavy for a simple note app.
Hard to customize with normal CSS.
Mobile support? Not great.
Cursor and keyboard behavior on mobile? Painful.

Monaco is amazing. But it was overkill for daylog... So I moved on.

The search

I explored several options:

CodeMirror – lighter than Monaco, still powerful.
MDXEditor – powerful but harder to learn.
react-simple-code-editor – simple, but not actively maintained.
@uiw/react-md-editor – and this one felt different.

The winner: @uiw/react-md-editor

What I liked about it:

Easy to implement.
Configurable.
Based on textarea encapsulation.
No heavy code editor engine.
Supports Mermaid, KaTeX, and GitHub flavored markdown.
Can be styled with CSS overrides.

It felt aligned with my original idea!.

When I integrated it into daylog and applied some custom CSS tweaks, everything finally clicked.

The editor looked good.
It felt responsive.
It fit the purpose of the app.

And most importantly, I could move forward with the other planned features, and share it here in dev.to ofc!

What I learned

Maybe I gave up too early on building my own editor... Maybe not.

Would it have been a great learning experience? Definitely.

Was it aligned with my product goal? Not really.

Sometimes building everything from scratch is ego.
Sometimes it’s learning.
Sometimes it’s just unnecessary suffering... (in my case).

If you were in my position, what would you have done?
Have you ever gone too deep into building something that wasn’t actually your main product?

I’d love to hear your story.

If you want to see the code, you can check the daylog repository:
https://github.com/artifacts-oss/daylog

I Built an Open Source Markdown Note-Taking Web App and Am Sharing It with You

David Rdz-Reveles — Tue, 20 Jan 2026 14:00:00 +0000

Hi devs!

I'm excited to share my first open-source project with you called daylog. It is a web app for taking notes with Markdown.

Why another note-taking app?

I initially created daylog to solve my own needs and for fun; as a former Notion user, I realized that I didn't need all the complexity and advanced features for my personal, informal notes. Also I got a little bored with the tree view menus...

I'm a very visual person and a Jira power user, so I wanted to mix both worlds: cards, boards and notes. Basically, in daylog, I can set an image as a cover for a board so I can identify my boards easily without even reading the title. The same applies to notes. However, using an image is optional; you can also let daylog generate a random color based on the title.

Why markdown?

As I mention before, I like to work with Jira or any Kanban style app, but also as developer with some touch typing skills, sometimes I prefer to go full keyboard rather than clicking or dragging and dropping components with a mouse. That's why daylog has both options in the note editor: you can go full keyboard or use the text styling toolbar when creating your notes.

That’s not all! I’ve integrated some security features and 3rd-party integrations you might like:

Two-Factor Authentication (2FA)
S3 Storage (for images)
Unsplash support (requires your own API key)
Fully responsive and PWA (ready to install on desktop and mobile)

What’s planned for the future?

As soon as possible, depending on my free time, I have some cool features and enhancements in mind, such as:

Improve keyboard navigation
Public and private sharing
Note encryption
Search enhancements
User wiki/documentation
File attachments
Changes history with undo or redo
Unsplash component also in note editor
Cool visual features to customize and organize boards easily

What about AI?

Maybe I'll integrate some AI specifically in the searching component in the future... but I don't have plans to integrate AI for note creation. Daylog is intended to let your brain decide what to write, without all the AI noise.

What did I learn?

A lot. Working on this "simple" project has inspired me to learn more about the concepts we use every day in software development projects. These concepts include GitHub Actions, Docker (and Docker Compose), semantic versioning, security advisories, README files, licensing, and other topics, such as failing to create a Markdown editor from scratch and finding a good Markdown editor project without losing my mind. I'll share my thoughts and lessons learned about these topics in future posts.

At this moment feel free to review the code and use daylog. PRs are also welcome! ;).
Go to daylog repository

DEV Community: David Rdz-Reveles