Hacker News Reader

Comment by avalaunch | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com