Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A complete rewrite of wiki as a single page application

c2.com

Post reply on HN
Print view View original

81–90 of 126 posts

Re: A complete rewrite of wiki as a single page application

#81

Post by Touche »

zAy0LfpBZLC8mAC wrote: post #67
mikeash wrote: post #63

Earlier quoted context omitted.

Everything you said applies to humans using normal web browsers as well. And yet people still fill pages with JS, and browsers still execute it, and people still see stuff.

With one minor difference: Humans at least have full-blown human intelligence which they can use to heuristically determine when the execution is "complete". Not that that makes all that much more sense ...

You seem to be saying that page load is not deterministic but that is not true. A special version of a browser can easily keep track of http requests and other async operations and consider the page to be complete when async ops = 0 and the last paint is complete. The only hard part I can think of is a page that is recursively calling setTimeout endlessly, but even that can be coded around.

Re: A complete rewrite of wiki as a single page application

#82

Post by gavinpc »

kephra wrote: post #35
blueskin_ wrote: post #12

Wow, that's some bad usability there. Talk about chasing the shiny over form and function. Javascript pages are the 'Flash site' of the 2010s and I can't wait until it's similarly consigned to its rightful place in the dustbin of history. All they do is waste my CPU time and memory, force me to enable a scripting language that is riddled with vulnerabilities just to see some content, and run more slowly than real pag…

Lets look, how this new wiki behaves without JS, from the viewpoint of a search engine. e.g. compare http://c2.fed.wiki.org/methodology-subsets.html with and without javascript. The new wiki is doomed by design, because content can not be found by Google or any other search engine. And a wiki where the content can not be found is for the trashcan.

It has also joined the ranks of sites that don't work at all without cookies. Go ahead, try it.

Re: A complete rewrite of wiki as a single page application

#83

Post by mbrock »

rayiner wrote: post #80
mbrock wrote: post #20

The original wiki was a wonderful community, alive in that ineffable way that very few online communities are, totally free and public. I wrote a blog post [0] about how strongly it influenced me as a person and the gratitude I feel for it. Ward Cunningham is a respected and intelligent software designer who works on open projects for the public good. The immediate cynicism and dismissal I've seen of his new project…

Take a look at a movie from the 1990s, where a character pulls up say a news article on the internet. Just text and some pictures. So usable! The web peaked in 1998, when everything was plain HTML but you could Google-search it, and everything since then has been the moral progeny of the tag. So when a perfectly usable site like C2 embraces the bankruptcy of the Web 2.0 era, I think people are justified in expressing…

The web peaked in 1998?

That's an interesting claim to make on a forum that frequently discusses new web technology, the progress in browser engines, the interesting new stuff that's being made.

In 1998 there was no Gmail, no Github, no Slack, no Discourse, and so on and so on.

C2 may have been perfectly usable, and I think it should remain as an archive, but there was barely any contribution anymore.

When you imply that Ward's "Smallest Federated Wiki" embraces the "bankrupty of the Web 2.0 era," it sounds to me like your pet peeve against JavaScript makes you discount the whole project.

I mean, you're very free to have your own views and opinions, but as someone who's very interested in this project, I'm pretty baffled by all the negativity, and the lack of a more than superficial interest.

The idea of a federated wiki is, it seems to me, very cool, and the fact that it hasn't been done yet indicates that the web has not peaked. So where you see "the bankruptcy of the Web 2.0 era," I see a fascinating development of the wiki idea by its original creator.

Yeah, the JS app seems a little unpolished, but also pretty cool in many ways. I don't know whether it's the best move to replace the old C2 wiki right now. Maybe Ward sees it as a way to get more people interested in the new project. I don't know.

As for me, I'm going to see if there's any way I can contribute and help the project. It would be nice to see some more of that attitude here, instead of only (in my view) superficial complaints.

Re: A complete rewrite of wiki as a single page application

#84

Post by zAy0LfpBZLC8mAC »

Touche wrote: post #81
zAy0LfpBZLC8mAC wrote: post #67

Earlier quoted context omitted.

With one minor difference: Humans at least have full-blown human intelligence which they can use to heuristically determine when the execution is "complete". Not that that makes all that much more sense ...

You seem to be saying that page load is not deterministic but that is not true. A special version of a browser can easily keep track of http requests and other async operations and consider the page to be complete when async ops = 0 and the last paint is complete. The only hard part I can think of is a page that is recursively calling setTimeout endlessly, but even that can be coded around.

No, it cannot, that is called the halting problem.

Re: A complete rewrite of wiki as a single page application

#85

Post by geofft »

sp332 wrote: post #73
userbinator wrote: post #70

Earlier quoted context omitted.

just to see some content Moreover, static content. There's a big difference between using JS to do something interactive and useful which couldn't be done before (e.g. various games, calculators, and visualisations get this part right), and using it to incompletely emulate basic functionality that web browsers already have. the 'Flash site' of the 2010s I like that analogy - stuffing the whole site into Flash was a h…

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.

