From 4d75ae441ff7069a77af0da0b576dcccd2ffbd92 Mon Sep 17 00:00:00 2001 From: John Jeong Date: Tue, 25 Nov 2025 22:53:51 +0900 Subject: [PATCH 1/2] docs(article): add metadata for IDE writing article --- apps/web/content/articles/using-ide-for-writing.mdx | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 apps/web/content/articles/using-ide-for-writing.mdx diff --git a/apps/web/content/articles/using-ide-for-writing.mdx b/apps/web/content/articles/using-ide-for-writing.mdx new file mode 100644 index 0000000000..775e57f0ca --- /dev/null +++ b/apps/web/content/articles/using-ide-for-writing.mdx @@ -0,0 +1,7 @@ +--- +meta_title: "Why we use IDEs to write blog articles" +meta_description: "Explaining why IDEs are superior in many ways compared to traditional WYSIWYG editors provided by CMS platforms." +author: "John Jeong" +created: "2025-10-17" +coverImage: "https://ijoptyyjrfqwaqhyxkxj.supabase.co/storage/v1/object/public/public_images/blog/tldv-review/cover.png" +--- From 5dab9b4373869359074d928bc6f03a9d1c7ec634 Mon Sep 17 00:00:00 2001 From: ComputelessComputer Date: Wed, 26 Nov 2025 12:02:01 +0900 Subject: [PATCH 2/2] blog: add article about using GitHub as a CMS --- .../articles/using-ide-for-writing.mdx | 123 ++++++++++++++- .../articles/why-our-cms-is-github.mdx | 145 ++++++++++++++++++ 2 files changed, 265 insertions(+), 3 deletions(-) create mode 100644 apps/web/content/articles/why-our-cms-is-github.mdx diff --git a/apps/web/content/articles/using-ide-for-writing.mdx b/apps/web/content/articles/using-ide-for-writing.mdx index 775e57f0ca..228a2d10c3 100644 --- a/apps/web/content/articles/using-ide-for-writing.mdx +++ b/apps/web/content/articles/using-ide-for-writing.mdx @@ -1,7 +1,124 @@ --- +display_title: "Why We Write Our Blog in an IDE (Not a WYSIWYG Editor)" meta_title: "Why we use IDEs to write blog articles" -meta_description: "Explaining why IDEs are superior in many ways compared to traditional WYSIWYG editors provided by CMS platforms." +meta_description: "Most teams write in a browser. We write in our IDE. Here’s why treating content like code gives us more control, fewer surprises, and a workflow that actually scales." author: "John Jeong" -created: "2025-10-17" -coverImage: "https://ijoptyyjrfqwaqhyxkxj.supabase.co/storage/v1/object/public/public_images/blog/tldv-review/cover.png" +created: "2025-11-24" +coverImage: "https://ijoptyyjrfqwaqhyxkxj.supabase.co/storage/v1/object/public/public_images/blog/using-ide-for-writing/cover.png" --- + +There's this quiet assumption in a lot of teams that "writing" should happen somewhere else. Some separate workspace. Some browser tab. Some editor UI designed to hide the machinery. Maybe that works for some people. + +But it never worked for us. + +We spend most of our waking hours inside an IDE. Zed, Cursor, VS Code, Neovim—pick your flavor. That's our home. That's where we think, debug, rewrite, delete, and try again. So it always felt strange to open a WYSIWYG editor and suddenly pretend the way we work should change just because the output is letters instead of code. + +It's not just a workflow thing. It's a mindset thing. + +## Writing Is Part of Building + +At Hyprnote everyone writes and everyone codes. There's no sharp line between the two. Writing lives next to version control, next to the app logic, next to everything else we ship. When you treat writing as something that belongs in the same universe as code, a lot of decisions get simpler. + +For example: context switching disappears. I don't have to think, "Okay, now I'm leaving my environment to go write a blog post." I'm already here. I just open a new `.mdx` file and start typing. Cursor or Zed already knows my shortcuts, my theme, my keybindings, my muscle memory. + +It feels natural. It feels honest. + +## WYSIWYG Tools Hide the Wrong Things + +WYSIWYG editors always promise ease. Click here, bold there, drag an image, done. But once you try to do anything slightly unusual, they fall apart. + +You start fighting the abstraction. + +You want to: + +- add a custom callout +- embed a component +- adjust image borders +- write MDX +- leave inline comments for teammates +- control spacing +- make the layout match the rest of the site + +Suddenly you're clicking around a UI that was never meant for people who actually care what's happening under the hood. You end up debugging the editor itself. + +MDX is just… easier. You write what you mean. You see what you wrote. Nothing forces your hand. + +## Markdown and MDX Are Not Barriers + +A lot of people think Markdown is something you need to "learn." But if you work in tech today, you already know it. + +You write `README.md` files. You write changelogs. You write documentation. Most engineers can write Markdown faster than they can type into a WYSIWYG box. + +MDX just extends that. It lets you treat a blog post like a tiny interface: + +```jsx +
+ +``` + +Things that would be impossible—or messy—in a visual editor are trivial when your writing tool is the same as your coding tool. + +## Content Becomes Code, Which Means It Scales + +This brings us to the real reason writing in an IDE is such a superpower: version control. Every blog post, every line, every word is tracked. Reviewed. Diffed. Discussed. + +- **PRs become editorial workflows.** +- **Comments become revision history.** +- **Preview environments become draft URLs.** + +Everything fits into the same mental model. + +You never have to pray that your CMS didn't break something silently. You never have to trust a black box. + +And if you ever want to migrate? You move the files. That's it. + +No database exports. No weird HTML blocks. No proprietary schemas. + +## The Downside: WYSIWYG Is Convenient (Until It Isn't) + +WYSIWYG editors do have a real advantage: convenience. + +- You drag in an image, and it uploads automatically. +- You paste a screenshot, and it appears instantly. +- You never think about storage buckets or public URLs. + +For a lot of teams, that convenience becomes muscle memory. It's smooth, fast, and frankly… nice. + +But here's the thing: **You can get the same convenience without giving up control.** + +If you're already using GitHub + an object store (Supabase Storage, S3, Cloudflare R2), you can: + +1. drag-and-drop images directly into GitHub's web editor +2. or upload them into your storage bucket +3. copy the public URL +4. paste it into MDX + +It takes seconds. And once you're used to it, it's not meaningfully slower than a WYSIWYG. The difference is that **you own the flow** and you're not trapped inside a CMS UI. + +**WYSIWYG gives you convenience by locking you into its environment.** +**Git + MDX gives you convenience without the lock-in.** + +## No Lock-In, No Surprises + +WYSIWYG editors are convenient in the beginning and painful later. They lock you into their structure, their parsing rules, their UI assumptions. + +But a folder of `.mdx` files? That lasts decades. + +It will outlive whatever CMS trend comes next. + +Your future self will thank you. + +## Writing Where You Think + +For me, writing in an IDE just feels right. + +It's quiet. It's fast. It respects your attention. + +There's no ceremony. No distractions. Just the ideas you're trying to express and the tools you already know how to use. + +Once you experience that kind of writing, it's hard to go back. + +--- + +*This post is Part 1 of our series on building a modern publishing workflow.* +*Next: [Why Our CMS Is GitHub](https://hyprnote.com/blog/why-our-cms-is-github).* diff --git a/apps/web/content/articles/why-our-cms-is-github.mdx b/apps/web/content/articles/why-our-cms-is-github.mdx new file mode 100644 index 0000000000..e98175049f --- /dev/null +++ b/apps/web/content/articles/why-our-cms-is-github.mdx @@ -0,0 +1,145 @@ +--- +meta_title: "Why Our CMS Is GitHub" +meta_description: "Most teams store code in GitHub. We store everything — blog posts, docs, ideas — because Git already solves the hardest parts of publishing: versioning, reviews, portability, and scale." +author: "John Jeong" +created: "2025-11-26" +coverImage: "https://ijoptyyjrfqwaqhyxkxj.supabase.co/storage/v1/object/public/public_images/blog/why-our-cms-is-github/cover.png" +--- + +Most teams think of GitHub as a place to store code. We treat it as the place where everything lives — code, docs, blog posts, ideas, experiments, and the entire history of how Hyprnote evolves. + +This wasn't a grand strategy. It just slowly became obvious: if our work already happens in GitHub, why should publishing be anywhere else? + +The more we leaned into that idea, the more natural it felt. Now it's just how we ship. + +## You Don't Need a CMS When You Already Have Git + +Most CMS platforms try to solve two problems: + +- where your content lives +- how your team edits it + +Git already solves both. + +Content lives in plain files. Editing happens through commits, branches, reviews, comments, and diffs. + +There are no plugins. No migrations. No schema lock-in. No "oops our CMS updated and it broke your content model." + +Just Markdown, MDX, and a repo. + +You never worry about losing access to your writing because everything is portable. You can zip the folder and take it anywhere. There's something comforting about that — a simplicity modern CMS platforms forgot. + +## PRs Are a Better Editorial Workflow + +If you're a technical team, this is the part that just clicks. + +A blog post becomes a pull request. A pull request becomes a draft. Review comments become edits. A merge becomes publication. + +There's no ceremony. No separate editorial queue. No abstracted "content status." No dashboards trying to reinvent what Git already does perfectly. + +You get: + +- inline comments +- suggested changes +- clear diffs +- commit-by-commit history +- revert ability +- preview builds +- CI checks for grammar, broken links, lint rules +- permanent traceability + +This is more powerful than any CMS collaboration feature because it's built on top of something every engineer already understands. + +## Content Is Just Code, So You Get All the Benefits + +Once your blog posts live in the repo, everything becomes composable. + +Need a new MDX component? Ship it. Need to fix a typo? Commit it. Need to update metadata? It's just frontmatter. Need to refactor how posts are structured? Rip through it with a script. + +There is never a moment where you're stuck thinking: + +"How do I do this in the CMS again?" + +Instead the question becomes: + +"How do I want this to work?" + +And that's a better question. + +## GitHub Scales With Your Team, Not Against It + +Most CMS systems age poorly: + +- content models become rigid +- plugins break +- WYSIWYG editors drift +- migrations become risky +- versioning becomes chaotic + +GitHub is the opposite. + +The larger your team grows, the more valuable its primitives become: + +- branch-based workflows +- code owners for reviewing specific areas +- protected branches +- required checks +- bots for automation +- auditability + +These are problems GitHub already solved at a global scale. + +Why recreate them in a CMS? + +## Images, Assets, and the Non-Code Stuff + +A common argument for CMS platforms is the convenience of asset uploads. + +Paste an image → instantly appears. Drag a file → gets stored in their bucket. + +It is nice. + +But we don't lose that. We just do it differently. + +You can: + +- drag images directly into GitHub's web editor +- upload screenshots into Supabase, S3, or R2 +- paste the public URL into MDX +- or commit images directly into the repo + +It takes seconds. + +The difference is you control the storage and the URLs forever — they're not tied to whatever CMS you happened to be using that year. + +## Portability Matters More Than People Think + +Every CMS feels safe until the day you want to leave. + +Then you find: + +- proprietary block formats +- hidden HTML +- vendor-specific markdown +- custom schemas +- migration scripts that only half-work + +A folder of .mdx files has none of that. + +If we move frameworks, hosting providers, or even redesign everything from scratch, the content survives untouched. + +Portability isn't a feature. It's insurance. + +## GitHub Gives Us the Kind of Freedom We Care About + +Writing should be simple. Shipping should be fast. Content should last. + +For us, GitHub checks all three. + +We don't need a CMS to feel modern. We just need something that respects how we work. + +GitHub does. + +--- + +This is Part 2 of our series on building a modern publishing workflow. Next: How to choose the right CMS for your team (and when not to use one at all).