Hacker News Reader

Comment by blueskin_ | Hacker News Reader

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 pages would.

View on HN

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.

This is a specific issue to be solved with standard REST techniques. Do you know if the team is working on it? Maybe it's on a timeline, scheduled to be implemented next month? I haven't looked into it, but the current lack of this functionality does not mean that the "new wiki is doomed by design."

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 available execution resources, see a different picture. That's just a braindead model for information storage and exchange.

I don't know what that was all about, but Google does, here's a blog post about it:

http://googlewebmastercentral.blogspot.com/2014/05/understan...

And webmaster tools has a tool to verify that content is scraped correctly.

Not saying there aren't other good reasons to do server-side rendering, but SEO is not a real one.

You're trying to be too intelligent for your own good.

Fact of the matter is the new wiki UI is horrible. It doesn't have to be spelled out any more complicated than that.

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 ...

Yeah, that does make it better, but it's still not perfect. Witness the complaints right here about how you can't tell whether you got an empty page or it just hasn't finished loading yet.

Trouble awaits when you try to wedge a general-purpose application environment into a page-based document viewer.

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.

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.

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).

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.

This can be solved using any of these methods: https://developers.google.com/webmasters/ajax-crawling/docs/...

I maintain a client side rendered website and while SEO can be problematic it can also be done.

I don't see C2 using any of these methods at first glance tho.

It can more easily be solved by just not crawling sites that have mandatory javascript, because chances are their content is going to be crap and not worth the time if they are that hostile to basic usability.

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

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 horrible idea, yet games and other useful interactivity (minus the annoying ads...) weren't so bad. Now the trend seems to be putting the whole site into JS, and while it could be argued that JS is more open than Flash, the end-result is just as unnecessarily wasteful of resources and inaccessible in the ways that the web was originally envisioned.

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.

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.

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.

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.

I'd actually prefer the panes to be a bit wider, but that's not that important.

What I find weird is that I can go 2 layers back on the same page, but then I suddenly have to use the browser's back button to go further up. I have to use the back button to close the right-most pane. And sometimes the back button does not work, or I have to use it multiple times to get "one step" back. Loading times feel worse, because you stare at a blank rectangle and wonder "is this article empty" and then it suddenly pops in.

I accidentally dragged a paragraph around and had to go back to the front page and follow a link there to remove the local copy I created. I also don't know how I would publish that copy if it were an intentional edit.

I'm sure it makes sense once you've understood it, but discoverability seems bad. Despite all its flaws TiddlyWiki seems to get the basic SPA wiki UI "more right" to me.

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 behaviour: it can be blown away easily and efficiently. You can forget large pieces of history by the apparently harmless interaction of clicking on links in a previous pane.

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 at one level, but at that point it is probably a UI specifically for me rather than something that is generally usable.

One thing that was cute was that the stack of pages is exposed in the URL, which suggests that some nice greasemonkey tricks would be viable.

"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.

There's no reason the page can't display some sort of progress indicator while it waits for data. If it doesn't actually do this here then that's silly, but that's a problem with the implementation, not the concept. I'm seeing more and more apps that perform potentially long-running tasks (usually involving network access) without any indication that anything is happening. It's frustrating.

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 single page applications, Google wouldn't exist today. So be careful when you encourage websites to become more complicated.

Tim Bray said it well in 2003: "Browsers are more usable because they're less flexible." https://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePl...

> 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.

You're commenting on a topic that the majority of people here have probably debated and thought about at great length. I can't help you think that calls for a slightly more nuanced argument than the one above.

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/

I don't disagree at all. I'd probably agree with the statement that most sites would be better without most of their 'enhancements'.

I just don't want the HN party line to become a knee-jerk "all js on content sites is bad".

I'm a big fan of pjax etc as it can really speed up page load without any downside (assuming it's been implemented well). If the UX is good, performance are as fast or faster as a plain HTML site, everything is bookmarkable and you don't break my back-button then go crazy.

And on the whole I actually like the new c2 wiki.

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...

Reply on news.ycombinator.com