Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTMLy: Databaseless Blogging Platform (Flat-File Blog)

github.com

Post reply on HN
Print view View original

21–30 of 66 posts

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#21

Post by bananas »

yen223 wrote: post #20

Replacing the database with flat files? We have gone full circle, haven't we. I can think of a lot of disadvantages with not using an actual database. What's the benefit of going back to flat files?

cp/tar/rsync/git/svn to name a few.

HN is apparently flat file based.

I actually have a 100% static site deployed in production. It is served off nginx, built with make, shell and sed (does some include processing and index generation) and is deployed with rsync from make and uses git for version control.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#24

Post by sheraz »

yen223 wrote: post #20

Replacing the database with flat files? We have gone full circle, haven't we. I can think of a lot of disadvantages with not using an actual database. What's the benefit of going back to flat files?

I wonder what simple blogging / CMS engines are out there that use sqlite as the backend. This also has the benefits of simple backups without the complexity of another process running. Most (if not all) webhosts will have this baked into their PHP installs.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#25

Post by spookylukey »

You should really use SQLite!

You will either end up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of SQLite ... or, you will fail to even attempt the features that SQLite gives you - such as locking and dealing with concurrency - and you will have bugs.

For example, you use file_put_contents. See this comment: http://www.php.net/manual/en/function.file-put-contents.php#...

Please don't go and add locking now! (It's hard to get right). SQLite was invented to be a better fopen() - use it! There is no reason not to, if you are requiring PHP 5.3. If you want a simple plain text dump of your SQLite DB, that's not hard to add.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#26

Post by pestaa »

mercurial wrote: post #8
deckiedan wrote: post #5

Earlier quoted context omitted.

Yep - and there's also some benefits performance and security wise to not having any serverside code at all (other than nginx, or whatever). The problems you have with jekyll, pelican, et al is that you lose site-side search, 'related posts' (without some reasonably complex compile-side clobber), etc. etc. Using extremely minimal PHP lets you deploy just as easily, you don't get too much of a performance hit (a hell…

> PHP as a server-side 'clever templating' language really isn't that bad. I only touch PHP as little as possible, and work with a legacy PHP codebase, but AFAIK, it hasn't evolved a tag to automatically HTML-escape/JSON-escape content. So, it's as good a templating language as it is a programming language: pretty terrible. I'll trade PHP for something as barebones as Python with WSGI + Jinja2 any day.

It's not fair to compare to compare pure PHP and Jinja2. Twig is the PHP-equivalent of Jinja2, and it is an extremely well designed templating engine.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#27

Post by kijin »
I hate non-standard stuff like this, even though I myself do similar things all over the place. It's the kind of the thing that's OK if you do it to yourself, but immediately rings an alarm when it is distributed to the general public. When you're already doing something non-standard by using a flat file instead of a well-known DB format, you might as well use standards in other places so that people have fewer reasons to complain.

For example, Markdown has a special syntax for tags. It looks like this:

    This is a title.
    ================
Since it is extremely unlikely that an tag will be used for anything other than the title of a post, why not use it to mark a line as the title?

Or maybe use the MultiMarkdown convention of colon-separated header fields at the top of the file, like:

    Title: This is the title.
    Tags: foo, bar
    Date: March 3, 2014

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#28

Post by chc »

bananas wrote: post #21
yen223 wrote: post #20

Replacing the database with flat files? We have gone full circle, haven't we. I can think of a lot of disadvantages with not using an actual database. What's the benefit of going back to flat files?

cp/tar/rsync/git/svn to name a few. HN is apparently flat file based. I actually have a 100% static site deployed in production. It is served off nginx, built with make, shell and sed (does some include processing and index generation) and is deployed with rsync from make and uses git for version control.

The design of news.arc is notoriously quirky. Given the fact that paging is entirely based on continuations, I don't think "flat-file-based" covers it.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#30

Post by vidarh »

spookylukey wrote: post #25

You should really use SQLite! You will either end up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of SQLite ... or, you will fail to even attempt the features that SQLite gives you - such as locking and dealing with concurrency - and you will have bugs. For example, you use file_put_contents. See this comment: http://www.php.net/manual/en/function.file-put-contents.php#... Please don'…

A blogging platform for personal use is not magic. Avoiding things like concurrency problems in small platforms like this is often trivial.

Personally I also use a flat file blogging platform, and I explicitly rejected putting stuff in a database because I want to be able to edit the articles with emacs and check them into a git repository. Concurrency in my case is a non-issue because, well, there's only one of me.

There are plenty of scenarios where you really should not use SQLite nor any other RDBMS because it overcomplicates things that are really exceedingly simple.

Post reply on HN