Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree, but it's just too difficult to get away from the React ecosystem...

Do you have suggestions on a better alternative?





It is not difficult to get away from that ecosystem, they simply need to not be included. It is in fact more work to include them and introduced unnecessary complexity.

Several markdown to html generators exist that are well established which simply use the base languages: node, python, go, etc. Instead of using a framework that isn't suited to the task, they focus on structure and features and work on that. By working on the features, structure, and grammar, the tooling will emerge.


This makes sense for one-way posting, but there are two issues for my main use case (personal and small company websites):

1. I want to edit the pages sometimes, and I want to do so using markdown without extra steps.

2. I still want to use React components *sometimes*.

3. I want it to be really easy to deploy and monitor. Nextjs is really easy for those things.

Solving the first issue and third issues don’t require React, but the second definitely does. So I’m still stuck.


> I agree, but it's just too difficult to get away from the React ecosystem...

Why? What specifically are you using for "website with markdown" that needs React?

> Do you have suggestions on a better alternative?

Yes.

1. For turning markdown into html on the server (i.e. render the HTML on the server and then deliver it) use pandoc. I use it like this for my blog: https://gist.github.com/lelanthran/2634fc2508c93a437ba5ca511...

2. For turning markdown into html on the client, write a custom component that parses the markdown into DOM nodes allowing the page author to simply do `<dynamic-markdown remote-src=some/path/to/page.md>`. You can even use one of the many existing Vanilla JS libraries to do this within the custom component.

In either of those two options above, what value does React add?


It’s the I-sometimes-want-to-use-React-components issue that is my holdup. They make it easy to do some visual/behavioral stuff and are often directly portable from other sites or oss projects.

Why not using marked.js or equivalent, plugging it with a Fetch API instead?

example:

  <html>
  <head><title>hello</title></head>
  <body>
  <main id=root ></main>
  <script src=./marked.min.js async defer ></script>
  <script>
  async function load() {
    let element = document.querySelector("main#root");
    await fetch("./index.md") 
      .then(resp => resp.text())
      .then(text => marked(text, { ... }))
      .then(html => {
        element.innerHTML = html;
      });
  }
  window.onload = load;
  </script>
  </body>
  </html>
since it directly injects the resulting html, you may set "unsafe HTML" option in marked (or markdown.js) and include <title> tags within your markdown document. this will _also_ rewrite the browser title(s)

> edit: formatting


That’s good if I’m really *only* ever using Markdown. But what about wanting to use React components sometimes? That’s my biggest problem.

https://htmx.org/. - for smaller sites. Likely the type of site you'd make content in markdown and have it transformed?

Can I still bring my React components when I want them? Haven’t tried out HTMX yet.

Not op, but check out unsuck[0] for some inspiration.

[0]: https://unsuckjs.com/


These look really promising! Can I bring existing React components with me to any of them? That might be the biggest hold up. I’d also worry about maintainability as web standards evolve, since these (mostly) seem like pretty small projects.

You could make it simpler in Python, Go, PHP, Rust, Elixir, Haskell, Ruby, and even in JavaScript if you want to step outside the JS ecosystem.

Just try to make something without React and you light see the light. It's actually not difficult.


Yep, but I still want to use React components sometimes. That’s my biggest holdup.

Not difficult at all



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: