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

41–50 of 126 posts

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

#41

Post by HelloNurse »

314 wrote: post #36
HelloNurse wrote: post #27

Earlier quoted context omitted.

Delayed display of text is terribly bad. Consider the following scenario: 1) I click a link to "Decorator Pattern". 2) A new panel with the title and no text appears. 3) I assume a major malfunction. 4) The text of the page deigns to appear. Then I tried clicking on "Category: Pattern" and page text took about a minute, not a few seconds. Regarding the "stack" of previously read pages, it offers a typical stack behav…

That sounds like server load, more than anything on the client side. When I used it everything was instant and snappy, so it might just depend on the number of visitors. Blowing away the stack by clicking is a bit of a pain. A couple of times something buggy happened where new pages overwrote some part of the old stack, but left the rest of it in place. I would like to see some option for expanding multiple branches…

"That sounds like server load, more than anything on the client side."

You are missing the point: with a normal page, server load looks like server load, whereas with "dynamic" tricks server load looks like a defective page and what you see cannot be considered the true content of the page.

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

#42

Post by TeMPOraL »

andybak wrote: post #30
lsh wrote: post #15

Earlier quoted context omitted.

no argument is being made, stop being po-faced. I agree with his sentiments and wish the internet were otherwise. I don't care how thoroughly brow beaten everyone is about this, I want it recorded that this is dumb and unnecessary.

> I want it recorded that this is dumb and unnecessary. But it's not that simple. Some uses of javascript genuinely add value - even to content sites. The real discussion is about cost vs benefit not "All interactivity is bad". Shades of grey, dear sir. Shades of grey...

But we do need some (I'd say, a lot) back-pressure against laziness and fashion that creates that unneccessary JavaScript.

Being JS-heavy is something I found to be correlated with poor/untrustworthy content and someone trying to make money off you. I'm of course not talking about web applications here (like GMail or Google Docs) but web pages, which after all "should be text communicating a fucking message"[0].

[0] - http://motherfuckingwebsite.com/

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

#43

Post by TeMPOraL »

arethuza wrote: post #10
agumonkey wrote: post #8

Earlier quoted context omitted.

I'm both sad and enjoyed by the move. I'm attached to the deceiptively poor old wiki, because it contrasts with the great content quality. At the same time, they're migrating toward something off the map of current technologies, and so the spirit of the first wikiwikiweb is still alive. ps: if someone has an archive / mirror of c2.com, I'll be happy to leech.

"deceiptively poor old wiki, because it contrasts with the great content quality" Does that remind anyone else of HN? I sort of rather like the lack of features on HN in the same way that I like c2.com.

Yeah, I feel that too (though HN is a bit too bare-bones for me; I think of Reddit as being the golden UI standard of this type of site). I do believe the more superfluous JS you have on page the less likely it is that your content is any good.

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

#44

Post by tragic »

cousin_it wrote: post #31
314 wrote: post #22

Earlier quoted context omitted.

Why is the usability bad? Pages are pleasant to read in that aspect ratio and it seems to provide a good solution to what to do with the bits around the edges. I like the stack of places that I've been before as context and think that it encourages exploration and clicking around more than the original site.

A website's job is serving up pieces of information. Helping me navigate that information is the browser's job. That's why we have amazing innovations like the back button, tabbed browsing, and bookmarks. Imagine a world where every website had its own buggy implementation of those. Also, simplicity of core architecture leads to diversity of tools. If Google's first crawler had to execute JavaScript and make sense of…

> That's why we have amazing innovations like the back button, tabbed browsing, and bookmarks. Imagine a world where every website had its own buggy implementation of those.

Heh. We had a requirement to put in a back button. We put it in. Since no decent criteria were available to specify how it behaved, we just called history.back().

They did some user testing. Then they asked us to take it out again.

Never have I enjoyed taking on a ticket like I enjoyed taking out that stupid bloody back button.

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

#46

Post by learnstats2 »

mbrock wrote: post #40
learnstats2 wrote: post #37

I feel sad about this :( The original wiki was full of the hope of the web. Here, the UI is unintuitive. The site depends heavily on client-side processing. It loads slowly - there's no intelligent processing in advance. It uses canonical URIs OK, but the window.history updates late and the URIs are designed in a way that makes them difficult to share. The code is hosted on an ethically-dubious commercial site. The w…

It seems to me like the people contributing to this project still have lots of hope for the web. The original wiki had plenty of UI quirks, too. How much time have you invested into figuring out how it works? Is the problem that the main page doesn't explain things clearly enough? Maybe you'd like to contribute some documentation? With regards to loading times, that's an engineering issue to be improved. Efficient lo…

> Is the problem that the main page doesn't explain things clearly enough? Maybe you'd like to contribute some documentation?

No. There are several problems, the first of which is that I am served content as a Javascript-dependent blank page for no good reason.

I'm not sure why you think I would contribute to this project. It contradicts my ideals for the future of the web on many levels, as I already explained, and some of which you overlooked when making your comment.

Firstly, I do not want to support something that represents a backwards movement from my preference, and secondly, any change I would choose to make would likely be reversed as against the spirit of the project.

My belief is that the Benevolent Dictator for Life/cult of personality model of existing open technologies is broken and should be shunned. (With apologies to Ward Cunningham, who I do not mean anything personally towards). People committing their resources to this project are not providing for the diversity that 7 billion web users need.

I have plenty of hope. My hope is that other people will take this technology in a better or just different direction.

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

#48

Post by blueskin_ »

andybak wrote: post #30
lsh wrote: post #15

Earlier quoted context omitted.

no argument is being made, stop being po-faced. I agree with his sentiments and wish the internet were otherwise. I don't care how thoroughly brow beaten everyone is about this, I want it recorded that this is dumb and unnecessary.

> I want it recorded that this is dumb and unnecessary. But it's not that simple. Some uses of javascript genuinely add value - even to content sites. The real discussion is about cost vs benefit not "All interactivity is bad". Shades of grey, dear sir. Shades of grey...

I've yet to see any. It used to be necessary for drop down menus, but now CSS does that. When I browse with javascript off, it's only crap sites that break, and often the same ones loaded down with tracking cookies, 3rd party CDNs, facebook/google plus/twitter buttons, popups and whatever other crap. Interesting, that...

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

#49

Post by mbrock »

learnstats2 wrote: post #46
mbrock wrote: post #40

Earlier quoted context omitted.

It seems to me like the people contributing to this project still have lots of hope for the web. The original wiki had plenty of UI quirks, too. How much time have you invested into figuring out how it works? Is the problem that the main page doesn't explain things clearly enough? Maybe you'd like to contribute some documentation? With regards to loading times, that's an engineering issue to be improved. Efficient lo…

> Is the problem that the main page doesn't explain things clearly enough? Maybe you'd like to contribute some documentation? No. There are several problems, the first of which is that I am served content as a Javascript-dependent blank page for no good reason. I'm not sure why you think I would contribute to this project. It contradicts my ideals for the future of the web on many levels, as I already explained, and…

I think the Federated Wiki concept is very interesting, and I agree that it would be very nice to serve functioning static pages—this could be added and probably should.

That's why I'm wondering if you have looked into the project's ideals and roadmap. Maybe they have different priorities than you would prefer. Maybe, as I said, they are already working on providing for your needs.

This is not a product someone is selling to you; it's a public work-in-progress with a pretty ambitious idea.

If you think that JavaScript applications in general are opposed to your ideal future of the web, then I understand your disappointment.

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

#50

Post by Touche »

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.

Google executes JavaScript.
Post reply on HN