Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com