Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will there be a support for markdown? #75

Closed
sharu725 opened this issue Oct 22, 2020 · 12 comments
Closed

Will there be a support for markdown? #75

sharu725 opened this issue Oct 22, 2020 · 12 comments

Comments

@sharu725
Copy link

From the docs

We also use a simple JSON data source instead of markdown, because we don't intend for you to edit content directly through files.

Does that mean there will not be one?

@jimafisk
Copy link
Member

Hi @sharu725, thanks for the question! Are you looking for something similar to Jekyll or Hugo that has frontmatter in YAML and then a markdown body?

I'm definitely open to discussion, but here are my current thoughts on the content editing experience. Whenever I used other SSG's I relied heavily on the structured frontmatter and seldom used the unstructured markdown. The key/value nature of frontmatter allowed me to do more interesting things, like pulling content into specific sections using variables and styling components according to an established style guide. Large markdown files felt reminiscent of WYSIWYG text editors, which can lead to inconsistent styles if you're not careful and make it hard for the developer to display specific information in dynamic ways. With Plenti you could still have a large content section for things like blog posts, you would just define your own key for it since we don't require any specific content structure or reserve any keywords. That said, we're in this weird middle ground at the moment where the frontend CMS is not ready so you have to edit JSON directly. I fully recognize that manually putting content into JSON is a terrible experience. If the goal was to edit these files directly, I think we'd have to implement some sort of yml/md solution to make this experience better. Ultimately these JSON content files will really just be something you track in Git, and you will edit the content directly on your website in the browser. Since JSON is a pretty standard format with generally good performance, I figured it was the right choice given the long-term goals I just outlined.

I would love to hear your thoughts / usecases / disagreements though!

@sharu725
Copy link
Author

@jimafisk I wasn't expecting this elaborate answer. Thanks you.

Are you looking for something similar to Jekyll or Hugo that has frontmatter in YAML and then a markdown body?

Yes, but I think I can wait till the frontend CMS is ready.
I'm trying to move from Jekyll to something with faster build. I like hugo but I love Svelte. i tried Plenti and it was what I was looking for. Fast build time(not sure if that holds up with 100s of posts), Svelte made me choose Plenti.

So I thought I can just use the markdown I already have. Another way could be converting all the posts into JSON. That could be a quick fix for now.

Awesome job by the way. Good luck.

@jimafisk
Copy link
Member

Thanks for taking a look at the project and I appreciate hearing your perspective!

If you do end up bringing things over from Jekyll please keep me posted. I hope pulling your content into JSON isn't too much of a pain. I wrote my own config readers early on in the project, but I've been meaning to move things over to viper. This would potentially make it easy to read YAML and we have an open ticket for it, but there are so many competing priorities that I don't want to overpromise a timeline for this.

I actually hadn't tested the build speeds with a large number of posts, so you've piqued my interest. I just did a rough test by copying the "about" page 200 times (cd content/pages then tee about-{001..200}.json < about.json >/dev/null). The cold startup for that was ~ 1 second:

Screenshot of 200+ page test

time

200_pages

The about page in the default starter is pretty simple, so with real content this would probably be slower. I was actually surprised it was this fast already, because I expect to make some significant performance gains when I implement concurrent build steps.

@sharu725
Copy link
Author

Awesome. Thanks for the test. I'm now a little confident to migrate. I might have some templates that can be ported to Plenti as well. I will keep you posted.

Also, why tapeworm?

@jimafisk
Copy link
Member

🤣 We talk a little about our mascot choice here: https://youtu.be/Gr3KTOnsWEM?t=28. Basically planarians are really simple and flexible - two of our guiding principals.

@kbsali
Copy link

kbsali commented Oct 25, 2020

Hey @jimafisk ,
awesome work, just like @sharu725 , plenti is really what I was looking for : simple Svelte & SSG!
However, I think supporting .md is definitely something to consider. As you said, manually editing json file is not ideal at all, and while you are planning on adding frontend inline editing, I have to admit that I like editing plain md files right from my editor. And just like @sharu725 , this would open up the doors to people wanting to migrate from other blogging solutions supporting markdown, the community around Plenti would then be easier to grow! :)

@jimafisk
Copy link
Member

Thanks @kbsali! It's definitely helpful to know the features folks want to see. I agree with your points, I'll have to take another look at this but it probably won't happen until at least themes are complete. Thanks for the feedback!

@jimafisk
Copy link
Member

@claxxmoldii and I were talking on twitter about md support as well, so I figured it was worth adding to the conversation here. My current thoughts are:

With markdown, in order to have more than a simple block of text, you often have to introduce concepts like "shortcodes" which add some structure to your content. Currently Plenti is set up the other way around: to add content to structure. It feels more natural to me to add the content to the layout this way, but even if it's that's not superior, I think having one direction for the flow of info can have advantages. It also could simplify things like integrating with CMS where we simply want to copy JSON and not have to worry about manipulating it into certain formats before it can be usable in the project. My thoughts might change on this, so it's possible we'll add this someday, I just want to make sure we're thinking through the best way to design the framework so it guides users to make good decisions.

@honzajde
Copy link

My perspective: Markdown support would enable me to migrate my old posts to this otherwise very neat SSG tool.

@jimafisk
Copy link
Member

jimafisk commented Aug 4, 2021

Folks on this thread might want to check out https://github.com/roobyz/articulatePost by @roobyz to be able to write in markdown and convert it to json so it can be used in a plenti project.

@roobyz
Copy link

roobyz commented Aug 4, 2021

Hi All,
This is a work in progress. I just updated "articulatePost" to include a sample folder. Contains a markdown file that I created and the output that was generated. Hopefully this helps jumpstart anyone interested since my documentation is still a bit sparse.

Notes:

  1. I set this up to live in my plenti project folder plenti/articulatePosts(added to .gitignore).
  2. Running node articulate from the terminal in the articulatePosts folder will:
    • look in the plenti project folder
    • for changes saved to any markdown files in the ./posts folder, and
    • generate output to the ./content/posts folder
  3. Provides code highlighting and Katex math capabilities for data science related projects

It will sit there waiting for any change to a file. So just hit save to your markdown file and it will generate the JSON output. You can run plenti serve -L from another terminal to get your changes refreshed pretty quickly. Cheers!

@jimafisk
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants