No CMS? Writing Our Blog in React (2023) | Hacker News Reader

No CMS? Writing Our Blog in React (2023)

getwaitlist.com

21 pointsy_gy43 comments

I think it's great they did what works for them. Personally though, I am starting to believe React, or indeed any reactive framework, is extremely ill suited for most websites. It adds a layer of complexity on many levels that IMHO is not worth the tradeoff. Not only the amount of tooling required (node_modules), also the fact that you're expected to write all your own elements (components) and override default browser functionality, and expect all of that to work perfectly (forever) is baffling to me. React is an extremely complex layer that abstracts away a quite simple and well understood concept: markup. If your content is mostly static, just use markup and sprinkle a bit of js on top of you must. Your visitors will be grateful. If you're building a web based application, which you're probably not, use React.

> the fact that you're expected to write all your own elements (components) and override default browser functionality

What ? I've certainly not overriden the HTML div, nor the CSS font-weight.

> If your content is mostly static, just use markup and sprinkle a bit of js on top of you must. Your visitors will be grateful. If you're building a web based application, which you're probably not, use React.

This is solved by React server rendering or RSC, e.g. through Next.

Your visitors will see HTML.

> This is solved by React server rendering or RSC, e.g. through Next.

You realise that's just HTML with more steps?

HTML doesn't solve routes as well as markup reuse. If you want to copypaste markup into it's own HTML and edit the contents, then you do you.

<template> is completely reusable…

> just use markup and sprinkle a bit of js on top if you must

My perspective is of React as a templating engine for markup that allows you to add behaviour on top as you need. So in a sense, exactly what you've said.

It's good at this because it's all done seamlessly in the same language with hardly any magic or conventions they have invented. It's just javascript. It also has a rendering model that's extremely simple to reason about when updates happen.

You can build something as complicated or as simple as you want with that, of course, but React doesn't care if you do. That's up to you to decide. React can be 'just' a static markup template engine running at build time (my own blog is built this way!), a server-only template engine, little bits of behaviour sprinkled in on the client to isolated parts of the page, all the way up to a full blown client application with an arbitrary level of complexity.

Agreed. This a problem that only needs to be solved once. My personal website is an OS like GUI that took a fair amount of effort to extract from an unrelated application, but no greater effort than starting from scratch with something like React. That effort is over and future contributions are now little more than a line of text in the HTML but I get all the flexibility and performance of not using React.

I have mixed feelings about React. I like it better than jQuery, and better than most other JS frameworks I’ve used.

