Hacker News new | past | comments | ask | show | jobs | submit login

It's not static. It's an editable wiki.



It's not (necessarily) dynamic, in the sense of DHTML, either. While I'm reading a page, I don't need to watch the page change. At best you could notify me that the page has changed, but I don't think I'll really get anything out of that.

There probably are environments where live collaborative (Etherpad/Google Docs/etc. style) editing of communal content is useful, but I suspect that you're looking at "documentation hackathon" or something. For a project that's had useful content for two decades, the changes made in the last two minutes are not why I'm there.

An analogy could be made to Hacker News (or Reddit, or...) comments. While you could pretty easily build a system that does live chat, given that live chat is pretty much everyone's first project in a real-time framework, I think it's important to the nature of the site that changing comments don't show up immediately, because it gets you longer-form comments and things that are more interesting to read for someone who comes later. The process of reading IRC scrollback, when you weren't involved in the conversation, is not particularly enjoyable.


The process of reading IRC scrollback, when you weren't involved in the conversation, is not particularly enjoyable.

It is interesting how true that is. If you're there in real-time, the timing of the various messages and interactivity provides a lot of context to what is being said. You're also not reading everything all at once in a blast of data, instead you have time to read and consider each one appropriately.


But you still have to render to HTML at some point. Wikipedia spends a huge amount of server resources rendering the last version of every page to HTML and caching it. It throws away older versions and has to render them again when you request them. The NYT ran into performance issues managing millions of articles and switched to client-side rendering even for old static content.


As cheap as S3 is, I'd suspect that it'd be cost-effective to just render the core HTML (i.e., that stuff minus the date, time, user-specific bits) of a page once, throw it there and forget about it. I can't get a good read on it from http://dumps.wikimedia.org/enwiki/20150112/ ('cause I'm too lazy), but it looks like it probably would be pretty cheap, given what those files probably expand to.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: