Hacker News Reader

Comment by pothibo | Hacker News Reader

Your site isn't faster because it's only HTML. It took ~360ms for DOMContentReady in average on your site while on pothibo.com (My blog running on Ecrire) took an average of ~260ms.

Your post made quite a lot of emphasis on "speed" but the first argument I checked was false. I used static site generation and it's a very poor choice for your personal website.

Works fine to create a Readme on github. Sucks if you use it to manage your personal website (brand).

View on HN

With a non-primed cache, your site gave me >1s for DOMContentReady consistently. OP's never reached 700ms. The main HTML page alone of this post[1] takes ~280ms here.

[1] http://pothibo.com/2013/11/rails-journey-dispatch-to-the-con...

Can you offer some alternatives or ideas as to why its slow and yours is oh-so-fast? Or offer some advice on how to speed his site's load times up?

Fresh cache run of your site took me 800ms vs. 400ms for OP.

I suspect you didn't try with a fresh cache for your blog. If all your JS, CSS, etc was cached locally already that would explain your "performance advantage" to me.

In what way does it "suck"?

- Can't edit anywhere beside the machine that has your source & access to server.

- Refactor your posts' tag? You need to manually edit all your post one by one.

- Refactor your theme? Same thing as above

- You can't have dynamic content, ever.

- Can't edit anywhere beside the machine that has your source & access to server.

Not true. OP himself hosts his source on Github, so not only he has access to it everywhere, as he can edit it from any machine with a browser.

- Refactor your posts' tag? You need to manually edit all your post one by one.

- Refactor your theme? Same thing as above

Not true. Static site generation engines like Pelican (which OP uses) can do it for you.

- You can't have dynamic content, ever.

You can with JavaScript (or by integrating a third-party service, though that's cheating a bit).

Use SSH, write scripts to facilitate bulk changes, do dynamic content with Javascript on the client side. If you need server-side logic, build some APIs and talk to them from the JS. Much cleaner than hacking additional features into off-the-shelf CMS/blog software.

What you are describing sounds like a hodge-podge of workarounds.

Like, one solution is "Use SSH, write scripts to facilitate bulk changes, write multiple backend services and front-end JavaScript to interface with them for any actual functionality you want on the site." The other is "Push a button on your blog software." How is the first one "cleaner"? You're basically re-inventing half of a blog with duct tape and toothpicks.

To be honest, your objections sounds more like "It doesn't work for me, personally" and not objectively factual objections.

> - Can't edit anywhere beside the machine that has your source & access to server.

Eh? Use CI and push via Git & a Markdown editor? They have apps for these on your phone? Or just GitHub?

> - Refactor your posts' tag? You need to manually edit all your post one by one.

I can replace all in an entire directory of documents in ~5 seconds. This is a non-issue.

> - Refactor your theme? Same thing as above

I modify two files to refactor all my blog posts.

> - You can't have dynamic content, ever.

Eh? AJAX? Allows you to make calls to another api/domain to throw in dynamic content?

Reply on news.ycombinator.com