7 ms·

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 u

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.

andybak 12y ago
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.
- lsh 12y ago
  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.
  - andybak 12y ago
    > 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...
    - TeMPOraL 12y ago
      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/ http://motherfuckingwebsite.com/
      - andybak 12y ago
        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.
      - vegedor 12y ago
        >correlated with poor/untrustworthy content and someone trying to make money >I'm of course not talking about web applications here (like GMail or Google Docs) Why would you even disclaim that, if the implication wasn't justified, that Google services weren't trustworthy but trying to make money?
    - blueskin_ 12y ago
      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...
314 12y ago
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.
- detaro 12y ago
  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.
- HelloNurse 12y ago
  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.
  - 314 12y ago
    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.
kephra 12y ago
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 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.
- mbrock 12y ago
  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."
- Touche 12y ago
  Google executes JavaScript.
  - zAy0LfpBZLC8mAC 12y ago
    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.
    - Touche 12y ago
      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/understanding-web-pages-better.html 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.
userbinator 12y ago
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.
- sp332 12y ago
  It's not static. It's an editable wiki.
  - geofft 12y ago
    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.
    - sp332 12y ago
      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.
deleted 12y ago
[deleted]

andybak 12y ago

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.

lsh 12y ago
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.
- andybak 12y ago
  > 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...
  - TeMPOraL 12y ago
    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/ http://motherfuckingwebsite.com/
    - andybak 12y ago
      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.
    - vegedor 12y ago
      >correlated with poor/untrustworthy content and someone trying to make money >I'm of course not talking about web applications here (like GMail or Google Docs) Why would you even disclaim that, if the implication wasn't justified, that Google services weren't trustworthy but trying to make money?
  - blueskin_ 12y ago
    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...

314 12y ago

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.

detaro 12y ago
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.
HelloNurse 12y ago
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.
- 314 12y ago
  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.

kephra 12y ago

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

mbrock 12y ago
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."
Touche 12y ago
Google executes JavaScript.
- zAy0LfpBZLC8mAC 12y ago
  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.
  - Touche 12y ago
    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/understanding-web-pages-better.html 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.

userbinator 12y ago

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.

sp332 12y ago
It's not static. It's an editable wiki.
- geofft 12y ago
  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.
  - sp332 12y ago
    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.

deleted 12y ago

[deleted]