Hacker News Reader

Comment by natrius | Hacker News Reader

Don't do this. If you aren't using a database or processing forms, your life will be better if you learn jekyll and use it.

View on HN

Or, indeed, Pelican[1]

[1] http://docs.getpelican.com/en/3.3.0/

Until you need to add a bit of dynamicity, such as a contact form or something trivial, sadly.

There are plenty of form services you can drop on a static page. That is what you should do.

That assumes the only thing you'll need is a contact form, though. My site has various things, such as a page that shows a graph of my daily weight.

So... you're using a database? Great. Use Django.

I think his point is that it's quite likely you'll begin without a need for a database but later want to add some functionality requiring one. And at that point, you will have been better off starting with Django (or similar) as now you'll need to migrate everything over anyway.

That point is wrong. Setting up a Django deployment that won't fall over when you get traffic is more work than moving Jekyll templates into a Django install. Plus, if he'd started with Jekyll, he might have chosen to store his weights as a flat file that Jekyll could use to generate static charts.

Database-first thinking for content sites is just wrong. I've done it based on this same argument, and I've learned my lesson.

If you need a DB that's read only and updated infrequently you can just store the content in JSON files and parse them client side. Of course if you need to do writes it gets more complicated.

How will a static site fall over with Django? My page generation times are only a few ms, they're just fetched from cache, same as the static files.

The problem isn't showing the data, it's storing it. I have different computers gathering the data and deploying my site, so I would have to set up an elaborate solution, and I would still not be able to do A/B tests, sending email for new content, auto-Tweeting, etc.

The solution you've chosen is probably right for your situation. However, lots of people (including me not too long ago) create static sites in Django because they dream of making it more dynamic that way. That's usually a bad approach in my experience.

Something that I've been playing around with is hosting sites on S3. Then you can have a simple cron job that will just update an HTML or JSON data file at whatever frequency you want.

Nice way to keep the site static but add a bit of variability.

I don't understand why you need S3 for that. Can't you just as easily schedule an upload of updated files from your computer to your server?

It's other way around: with S3 you don't need your own server. KISS

Yea - it can work just as easily on your own server but the idea is that you don't have to worry about hosting at all and rely on S3 which is the most reliable AWS service.

If you dont want to generate static files with data for that, you can use the google docs json API to store the graph data and render that.

I tried going with that first, it was almost impossible. I never figured out how to do it.

Also, the bigger problem was, indeed, data storage, not display.

Its badly documented, but not impossible. I should write it up sometime.

You can also just deploy your static site to BitBalloon, then any contact form will start working and accepting form submissions. (Disclaimer, I'm the founder).

Link: https://www.bitballoon.com

Reply on news.ycombinator.com