Item — HN Reader

Or better yet -- make your entire site static to begin with! This is how our site works (firebase.com). Our entire site is static content that's generated at deploy time and hosted on a CDN. Dynamic data is loaded asynchronously as needed. If a server were to go down, at least all of the static pieces (which is most of the site) would be unaffected.

We use Firebase to power the dynamic portions (obviously), but you can use plain old AJAX requests as well.

The age of the dynamically-generated HTML page is coming to an end.

6 comments

One man says, "Make your whole site static! Load content with AJAX instead of generating HTML on the server!"

The other man says, "Your site doesn't work on my browser with NoScript."

These two men will never like each other.

The NoScript man is used to this and his fitted tinfoil hat. If he's more lenient he uses Ghostery to block all 3rd party addons and various cookie blockers to keep out the cruft, but keeps the actual site unperturbed.

True tinfoils don't use propietary software.

It'll be open source soon. Plus, you can always look at the injected JS yourself - it's not obfuscated.

In theory, I'm super attracted to this model. My only concern is that it puts a lot of eggs in the Firebase basket. And what happens if I need to scale faster than Firebase can handle? Is there a way for me to run an in-house api compatible version of Firebase on my infrastructure and re-point to that? Can I keep a hot-swappable backup in sync? Or can I pay Firebase to do that for me?

Here's a small, shameless, open source, plug: I work on the "Cactus" static website generator, check out and fork our work here: github.com/koenbok/Cactus (current version), https://github.com/krallin/Cactus (next version)

Is the new version stable or would you recommend the old one to a newcomer? I'm using Hyde right now, but I'm not loving it.

I would personally recommend the new one (but take this with a grain of salt: I work on it). I use it daily to build www.scalr.com.

It's got more tests, and it succeeds at building the Cactus examples like the old one. The only thing that's not stable in it is the "serve" mode.

I'm working with Koen (the original author) to get this into the main repo.

--- If you use it, and run into any issue, get in touch with me: thomas [at] orozco.fr

Shameless plug for Google Web Toolkit. Since core design principle is dynamic site generation client side from permutations (i.e. locales and languages) created at compile time, you can deploy the entire thing as static files to S3. That's what I do :)

The only trick is to leave a foo XHR response in your R53 failover so that a running instance of your app can realize the server is tits up and degrade gracefully. For even better caching throw in webapp manifest files too!

You still need dynamic "pages". Things like geoip redirection or localization etc. You could in theory load this stuff via ajax, but this doesn't work for search engine crawlers. But i do agree most stuff can be static, you can push json on fragments onto s3 and have the web page fetch them via ajax.

We've done this for a lot of data vis work. Clients have access to a cms which lets them stage and publish their data. Doing so puts JSON files on s3 where we also serve the site. There are some trade offs, sometimes you miss having that rest api, but you also gain a lot too.

Route53 can do a lot of that localization redirection for you, though not exactly at the geoip level. Other localization redirects can easy be done from JS.

Agree. Another benefit of having the site mainly static, with dynamic parts loaded over ajax is that it becomes much easier to apply efficient http-level caching.