It's a shame that comments like this one repudiating several of the details in the original article can't be viewed at the location of the originating post.
Instead, everyone who reads the article in the future will have an one-sided impression of the situation (unless the author edits the post based on the points brought up in this thread) due to the lack of comments.
> What is a distributed commenting system? An HTML script tag to load a static file that will ping an api that will serve you comments.
This is how Disqus works. Something still has to power the API that serves the data for it and we happen to like Django a lot so that's what we use. There are also a lot of parts of Disqus that are not the embed (moderation panel, account management, etc.)
> There's no way that we can entrust the business to something that can just catastrophically fail at any moment.
Anything, including service providers, can catastrophically fail at any moment. Fault-tolerant architectures are based on redundancy (including infrastructure provider redundancy, as you mention), not on "guaranteed" SLAs.
It's worth noting that if you're planning on instantiating multiple instances of the same "class" (to use the term generically/loosely) instead of immediately invoking the function, the module pattern has a much more significant memory footprint than prototypical inheritance — total memory usage should increase linearly with the number of objects you're creating, since you're creating new copies of all member functions each time.
> "git reset" has quite simple syntax, but it confuses the hell out of even experienced git users because it's very clever and potentially very dangerous.
Seeking Work - Remote preferred, or SF-ish (North Bay)
Available for short- or long-term engagements. Experience with building large Django applications and working all over the stack (both server- and client-side). Would prefer working in a team environment, opposed to being the primary/single programmer responsible for development.
> Running a whole VM just to run an app is immensely irritating.
Although starting a VM to run an app is irritating, spending time hunting down why your build is breaking (or worse, why production is breaking) because someone had a library a few minor versions out of sync or because they're on a different operating system is immensely more irritating.
Also worth noting is Steve Souders' control.js (http://stevesouders.com/controljs/) which adds some tools for delayed script execution and solves a few document.write use cases that have been issues with deferred loading/execution.
"I agree with you and generally this is a great way for a startup to save money as well because new grads are cheap."
I'd argue the opposite case — if it's true that a good programmer is at least 5-10x more productive than an average programmer[1], you'd actually save money by paying the experienced programmer significantly more when compared to hiring a team of beginning or average programmers.
I updated the original comment w/ the original and updated text. Sorry if you saw this as inappropriate — I had updated it before it was upvoted and thought it only clarified the points, not changed it.
Regardless, many deployments use this same technique for just this reason (to avoid spoonfeeding slower clients responses). How is this any more risky than running Apache up front, barring configuration errors (which could just as easily happen with any other server software)?
They (nginx, lighttpd) are more difficult to exploit, especially when used to buffer requests to a heavier upstream server like Apache.
EDIT (Clarification):
They (nginx, lighttpd) are more difficult — although not impossible — to exploit, especially when used to buffer requests to a heavier upstream server like Apache.
Specifically, they are typically able to handle many more connections than your application server would be able to (as long as they are properly configured), without the incurring the resource overhead of your application server by bufferring the HTTP request/response.
If you're going to call Deschutes a Portland beer at 160+ miles away (and at the same time, leave out Rogue? That one confused me.), I think it's fair to call Russian River, North Coast, Lagunitas, Bear Republic, Anchor, and Sierra Nevada all San Francisco area breweries — and it's a little hard to argue with those. (As long as you like hops, at least.)
Instead, everyone who reads the article in the future will have an one-sided impression of the situation (unless the author edits the post based on the points brought up in this thread) due to the lack of comments.