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

101–110 of 126 posts

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

#101

Post by shoover »

mbrock wrote: post #98
shoover wrote: post #92

Earlier quoted context omitted.

Right on. I recently deployed a fedwiki farm for my team after playing with it myself and catching just a whiff of the possibilities. I had a litany of complaints myself, but was compelled to press on due to the intriguing promise of the goals of the project. While some issues stem from the fundamental design of tracking individual paragraphs, I believe many of the problems will be designed away with better client si…

Good to hear that someone else is interested! Could you explain a bit more about the issues with tracking paragraphs? It sounds like an interesting idea. From perusing the GitHub documents briefly, it seems like the architecture is such that other UIs should be possible. Do you have a hunch about the possibility of making, say, an Emacs client?

Because of drag/drop refactoring and the detail in the page journal, they have to track the history of every paragraph, which requires UI for interacting with individual paragraphs. You can't have just a big old textbox for the whole page and do things as we always have (maybe you can get close with the right diff algorithm).

So to edit a paragraph in the current UI you have to double click to get an edit box, then click to insert the cursor in the right spot. Adding a new paragraph requires a few clicks. Adding a new page and getting to that first edit box requires too many clicks.

Drag/drop as the primary mouse interaction also makes it hard to copy/paste text in and out of the wiki.

It's painful if you're used to orgmode.

But like I said, these are just UI gripes. You can see how they fall out of the fundamental design of the system, but I think focused client design could optimize editing and make it more familiar if that was a goal.

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

#102

Post by darkmighty »

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.

It doesn't matter if the halting problem is solvable or not, there would exist a cut-off anyways (even if they had a super-Turing machine).

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

#103

Post by geofft »

zAy0LfpBZLC8mAC wrote: post #88
geofft wrote: post #86

Earlier quoted context omitted.

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.

OK, so we have a pretty straightforward rule. Providing no further input to the program once it begins,

1) If execution terminates by some timeout T, where T is at least several seconds, then index that.

2) If execution has not yet terminated by T, whether or not we have any idea whether it will terminate in the future, don't index.

Tune T so that it will get the vast majority of reasonable web pages. (Hypothesize, and test, T = 5 seconds or 30 seconds or something. Have a human look at the highest-PageRanked timeouts to figure out what's going on.)

This applies whether "the program" is server-side or client-side. The halting problem cannot be reduced to the timeout problem (since the halting problem asks if it ever terminates), and the timeout problem is pretty clearly computable.

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

#104

Post by sp332 »

geofft wrote: post #85
sp332 wrote: post #73

Earlier quoted context omitted.

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…

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.

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

#105

Post by HelloNurse »

mbrock wrote: post #71
HelloNurse wrote: post #69

Earlier quoted context omitted.

That the rebuilt C2 wiki doesn't work is a fact; the problems are, unfortunately, so obvious and so serious that the first impression is uncommonly bad, there is no need to look further. The "value" of the old site is lost, the "potential" for improvement doesn't matter and doesn't exist, the "innovation" is a failed experiment that shouldn't have been "released early". I just don't understand this leniency towards a…

Is it the whole concept of a federated wiki that you think is a "bad idea"? When you say that the "'potential' for improvement doesn't matter," what exactly do you mean? Doesn't matter to whom? For what reason? I am lenient and curious about most attempts at innovation in the field of web-based communication and collaboration. Personally speaking, I like Ward Cunningham; I admire his previous work; I am interested in…

A federated wiki consists of three main parts: a federated database of content (which is supposed to be the interesting part), a user interface for reading that content, and a fairly different but unavoidably related user interface for editing and administration (both likely to resemble their counterparts in a non-federated wiki, but a bit more complex because of the richer information model).

Of these three components, all criticism of the C2 rewrite is focused only on the most accessible: the reading user interface, which is blighted by the fundamental bad idea of imposing a bizarre, dysfunctional SPA gateway on one of the most pure examples of hypertext in existence. Only this user interface is an impractical, grossly failed experiment; it's obvious that pages like those in the old C2 wiki, possibly with a few extra buttons and links to deal with federation-related metadata and features, would have been a far superior user interface.

Nobody complains about the idea of a federated wiki (either in general or referring this particular design) because, with the ugly bugs and bad user experience, it's simply irrelevant; even the editing user interface is practically hidden behind a wall of inconvenience and mostly ignored in comments.

Personally, I think federated wikis are a promising organization for the public web, but they won't be like this.

Actual software and sites, particularly when they replace a very good predecessor like in this case, should be judged by their actual quality, not by enthusiasm levels or fantasies about the future. As a production wiki, the C2 replacement has been published by mistake and it should be reverted ASAP and killed with fire, but as a research testbed it deserves rework and further experimentation: with a good user interface, which remains to be determined, people would be able to exercise the underlying federated wiki database, which I suspect to be good.

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

#106

Post by harryh »

rayiner wrote: post #90
mbrock wrote: post #83

Earlier quoted context omitted.

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 ve…

The web is better now because there are more people using it. All the things that you dislike were requirements to onboarding all those people.

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

#107

Post by wtbob »

sp332 wrote: post #104
geofft wrote: post #85

Earlier quoted context omitted.

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…

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.

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

#108

Post by mbrock »

HelloNurse wrote: post #105
mbrock wrote: post #71

Earlier quoted context omitted.

Is it the whole concept of a federated wiki that you think is a "bad idea"? When you say that the "'potential' for improvement doesn't matter," what exactly do you mean? Doesn't matter to whom? For what reason? I am lenient and curious about most attempts at innovation in the field of web-based communication and collaboration. Personally speaking, I like Ward Cunningham; I admire his previous work; I am interested in…

A federated wiki consists of three main parts: a federated database of content (which is supposed to be the interesting part), a user interface for reading that content, and a fairly different but unavoidably related user interface for editing and administration (both likely to resemble their counterparts in a non-federated wiki, but a bit more complex because of the richer information model). Of these three componen…

That seems like a more reasonable position.

However:

(1) The federated wiki has not replaced C2. Ward has put up a notice saying that he plans to do so at some unspecified time in the future. Right?

(2) You claimed earlier that "the 'potential' for improvement doesn't matter and doesn't exist," which I point out is excessively negative and dejecting.

(3) Wiki has always been a research testbed and a place for experimentation. That's why the whole thing is done in public in such a way that any interested person may participate and give input. To help such projects, if one has any reason to believe that they may be valuable—as you now seem to agree—it is more productive to give constructive feedback through appropriate channels.

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

#109

Post by tptacek »

rayiner wrote: post #90
mbrock wrote: post #83

Earlier quoted context omitted.

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 ve…

SMTP/IMAP isn't better than webmail. IMAP is an awful protocol. It's less secure than HTTPS. It doesn't do a better job of avoiding "spying" than webmail does. You can sync multiple clients with IMAP, but webmail accomplishes the same task so seamlessly clients don't even need to be aware of it.

IMAP is a pretty good example of the kind of protocol that should be eaten by HTTP/RPC APIs.

(I've written a couple IMAP implementations, both client and server, and was [in the 1990s] responsible for the mail infrastructure for a popular ISP.)

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

#110

Post by chinpokomon »

With regards to SEO, I think a lot of you are missing something special about SFW, and that is that each page has a JSON representation. The client only exists to render the human readable view, but the JSON is fully crawlable by a spider. In a lot of ways, this borrows from the days of XML pages where the content was rendered using XSLTs. In this case, the content as well as page revision history and links are preserved as a single JSON object. This actually may make SFW content more crawlable.
Post reply on HN