Hacker News Reader

Comment by prmoustache | Hacker News Reader

Isn't "poweredy by python" kind of defeating the purpose of using markdown and git? Well I don't mean python as a language, but python as running as a web service/app.

Usually when your website is hosted on git as markdown files, that is because you'd rather have the website generation separated from serving the actual content to the public, i.e. having a secure and dead simple static website.

If you start having to run a service/container, that generate the content on the fly and plan to edit the website using the browser, I don't really see the advantage of hosting the content on git vs a database. That database can be as simple and easy to host/backup/manage as a simple sqlite3 file and would still be more efficient than a git repo as a storage backend.

View on HN

No, this isn't always true.

I have hated every WYSIWYG intranet my employer has used. I just want to write Markdown.

Luckily, we also had access to a file server with ~/public_html and httpd with PHP.

So I just threw PHP Markdown Extra and a htaccess file up, now I can write in Markdown and it magically works. If that was done with Python I wouldn't care either.

(that old webserver has since been retired and the new one doesn't have PHP, so now I render locally with Pandoc and rsync my HTML files directly, sigh)

I agree, there are two things I miss with markdown: import/export of text + media, multi user editing. This is always an extra step when you do not have and editing builtin in the Wiki that handles that. The "paste" image into document feature is one of the most useful features of a wiki if you want to write a fast bare bones tutorial.

The purpose of using markdown is to make editing simple. The purpose of using git is to use a well-known and rock-solid history-preserving file store. Both of those purposes are orthogonal to method of delivery and tech stack used. So no.

In general, i agree that static site generation is preferable to dynamic rendering where possible, because it makes for a much simpler and more secure deployment. But a wiki has to support editing of pages in the browser, and authentication of users before they can edit, and you need a backend for that. Also, if you want to support browsing of page history, a static site generator would need to render every version of the page upfront, which feels like a bad idea to me.

> That database can be as simple and easy to host/backup/manage as a simple sqlite3 file and would still be more efficient than a git repo as a storage backend.

With git you will have the latest version of the file in the filesystem, that must be more efficient than retrieving it from sqlite3, mustn't it?

I am not sure that retrieving it is the correct word. In term of efficiency you have to take into account the overhead of multiple files, some in cache, some not vs 1 single probably already cached file

Also https://www.sqlite.org/fasterthanfs.html

Reply on news.ycombinator.com