Re: A complete rewrite of wiki as a single page application

#86

Post by geofft »

zAy0LfpBZLC8mAC wrote: post #52
Touche wrote: post #50

Earlier quoted context omitted.

Google executes JavaScript.

That can impossibly be true. JS is turing complete, turing completeness means that the halting problem is undecidable, which means that at best Google will execute JS with some random resource limit to avoid infinite resource consumption, which in turn means that whether Google will actually see the content is ultimately undefined. And even worse: other search engines might, due to lack of standardization of the avai…

The exact same argument could apply to pages that take forever to load, because the web server sends you a chunk of bytes every two seconds. Would it be braindead for Google to apply an arbitrary timeout without standardization?

Re: A complete rewrite of wiki as a single page application

#87

Post by zAy0LfpBZLC8mAC »

wahnfrieden wrote: post #72
zAy0LfpBZLC8mAC wrote: post #67

Earlier quoted context omitted.

With one minor difference: Humans at least have full-blown human intelligence which they can use to heuristically determine when the execution is "complete". Not that that makes all that much more sense ...

I doubt Google is worried about unfairly weighting pages it indexes with Javascript that takes so long to run, hence the cutoff. It's more a question of where to place the cutoff than whether to have one at all, which is absurd.

No, the question is neither of those. The question is how to define the cutoff in a portable way that enables interoperability and long-term stability. A document format where every implementation has its own secret cutoff that also probably changes all the time is just idiotic if your goal is interoperability.

Re: A complete rewrite of wiki as a single page application

#88

Post by zAy0LfpBZLC8mAC »

geofft wrote: post #86
zAy0LfpBZLC8mAC wrote: post #52

Earlier quoted context omitted.

That can impossibly be true. JS is turing complete, turing completeness means that the halting problem is undecidable, which means that at best Google will execute JS with some random resource limit to avoid infinite resource consumption, which in turn means that whether Google will actually see the content is ultimately undefined. And even worse: other search engines might, due to lack of standardization of the avai…

The exact same argument could apply to pages that take forever to load, because the web server sends you a chunk of bytes every two seconds. Would it be braindead for Google to apply an arbitrary timeout without standardization?

Nope, but it would be braindead for google to then just index however many bytes it has received up to that point as if it were the full document.

Re: A complete rewrite of wiki as a single page application

#89

Post by Touche »

zAy0LfpBZLC8mAC wrote: post #84
Touche wrote: post #81

Earlier quoted context omitted.

You seem to be saying that page load is not deterministic but that is not true. A special version of a browser can easily keep track of http requests and other async operations and consider the page to be complete when async ops = 0 and the last paint is complete. The only hard part I can think of is a page that is recursively calling setTimeout endlessly, but even that can be coded around.

No, it cannot, that is called the halting problem.

Right, so like you said they have a reasonable cut-off for this one most likely ultra-rare situation. It's not going to be perfect but it doesn't have to be, in order to be useful.

Re: A complete rewrite of wiki as a single page application

#90

Post by rayiner »

mbrock wrote: post #83
rayiner wrote: post #80

Earlier quoted context omitted.

Take a look at a movie from the 1990s, where a character pulls up say a news article on the internet. Just text and some pictures. So usable! The web peaked in 1998, when everything was plain HTML but you could Google-search it, and everything since then has been the moral progeny of the tag. So when a perfectly usable site like C2 embraces the bankruptcy of the Web 2.0 era, I think people are justified in expressing…

The web peaked in 1998? That's an interesting claim to make on a forum that frequently discusses new web technology, the progress in browser engines, the interesting new stuff that's being made. In 1998 there was no Gmail, no Github, no Slack, no Discourse, and so on and so on. C2 may have been perfectly usable, and I think it should remain as an archive, but there was barely any contribution anymore. When you imply…

> That's an interesting claim to make on a forum that frequently discusses new web technology

I don't like to shy away from controversy. ;)

> In 1998 there was no Gmail, no Github, no Slack, no Discourse, and so on and so on.

No, but there was SMTP/IMAP/Exchange, which was better and didn't spy on you. There was ViewCVS, which was just peachy, and in any case the improvements in Github over CVS have to do with git versus CVS (i.e. the native apps and protocols), not the web frontend per se. There was also IRC and AIM, which were just peachy too.

It may well be that the 1998 peak was a local maximum, but I stand by the assertion that the web was better back then. The modern web is spectacularly bad for finding and consuming information. Want a simple how-to or product review? You'll be blasted in the face with images, video, and animation until your quad-core 2GHz/16GB RAM machine falls to its knees.

And to what end? Text is still, after thousands of years, the most efficient way to convey information. Anything you layer on top of it detracts, rather than adds.

Post reply on HN