But I prefer Mithril (https://mithril.js.org/), which offers the same immediate-mode advantages (https://news.ycombinator.com/item?id=19746235) without the crazy-complex dependency-tracking reactivity.

I rather liked this comment on React: https://news.ycombinator.com/item?id=38640051

I'm sorry but you lost me at “Write blog in React.” The art/science and tech of writing should be as decoupled as possible from the tools (CMS, React, etc.) Make people write -- then enable the features, UX, and the other facades of a blog with the tooling -- React, Vue, WordPress, Movable Type, Blogger, and FooBar.

Yup, headless CMS exists.

The art/science and tech of writing should be as decoupled as possible from the tools.

There is nothing about writing that makes this automatically true, and if you look at some of the software that novelists, editors screenwriters, journalists, technical authors, etc use it doesn't really hold water. For example, Scrivener and Shotrunner are closer to databases than writing tools.

Humans have been writing for thousands of years, and modern tech tools to help have been around for about 50. It's far too early to say whether or not tools hinder the process.

I agree to this perspective too. Screenwriters, novelists, etc. need to keep a tap of the journey, fork, and side stories of characters and entities. The tools help them with that and not with the writing part.

Blog Articles are self-contained in most cases and are within the scope of that blob. So, most tools should be either an enabler in that writing (editors, formatters) or the aftermath -- publishing (most CMSes).

I'm sorry, but Knuth wrote TeX in order to be able to write books up to his standards. Tools matter, because they enable you to realise and work with higher level concepts.

From TFA:

> My idea was that surely it's possible to write a bunch of markdown, and then have that get wrapped in a bunch of JSX tags that come pre-styled, using the styles of your existing repo? For example, what I expected was to be able to write *test* (Markdown for bold) and then get a component that looked like<Bold>test</Bold> where <Bold> is a library-defined React component

It surely is possible, so perhaps I can share some links if others are wondering the same thing.

If you like to roll your own solution for that, you can use the unified ecosystem: https://unifiedjs.com/

However, if you want JSX just do what everyone does and reach for MDX: https://mdxjs.com/

> We thought this would be a no-brainer and that there would be some CMS/SSG libraries out there that made this Markdown conversion process easy and facilitated integration with any number of frontend frameworks.

You thought correct:

- NextJS MDX integration: https://nextjs.org/docs/pages/building-your-application/conf... - Gatsby MDX integration: https://www.gatsbyjs.com/docs/how-to/routing/mdx/

Or check https://jamstack.org/generators/ for more options But since you seem to like

At that point might as well just write HTMLh instead of writing markdown and making JS convert it to HTML. I feel like I’m taking crazy pills or something.

you are not alone

So when the primary purpose of your blogs content is to deliver information accessibly, any user block JavaScript by default for security/privacy, any TUI browsers, & we crawlers get nothing but a blank screen—not even a noscript. You can’t convince me this is a rational usage of a technology—this is essentially static HTML. There’s a lot of justified complaints in here about how terribly limited Markdown is for creating blogs/documentation, but the solution shouldn’t be jumping to React but consider choosing something with better features & extensibility for actually writing something beyond a comment (such as reStructuredText or Asciidoctor).

> We recognized that a full-on SSG wasn't going to do the job.

Why? The article doesn't explain.

> it turns out that it's not so easy to "just use a CMS." Like many others, we initially looked into popular ones like Ghost, Hugo, Jekyll, and Publii

I don't know what Publii is; but Hugo and Jekyll aren't CMS's.

> all I really wanted was to be able to write Markdown, and then get some React Components that were styled well enough to use in my blog

Why was this a technical requirement? Why should the output from Markdown be a React component? Why does she need React for her blog? The article doesn't say.

Publii is one of the few competent attempts at a desktop CMS app.

https://getpublii.com/

They do a lot of things right.

I think being in a position where the person writing the content is comfortable with writing code and/or won't make a mistake that will mess with layout etc is pretty unique.

I would imagine that's the most common reason people use a CMS.

Most definitely. There are reasons to reinvent the wheel sometimes, this, however, maybe be a low roi reason...

I don't want to be the jerk in the comments but this seems pretty poorly conceived.

* What are you going to do when you hire a non-technical writer down the road?

* The handwringing about control over SEO smacks of NIH and makes little sense. It feels like a very thin justification for this weird scheme.

* You are a technical company but you couldn't figure out how to apply your look and feel, which isn't unique and feels like a bootstrap template, to something or anything else.

* Your content is JSON in JS

I'm going through some of your blog posts and I just don't see where this kind of overkill is necessary. Nothing I'm seeing can't be represented in markdown with a little front matter. I mean MDX lets you use react components, which doesn't feel like a good idea to me either but feels like a better idea than this.

I dunno, kind of a strange read first thing in the morning.

I'm with you 100%

Maybe I am missing the point, but why would people want to manage their content within their code? It seems incredibly weird and prone to quite messy and unmaintainable code.

I wonder if they even looked into headless CMS options? I just don't understand the thinking behind this, it seems really bizarre and inefficient.

Surely you can just run a headless CMS and fetch content using GraphQL or REST, and have your blog look the way you want it to with React or Nuxt SSR?

Weird...

I'm going to tack onto your comment because my instinct was just to write "oh for pity's sake! :-o"

You've hit the nail on the head. There is IMO some distance between eating your own dog food and NIH, and they have happily traversed that distance without a thought.

My first reaction was to think that someone is re-inventing the wheel again for not good reason, but as usual "it depends".

If you are trying to have your blog as your main website and not just one sub-category it makes sense to use a blogging framework (Hugo, Ghost, Wordpress etc.), but I realized that having a blog integrated in a product isn't so straight forward if you want to keep your existing footer, header, CSS and share it.

I tried to use Hugo to integrate a blog in my Rails app but it was a bigger amount of pain than just doing it quickly in your existing code base with all the tools and styles already available.

> if you want to keep your existing footer, header, CSS

That's actually pretty simple, and is what CSS is meant to be helping with - there will be a pain of having to wrangle the framework's HTML to fit what you need, but it's doable, and a small price to pay for the benefits the tried-and-tested framework brings.

Yes, but in reality it's not that easy if you want to have a shared footer / header / navbar component.

If you want to use for example Tailwind CSS classes in your blog you also need to integrate it with your build pipeline to add/remove unused classes from the final stylesheet.

I have client side includes using a custom element, that I can add to any HTML page and get the shared footer, header, etc.

I'm currently facing the same problem - adding a blog to a Rails app.

I thought Sitepress looks interesting, as its supposed to integrate with Rails. Have you given that one a try?

https://sitepress.cc/

I haven't seen that one yet but it looks good and kinda what I was looking for. Thanks for sharing!

I expected there to be many solutions for this problem but wasn't able to find a simple one.

In the end I just generated a simple "post" model and have some ugly admin interface that allows me to paste some markdown into a small box and publish it. Then I'm just using some gems for RSS feed / sitemap handling.

If you natively work with Markdown, consider the static site generation approach. It also means that your content is also source-controlled.

Basically, just convert your markdown to HTML, and dump that into your existing templates.

I use Hugo to generate HTML without header and footer etc. and serve the HTML parts from my app.

Wondering why Docusaurus (https://docusaurus.io) did not match their needs. Works perfectly fine as a blogging engine for our tech blog.

A project I've been slowly working on over the years is JSON Blog -> https://github.com/jsonblog/jsonblog-cli

The idea being you can have a file called blog.json, and your entire site structure can be generated from it. (in whatever fashion you want aka templates)

You can store the content of the blog posts in the blog.json or they blog posts can reference something at a quasi permanent place e.g. ipfs

The author may be conflating rendering and content management.

There's been a huge push in the past few years for "headless CMS": content is managed entirely separately from the actual website or app where it's leveraged.

In this specific case, YAML frontmatter MDX along with Next.js, Gatsby or similar would have done the trick.

Shameless plug: if you want to focus on managing content rather than juggling YAML and git, I'm building Pages CMS [1]. It adds a user friendly interface on top of GitHub when dealing with flat files.

[1]: https://pagescms.org/

Never regretted just using Wordpress. Regretted anything else.

Really surprising to hear these folks couldn't have written a e.g. Hugo template to fit the site's look and feel in a very short amount of time.

I see a blog as a web site, with different pages for each article, which you can bookmark, not as a web application.

This risks making your blog invisible to search engines, unless their crawler goes to the significant additional expense of either executing JavaScript or developing a custom spider to identify and load the JSON directly.

“Specifically, sure we could write a Ghost blog that used our preferred font and colors, but it still wouldn't have the GetWaitlist navigation header or footer or "look and feel" of the rest of our website. Plus, if we wanted production deployment to be easy at all, then we'd have to host it on a subdomain.”

This is entirely incorrect. If you want to reproduce your header and footer in some other thing, simply copy your header and footer! View-Source, copy, paste. It’s that easy.

Hosting it on a subdomain? Nope, you don’t have to do that either. You can use nginx to serve the path, you can use httpd to serve the path, you can use AWS ALB’s, HAProxy, pretty much every web server that can load balance can host your path to the blog outside of the path to /.

I stopped reading after this failure to do due diligence and use common sense.

give keystatic a try: https://keystatic.com

- open source

- configuration files for the cms data model

- github based (no database)

- yml, markdown, json output

- simple and aesthetic

"No grocery store? Growing your own food"

Reply on news.ycombinator.com