from Hacker News

No CMS? Writing Our Blog in React (2023)

by y_gy on 2/13/24, 3:19 AM with 43 comments

• by robador on 2/13/24, 6:35 AM

  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.

• by Brajeshwar on 2/13/24, 5:54 AM

  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.

• by joostdecock on 2/13/24, 6:10 AM

  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

• by toastal on 2/13/24, 9:09 AM

  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).

• by azangru on 2/13/24, 8:30 AM

  > 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.

• by jasonjmcghee on 2/13/24, 5:13 AM

  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.

• by jawngee on 2/13/24, 6:07 AM

  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.

• by dewey on 2/13/24, 6:03 AM

  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.

• by bitExpert on 2/13/24, 7:47 AM

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

• by thomasfromcdnjs on 2/13/24, 8:58 AM

  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

• by hunvreus on 2/14/24, 2:30 AM

  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/

• by quickthrower2 on 2/13/24, 9:14 AM

  Never regretted just using Wordpress. Regretted anything else.

• by jszymborski on 2/13/24, 5:43 AM

  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.

• by DeathArrow on 2/13/24, 8:25 AM

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

• by m-i-l on 2/13/24, 9:48 AM

  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.

• by reactordev on 2/13/24, 9:17 AM

  “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.

• by remidemmi on 2/13/24, 9:25 AM

  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

• by leshokunin on 2/13/24, 5:34 AM

  "No grocery store? Growing your own food"